XCON Working Group                                          G. Camarillo
Internet-Draft                                                  Ericsson
Expires: February 17, April 25, 2005                                           J. Ott
                                                     Universitaet Bremen
                                                                K. Drage
                                                     Lucent Technologies
                                                         August 19,
                                                        October 25, 2004

                The Binary Floor Control Protocol (BFCP)
                      draft-ietf-xcon-bfcp-01.txt
                      draft-ietf-xcon-bfcp-02.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 aware will be disclosed, in accordance with
   RFC 3668.

   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 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 February 17, April 25, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   Floor control is a means to manage joint or exclusive access to
   shared resource 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 specicies specifies the Binary Floor Control Protocol (BFCP).
   BFCP is used between conference floor participants and floor control servers,
   and between floor chairs (i.e., moderators) and floor control
   servers.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4   5
   3.   Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5   6
     3.1  Floor Creation . . . . . . . . . . . . . . . . . . . . . .   6   8
     3.2  Obtaining Information to Contact a BFCP Floor Control Server  . . .   7   8
     3.3  Generating a Shared Secret . . . . . . . . . . . . . . . .   7   8
     3.4  Obtaining Floor-Resource Associations  . . . . . . . . . .   7   9
     3.5  Policy Enforcement . . . . . . . . . . . . . . . . . . . .   8   9
   4.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   8  10
     4.1  User -  Floor Participant to Floor Control Server Interface  . . . . . . . . . .   9  10
     4.2  Floor Chair - to Floor Control Server Interface  . . . . . . .  11  13
   5.   Packet Format  . . . . . . . . . . . . . . . . . . . . . . .  12  14
     5.1  FIXED-HEADER Format  . . . . . . . . . . . . . . . . . . .  12  14
     5.2  Attribute Format . . . . . . . . . . . . . . . . . . . . .  13  16
       5.2.1  FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . .  14  17
       5.2.2  USER-ID  . . . . . . . . . . . . . . . . . . . . . . .  14  17
       5.2.3  BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . .  14  17
       5.2.4  TRANSACTION-ID . . . . . . . . . . . . . . . . . . . .  15  18
       5.2.5  FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . .  15  18
       5.2.6  HUMAN-READABLE-INFO  . . . . . . . . . . . . . . . . .  15  18
       5.2.7  INTEGRITY  DIGEST . . . . . . . . . . . . . . . . . . . . . .  16 . .  19
       5.2.8  REQUEST-STATUS . . . . . . . . . . . . . . . . . . . .  16  20
       5.2.9  ERROR-CODE . . . . . . . . . . . . . . . . . . . . . .  17  21
       5.2.10   USER-DISPLAY-NAME  . . . . . . . . . . . . . . . . .  19  23
       5.2.11   USER-URI . . . . . . . . . . . . . . . . . . . . . .  19  23
       5.2.12   PRIORITY . . . . . . . . . . . . . . . . . . . . . .  19
   6.   Message Format  23
       5.2.13   NONCE  . . . . . . . . . . . . . . . . . . . . . . .  19
     6.1  FloorRequest  23
       5.2.14   SUPPORTED-TLVS . . . . . . . . . . . . . . . . . . .  24
     5.3  Message Format . . . .  19
     6.2  FloorRelease . . . . . . . . . . . . . . . . . .  24
       5.3.1  FloorRequest . . . . .  20
     6.3  FloorRequestInfo . . . . . . . . . . . . . . . .  24
       5.3.2  FloorRelease . . . . .  20
     6.4  FloorRequestStatus . . . . . . . . . . . . . . . .  25
       5.3.3  FloorRequestInfoWanted . . . .  20
     6.5  FloorInfo . . . . . . . . . . . .  25
       5.3.4  FloorRequestInfo . . . . . . . . . . . .  21
     6.6  FloorStatus . . . . . . .  26
       5.3.5  FloorInfoWanted  . . . . . . . . . . . . . . . .  21
     6.7  ChairAction . . .  26
       5.3.6  FloorInfo  . . . . . . . . . . . . . . . . . . . .  22
     6.8  ChairActionAck . .  27
       5.3.7  ChairAction  . . . . . . . . . . . . . . . . . . . .  22
     6.9  Ping .  27
       5.3.8  ChairActionAck . . . . . . . . . . . . . . . . . . . .  28
       5.3.9  Hello  . . . . . .  22
     6.10   PingAck . . . . . . . . . . . . . . . . . .  28
       5.3.10   HelloAck . . . . . .  22
     6.11   Error . . . . . . . . . . . . . . . .  28
       5.3.11   Error  . . . . . . . . .  23
   7.   Transport . . . . . . . . . . . . . .  29
   6.   Transport  . . . . . . . . . . .  23
   8.   Lower-Layer Security . . . . . . . . . . . . . .  29
   7.   Lower-Layer Security . . . . . .  23
   9.   Protocol Transactions . . . . . . . . . . . . . .  30
   8.   Protocol Transactions  . . . . .  23
     9.1  Client Behavior . . . . . . . . . . . . . .  30
     8.1  Client Behavior  . . . . . . .  24
     9.2  Server Behavior . . . . . . . . . . . . . .  30
     8.2  Server Behavior  . . . . . . .  24
   10.  Authentication . . . . . . . . . . . . . .  30
   9.   Authentication and Authorization . . . . . . . . .  24
     10.1   Client Behavior . . . . .  31
     9.1  Client Behavior  . . . . . . . . . . . . . . .  24
     10.2   Server Behavior . . . . . .  31
     9.2  Floor Control Server Behavior  . . . . . . . . . . . . . .  25
   11.  Client  32
   10.  Floor Participant Operations . . . . . . . . . . . . . . . . . . . . .  25
     11.1  32
     10.1   Requesting a Floor . . . . . . . . . . . . . . . . . . .  25
       11.1.1   Receiving  33
       10.1.1   Sending a Response . . . . . . . . . . . . . FloorRequest Message . . .  26
   12.  Requesting Information about Floor Requests . . . . . . . .  27
     12.1  33
       10.1.2   Receiving a Response . . . . . . . . . . . . . . . . . .  27
   13.  34
     10.2   Cancelling a Floor Request and Releasing a Floor . . . . . .  28
     13.1   Receiving  34
       10.2.1   Sending a Response FloorRelease Message . . . . . . . . . . .  34
       10.2.2   Receiving a Response . . . . . . .  28
   14.  Requesting Information about Floors . . . . . . . . .  35
   11.  Chair Operations . . .  28
     14.1   Receiving a Response . . . . . . . . . . . . . . . . . .  29
   15.  Checking the Liveness of .  35
     11.1   Sending a Server ChairAction Message  . . . . . . . . . . . . .  29
     15.1  36
     11.2   Receiving Responses a Response . . . . . . . . . . . . . . . . . .  30
   16.  Chair  37
   12.  General Client Operations  . . . . . . . . . . . . . . . . . . . . . .  30
     16.1   Obtaining  37
     12.1   Requesting Information about Floor Requests Floors  . . . . . . . .  30
     16.2   Instructing the Floor Control Server . .  37
       12.1.1   Sending a FloorInfoWanted Message  . . . . . . . . .  30
       16.2.1  37
       12.1.2   Receiving a Response . . . . . . . . . . . . . . . .  31
   17.  Server Operations  . . .  38
     12.2   Requesting Information about Floor Requests  . . . . . .  38
       12.2.1   Sending a FloorRequestInfoWanted Message . . . . . .  39
       12.2.2   Receiving a Response . . . . . .  32
     17.1   Reception of a FloorRequest Message . . . . . . . . . .  32
     17.2   Reception  40
     12.3   Obtaining the Capabilities of a FloorRequestInfo Message  . . . . . . Floor Control Server . .  33
     17.3   Reception of  40
       12.3.1   Sending a FloorRelease Hello Message  . . . . . . . . . .  33
     17.4   Reception of a FloorInfo Message . . . . . . .  40
       12.3.2   Receiving Responses  . . . . .  34
     17.5   Reception of a ChairAction Message . . . . . . . . . . .  35
     17.6   Reception of a Ping Message  40
   13.  Floor Control Server Operations  . . . . . . . . . . . . . .  35
     17.7   Error  41
     13.1   Reception of a FloorRequest Message Generation . . . . .  . . . . . . . . . . .  36
   18.  BFCP and  41
       13.1.1   Generating the Offer/Answer Model  . . . . . . . . First FloorRequestInfo Message  . . .  42
       13.1.2   Generation of Subsequent FloorRequestInfo Messages .  42
     13.2   Reception of a FloorRequestInfoWanted Message  . .  36
     18.1   Fields in the m Line . . .  43
       13.2.1   Information on a Single Floor Request  . . . . . . .  44
       13.2.2   Information on the Floor Requests Associated to a
                Participant  . . . . . . . .  36
     18.2   The confid and userid SDP Parameters . . . . . . . . . .  37
     18.3   The k line . .  44
     13.3   Reception of a FloorRelease Message  . . . . . . . . . .  45
     13.4   Reception of a FloorInfoWanted Message . . . . . . . . .  45
       13.4.1   Generation of the First FloorInfo Message  . .  37
     18.4   TCP Connection Management . . .  46
       13.4.2   Generation of Subsequent  FloorInfo Messages . . . .  47
     13.5   Reception of a ChairAction Message . . . . . . . .  37
     18.5   Association between Streams and Floors . . .  47
     13.6   Reception of a Hello Message . . . . . .  38
     18.6   Example . . . . . . . .  48
     13.7   Error Message Generation . . . . . . . . . . . . . . . .  38
   19.  48
   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  39
   20.  49
   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  39
     20.1   SDP Attributes Registration  . . . . . . . . . . . . . .  39
   21.  49
   16.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  39
   22.  49
   17.  References . . . . . . . . . . . . . . . . . . . . . . . . .  39
   22.1  49
   17.1   Normative References . . . . . . . . . . . . . . . . . . .  39
   22.2  49
   17.2   Informational References . . . . . . . . . . . . . . . . .  40  50
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  41  51
        Intellectual Property and Copyright Statements . . . . . . .  42  52

1.  Introduction

   Within a (multimedia) conference, some applications (e.g., conference
   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 [15] [9] list a set of
   requirements that need to be met by floor control protocols.  The
   Binary Floor Control Protocol (BFCP), which is specified in this
   document, meets these requirements.

   The remainder of this document is organized as follows.  Section 2
   defines the terminology used throughout this document and Section 3
   discusses the scope of BFCP (i.e., which tasks fall within the scope
   of BFCP and which ones are performed using different mechanisms).
   Section 4 provides a non-normative overview of BFCP operation and
   subsequent sections provide the normative specification of BFCP.

2.  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 conferences, a given media participant is typically
   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 co-located.

   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 manipulated by the conference policy server.  It includes
   the membership policy and the media policy.  There is an instance of
   conference policy for each conference.

   Conference Policy Control Protocol (CPCP): The protocol used by
   clients to manipulate the conference policy.

   Floor: A permission to temporarily access or manipulate a specific
   shared resource or set of resources.

   Floor chair: Chair: A user (or an entity) who logical entity that manages one floor (grants, denies,
   or revokes a floor).  The  An entity that assumes the logical role of a
   floor chair does not have to be for a
   member in given transaction may assume a conference. different role
   (e.g., floor participant) for a different transaction.  The roles of
   floor chair and floor participant are defined on a
   transaction-by-transaction basis.

   Floor control: 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: 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.  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.

   Media Policy: A set of rules manipulated by the conference policy
   server regarding the media composition of the conference.  The media
   policy is used by the focus to determine the mixing characteristics
   for the conference.  The media policy includes rules about which
   conference participants receive media from which other participants,
   and the ways in which that media is combined for each conference
   participant.  In the case of audio, these rules can include the
   relative volumes at which each conference participant is mixed.  In
   the case of video, these rules can indicate whether the video is
   tiled, whether the video indicates the loudest speaker, and so on.

   EDITOR'S NOTE: we may want to reference the definitions in the
   conferencing framework.  If we decide to copy them here, we need to
   make sure

   Participant: An entity that we copy all the definitions we use in this document. acts as a floor participant, as a media
   participant, or as both.

3.  Scope

   As stated above, earlier, the BFCP is a protocol to coordinate access to
   shared resources in a conference setting following the requirements defined
   in [15]. [9].  Floor control complements other functions defined in the conference framework,
   conferencing framework [14], such as conference policy and media
   policy.  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), and how access to the floor is
   managed.  Furthermore, it is up to 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.

   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 the
   conference and media policy, respectively.

   Figure 1 shows the tasks that BFCP can perform.

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

                Figure 1: Functionality provided by BFCP

   BFCP provides a means:

   o  for users 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 users. floor participants.
   o  for floor chairs to send floor control servers decisions regarding
      floor requests.
   o  for floor control servers to keep users floor participants and floor
      chairs informed about the status of a given floor. 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 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.

   According to the definitions in Section 2, the conference policy is
   manipulated using a Conference Policy Control Protocol (CPCP), such
   as [16]. the one defined in [10].  Consequently, floor creation and
   termination is handled by CPCP.  In addition, CPCP also handles the
   association of a given floor with a resource or a set of resources
   (e.g., media streams).

   Additionally, the floor control server needs to stay up to date on
   changes on the conference policy (e.g., when a new floor is created).
   The floor control may use a mechanism such as the XCAP event package
   [19] one defined in [13]
   to keep itself up to date.

3.2  Obtaining Information to Contact a BFCP Floor Control Server

   A user or a floor chair 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.

   Users

   Clients can obtain this information in different ways.  Two
   possibilities are using CPCP and using the an offer/answer [11] exchange
   which is used to establish media streams between the user and the
   conference server.  Section 18 discusses how [8] exchange.
   How to use an SDP [5] offer/
   answer [11] [6] offer/answer [8] exchange to obtain this information.
   information is described in [15].

3.3  Generating a Shared Secret

   Authentication and integrity protection in BFCP are is based on a shared secret between the user or floor chair, client
   and the floor control server.  So, there is a need for a mechanism to
   generate such a shared secret.

   When the user floor participant or the floor control chair obtains a the information
   needed to contact the BFCP floor control server over a secure channel
   (e.g., an offer/answer [8] exchange using SIP [10] [7] protected using S/MIME), S/
   MIME), they can get the shared secret using the same channel.

   If there is no secure channel available, a different mechanism needs
   to be used.  For example, MIKEY [18] [12] allows an offerer and an
   answerer to perform a Diffie-Hellman key exchange.

   Editor's note: Probably need to mention TLS as another mechanism
   here.

   Shared secrets can also be generated and exchanged using out-of-band
   means.

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, which is manipulated using CPCP.

   Users

   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 CPCP or an offer/answer [11] [8] exchange.  Section
   18 describes how
   How to use an offer/answer exchange to obtain these
   associations. associations is
   described in [15].

      Note that users floor participants perform offer/answer exchanges with
      the SIP focus of the conference.  So, the SIP focus needs to
      obtain information about associations between floors and resources
      using a mechanism such as CPCP in order to be able to provide this
      information to a
      user floor participant in an offer/answer exchange.

3.5  Policy Enforcement

   A user participant whose floor request is granted has the right to use in (in
   a certain way way) the resource or resources associated with the floor
   that was requested.  For example, the user participant may have the right
   to talk
   (i.e., send media over a particular audio stream). 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 media policy of a conference is the one that
   determines which users 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 in the media policy of the conference.  For example, the
   mixer only accepts media from the user who holds the floor.

   A way to reflect the status of the floors in the media policy is to
   have the floor control server manipulate the media policy using CPCP.
   Nevertheless, there are other ways to enforce floor control policies,
   such as having a floor control chair manipulate the media policy
   (using CPCP) only if there are misbehaving users trying to use a
   resource without holding its associated floor.

4.  Overview of Operation

   This section provides a non-normative description of BFCP operations.
   Section 4.1 describes the interface between users 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.  The common
   header contains, among other information, a 32-bit conference
   identifier.  Users  Floor participants, media participants, and floor chairs
   are identified by a 16-bit user identifier, which is carried in a
   TLV.

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

4.1  User -  Floor Participant to Floor Control Server Interface

   Users

   Floor participants request a floor by sending a FloorRequest message
   to the floor control server.  BFCP supports third party third-party floor
   requests.  That is, the user floor participant sending the floor request
   need not be co-located with the same as the user
   who 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, and the identity of
   the beneficiary of the floor, in third party floor requests, in a
   BENEFICIARY-ID TLV.

      Third party floor requests can be sent sent, for example, by users floor
      participants that have a BFCP connection to the floor control server,
      server but who that are not conference 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.  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.

   EDITOR'S NOTE: we need to explain in this paragraph that if a user is
   anonymous, the floor

   Floor control server does not disclose the identity of servers respond to FloorRequest messages with
   FloorRequestInfo messages, which provide information about the requester status
   of the floor request.  The first FloorRequestInfo message is the
   response to the rest of FloorRequest message from the users client, and floor chairs.

   Floor control servers respond to FloorRequest therefore
   carries the same TRANSACTION-ID TLV as the FloorRequest.

   Additionally, the first FloorRequestInfo message carries a
   FLOOR-REQUEST-ID TLV.  Subsequent FloorRequestInfo messages with
   FloorStatus messages.

   Editor's note: This section related
   to the same floor request will be finished when we have agreed on
   what it is specified in carry the rest of this document.  For same FLOOR-REQUEST-ID TLV.
   This way, the time
   being, below there are two typical call flows: floor participant can associate them with the
   appropriate floor request.

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

   Figure 2 shows how a floor and participant requests a client requesting information about floor, obtains it,
   and, at a floor.

   Client later time, releases it.  This figure illustrates the use,
   among other TLVs, of the TRANSACTION-ID and the FLOOR-REQUEST-ID
   TLVs.

     Floor Participant                                 Floor Control
                                                          Server

     |
             |(1) FloorRequest                               |
     |        TRANSACTION-ID:
             |TRANSACTION-ID: 123                            |
     |----------------------------->|
             |USER-ID: 234                                   |
             |FLOOR-ID: 543                                  |
             |---------------------------------------------->|
             |(2) FloorRequestInfo                           |   FloorRequestStatus         |
     |     TRANSACTION-ID:
             |TRANSACTION-ID: 123                            |
             |USER-ID: 234                                   |     FLOOR-REQUEST-ID: 345
             |FLOOR-REQUEST-ID: 789                          |
             |FLOOR-ID: 543                                  |     REQUEST-STATUS:
             |REQUEST-STATUS: Pending                        |
     |<-----------------------------|
     |                              |
     |   FloorRequestStatus
             |<----------------------------------------------|
             |(3) FloorRequestInfo                           |
             |USER-ID: 234                                   |     FLOOR-REQUEST-ID: 345
             |FLOOR-REQUEST-ID: 789                          |
             |FLOOR-ID: 543                                  |     REQUEST-STATUS:
             |REQUEST-STATUS: Accepted (1st in Queue)        |
     |<-----------------------------|
     |                              |
     |                              |
     |   FloorRequestStatus
             |<----------------------------------------------|
             |(4) FloorRequestInfo                           |
             |USER-ID: 234                                   |     FLOOR-REQUEST-ID: 345
             |FLOOR-REQUEST-ID: 789                          |
             |FLOOR-ID: 543                                  |     REQUEST-STATUS:
             |REQUEST-STATUS: Granted                        |
     |<-----------------------------|
     |                              |
     |                              |
     |
             |<----------------------------------------------|
             |(5) FloorRelease                               |
             |TRANSACTION-ID: 154                            |     TRANSACTION-ID: 124      |
     |     FLOOR-REQUEST-ID: 345    |
     |----------------------------->|
     |
             |USER-ID: 234                                   |
             |FLOOR-REQUEST-ID: 789                          |   FloorRequestStatus         |
             |---------------------------------------------->|
             |(6) FloorRequestInfo                           |     TRANSACTION-ID: 124
             |TRANSACTION-ID: 154                            |
             |USER-ID: 234                                   |     FLOOR-REQUEST-ID: 345
             |FLOOR-REQUEST-ID: 789                          |
             |FLOOR-ID: 543                                  |     REQUEST-STATUS:
             |REQUEST-STATUS: Released                       |
     |<-----------------------------|
     |                              |
             |<----------------------------------------------|

               Figure 2: Requesting and releasing a floor
    Client or                    Floor Control
      Chair                         Server

        |      FloorInfo               |
        |        TRANSACTION-ID: 123   |
        |        FLOOR-ID: 15          |
        |----------------------------->|
        |                              |
        |FloorStatus                   |
        |  TRANSACTION-ID: 123         |
        |  FLOOR-ID: 15                |
        |  FLOOR-REQUEST-ID: 345       |
        |  REQUEST-STATUS: Granted     |
        |  FLOOR-REQUEST-ID: 348       |
        |  REQUEST-STATUS: 1st in queue|
        |<-----------------------------|
        |                              |
        |FloorStatus                   |
        |  FLOOR-ID: 15                |
        |  FLOOR-REQUEST-ID: 348       |
        |  REQUEST-STATUS: Granted     |
        |<-----------------------------|
        |                              |
        |FloorStatus                   |
        |  FLOOR-ID: 15                |
        |<-----------------------------|
        |                              |

   Figure 3: Obtaining status information about 2 shows how a floor

4.2 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 as the FloorInfoWanted
   message.

   Subsequent FloorInfo messages consist of server-initiated
   transactions, and therefore carry no TRANSACTION-ID TLV.  FloorInfo
   message (2) indicates that there are currently two floor requests for
   the floor whose Floor Chair - ID is 543.  FloorInfo message (3) indicates
   that the floor requests with Floor Control Server Interface

   TBD.  For Request ID 764 has been granted,
   while the time being, below there floor request with Floor Request ID 635 is the typical call flow for
   this interface.

     Chair 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                            |   ChairAction
             |TRANSACTION-ID: 257                            |
             |USER-ID: 234                                   |     TRANSACTION-ID: 123
             |FLOOR-ID: 543                                  |
             |---------------------------------------------->|
             |(2) FloorInfo                                  |     FLOOR-ID: 15
             |TRANSACTION-ID: 257                            |
             |USER-ID: 234                                   |     FLOOR-REQUEST-ID: 345
             |FLOOR-ID:543                                   |
             |FLOOR-REQUEST-ID: 764                          |     REQUEST-STATUS: Granted
             |FLOOR-ID: 543                                  |
       |----------------------------->|
             |BENEFICIARY-ID: 124                            |
             |REQUEST-STATUS: Accepted (1st in Queue)        |
             |FLOOR-REQUEST-ID: 635                          |   ChairActionAck
             |BENEFICIARY-ID: 154                            |
             |FLOOR-ID: 543                                  |     TRANSACTION-ID: 123
             |REQUEST-STATUS: Accepted (2nd in Queue)        |
       |<-----------------------------|
             |<----------------------------------------------|
             |(3) FloorInfo                                  |
             |USER-ID: 234                                   |

     Figure 4: Chair invoking an action at 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
             |FLOOR-ID:543                                   |
             |FLOOR-REQUEST-ID: 764                          |
             |FLOOR-ID: 543                                  |
             |BENEFICIARY-ID: 124                            |
             |REQUEST-STATUS: Granted                        |
             |FLOOR-REQUEST-ID: 635                          |
             |BENEFICIARY-ID: 154                            |
             |FLOOR-ID: 543                                  |
             |REQUEST-STATUS: Accepted (1st 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Queue)        | Ver |Reserved
             |<----------------------------------------------|
             |(4) FloorInfo                                  |  Primitive
             |USER-ID: 234                                   |        Payload Length
             |FLOOR-ID:543                                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |FLOOR-REQUEST-ID: 635                          |                         Conference ID
             |BENEFICIARY-ID: 154                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Ver:
             |FLOOR-ID: 543                                  |
             |REQUEST-STATUS: Granted                        |
             |<----------------------------------------------|

          Figure 3: Obtaining status information about a floor

   FloorInfo messages contain information about the 3-bit version field MUST be set to 1 to indicate this
   version of BFCP.

   Reserved: at 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 point, is
   not a multi-floor floor request.

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 5 bits in floor control server
   needs to take into consideration the reserved field SHOULD be
   set instructions received in
   ChairAction messages (e.g., granting a floor), it does not
   necessarily need to zero perform them exactly as requested by the sender of floor
   chair.  The operation that the floor control server performs depends
   on the ChairAction message and MUST be ignored by the
   receiver.

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

     Value        Primitive             Direction
     _________________________________________________________
       0          FloorRequest          C   ->  S
       1          FloorRelease          C   ->  S
       2          FloorRequestInfo      S   ->  C ; Ch  ->  S
       3          FloorRequestStatus    S   ->  C
       4          FloorInfo             C   ->  S ; Ch  ->  S
       5          FloorStatus           S   ->  C ; S   ->  Ch
       6 floor
   control server.

   For example, a floor chair may send a ChairAction           Ch  ->  S
       7          ChairActionAck        S   ->  Ch
       8          Ping                  C   ->  S ; Ch <->  S
       9          PingAck               S   ->  C ; Ch <->  S
      10          Error                 S   ->  C ; S   ->  Ch

       S: Server  C: Client  Ch: Chair

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

   Conference ID: this 32-bit identifies granting a
   floor which was requested as part of an atomic floor request
   operation that involved several floors.  Even if the conference chair
   responsible for one of the message
   belongs to.

5.2  Attribute 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                                   |
             |FLOOR-ID: 543                                  |
             |FLOOR-REQUEST-ID: 635                          |
             |REQUEST-STATUS: Granted                        |
             |---------------------------------------------->|
             |(2) ChairActionAck                             |
             |TRANSACTION-ID: 769                            |
             |USER-ID: 357                                   |
             |<----------------------------------------------|

          Figure 4: Chair instructing the floor control server

5.  Packet Format

   BFCP attributes are encoded packets consist of an 8-byte fixed header followed by
   attributes.  All the protocol values MUST be sent in TLV (Type-Length-Value) network byte
   order.

5.1  FIXED-HEADER Format

   The following is the FIXED-HEADER format.  TLVs
   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     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver |Reserved |  Primitive    |        Payload Length         |
     /                       Attribute Contents                      /
     /                                                               /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Conference ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type: this 7-bit field contains

                     Figure 5: FIXED-HEADER format

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

   Reserved: at this point, the attribute.

   M: 5 bits in the 'M' bit, known as reserved field SHOULD be
   set to zero by the Mandatory bit, indicates whether support sender of the attribute is required.  If an unrecognized attribute with the
   'M' bit set is received, the message is rejected.

   Length: and MUST be ignored by the
   receiver.

   Primitive: this 8-bit field contains identifies the length main purpose of the attribute in
   bytes, excluding any padding defined for specific attributes.
   message.  The
   Type, 'M' bit, and Length fields following primitive values are included.

   Attribute Contents: the contents defined:

       +-------+------------------------+-----------------------+
       | Value | Primitive              | Direction             |
       +-------+------------------------+-----------------------+
       |   0   | FloorRequest           | P -> S                |
       |   1   | FloorRelease           | P -> S                |
       |   2   | FloorRequestInfoWanted | P -> S ; Ch -> S      |
       |   3   | FloorRequestInfo       | P <- S ; Ch <- S      |
       |   4   | FloorInfoWanted        | P -> S ; Ch -> S      |
       |   5   | FloorInfo              | P <- S ; Ch <- S      |
       |   6   | ChairAction            | Ch -> S               |
       |   7   | ChairActionAck         | Ch <- S               |
       |   8   | Hello                  | P -> S ; Ch -> S      |
       |   9   | HelloAck               | P <- S ; Ch <- S      |
       |   10  | 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 different TLVs are defined message in
   4-byte units excluding the following sections.

5.2.1  FLOOR-ID

   The following is the format of fixed header.

   Conference ID: this 32-bit identifies the contents of conference the FLOOR-ID
   attribute, whose attribute type is 1. message
   belongs to.

5.2  Attribute Format

   BFCP attributes are encoded in TLV (Type-Length-Value) format.  TLVs
   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 = 1     |M|    Length     |           Floor ID                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     /                       Attribute Contents                      /
     /                                                               /
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

5.2.2  USER-ID

                          Figure 6: TLV format

   Type: this 7-bit field contains the type of the attribute.  The
   following attribute types are defined:

                     +------+---------------------+
                     | Type | Attribute           |
                     +------+---------------------+
                     |   0  | FLOOR-ID            |
                     |   1  | USER-ID             |
                     |   2  | BENEFICIARY-ID      |
                     |   3  | TRANSACTION-ID      |
                     |   4  | FLOOR-REQUEST-ID    |
                     |   5  | HUMAN-READABLE-INFO |
                     |   6  | DIGEST              |
                     |   7  | REQUEST-STATUS      |
                     |   8  | ERROR-CODE          |
                     |   9  | USER-DISPLAY-NAME   |
                     |  10  | USER-URI            |
                     |  11  | PRIORITY            |
                     |  12  | NONCE               |
                     |  13  | SUPPORTED-TLVS      |
                     +------+---------------------+

                        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 format
   '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.

   Attribute Contents: the contents of the USER-ID attribute,
   whose attribute type different TLVs are defined in
   the following sections.

5.2.1  FLOOR-ID

   The following is 2. the format of the 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 2   |M|    Length     |            User
     |0 0 0 0 0 0 0|M|0 0 0 0 0 1 0 0|           Floor ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   User

                       Figure 7: FLOOR-ID format

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

5.2.3  BENEFICIARY-ID

5.2.2  USER-ID

   The following is the format of the contents of the BENEFICIARY-ID
   attribute, whose attribute type is 2. 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 2   |M|    Length     |        Beneficiary
     |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0|            User ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Beneficiary

                        Figure 8: USER-ID format

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

5.2.4  TRANSACTION-ID

5.2.3  BENEFICIARY-ID

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

                    Figure 9: BENEFICIARY-ID format

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

5.2.4  TRANSACTION-ID

   The following is the format of the TRANSACTION-ID
   attribute, whose attribute type is 3. 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 3   |M|    Length     |
     |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0|        Transaction ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 10: TRANSACTION-ID format

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

5.2.5  FLOOR-REQUEST-ID

   The following is the format of the contents of the FLOOR-REQUEST-ID
   attribute, whose attribute type is 4. 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 3   |M|    Length     |
     |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|       Floor Request ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 11: FLOOR-REQUEST-ID format

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

5.2.6  HUMAN-READABLE-INFO

   The following is the format of the contents of the HUMAN-READABLE-INFO attribute, whose attribute type is 5. 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 4   |M|
     |0 0 0 0 1 0 1|M|    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     /                             Text                              /
     /                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 12: HUMAN-READABLE-INFO format

   Text: this field contains UTF-8 [13] [5] 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 that the
   contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned.  The
   Padding bits SHOULD be set to zero by the sender and MUST be ignored
   by the receiver.  If the TLV is already 32-bit aligned, no padding is
   needed.

5.2.7  INTEGRITY  DIGEST

   The following is the format of the contents of the INTEGRITY
   attribute, whose attribute type is 6. 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 5   |M|    Length     |
     |0 0 0 0 1 1 0|M|0 0 0 1 1 0 0 0|                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     +                                                               +
     |                                                               |
     +                          HMAC-SHA1                            +
     |                                                               |
     +                                                               +
     |                                                               |
     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |             Padding           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 13: DIGEST format

   HMAC-SHA1: this 20-byte field contains an HMAC-SHA1 [1] of the BFCP
   message.  Its calculation is described in Section 10. 9.

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

5.2.8  REQUEST-STATUS

   The following is the format of the contents of the REQUEST-STATUS
   attribute, whose attribute type is 7. 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 6   |M|    Length     |        Request
     |0 0 0 0 1 1 1|M|0 0 0 0 0 1 0 0|Request Status         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Queue |Queue Position |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 14: REQUEST-STATUS format

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

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

                     Table 3: Request Status values

   Queue Position: this 16-bit 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.

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

5.2.9  ERROR-CODE

   The following is the format of the contents of the ERROR-CODE
   attribute, whose attribute type is 8. 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 7   |M|
     |0 0 0 1 0 0 0|M|    Length     |          Error Code           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                     Error Specific Details                    |
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 15: ERROR-CODE format

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

   +---------------------------------+---------------------------------+
   |              Value              | Meaning
     __________________________________________________________                         |
   +---------------------------------+---------------------------------+
   |                0                | Conference does not Exist       |
   |                1                | Authentication Failed           |
   |                2                | Unknown Mandatory TLV           |
   |                3                | Floor Request ID Does Not Exist |
   |                4                | Unauthorized Operation          |
   |                5                | User does not Exist             |
   |                6                | Invalid Request-ID Nonce                   |
   |                7          INTEGRITY                | DIGEST TLV Required             |
   |                8                | Invalid Floor ID                |
   |                9                | You have Already Reached 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
   this document, only for Error Code 2 (Unknown Mandatory TLV).  For
   Error Code 2, this field contains the Types of the TLVs (which were
   present TLVs (which were
   present in the message that triggered the Error message) that were
   unknown to the receiver, encoded as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Unknown TLV Type         |      Unknown TLV Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      Unknown TLV Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Unknown TLV Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 16: Unknown TLVs format

   Padding: one, two, or three bytes of padding added so that the
   contents of the ERROR-CODE TLV 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.  Note all the 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).  Error Code 2 results in a TLV
   that may need 2 bytes of padding.

5.2.10  USER-DISPLAY-NAME

   The format of the USER-DISPLAY-NAME attribute 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 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.

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

                       Figure 17: PRIORITY format

   Priority: the higher the 8-bit value, the more priority is requested
   for a given floor request.

   Reserved: at this point, the 8 bits in the reserved field SHOULD be
   set to zero by the sender of the message and MUST be ignored by the
   receiver.

5.2.13  NONCE

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

                        Figure 18: NONCE format

   Nonce Value: this 16-bit field contains a nonce.

5.2.14  SUPPORTED-TLVS

   The following is the format of the SUPPORTED-TLVS 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     |         Supported TLV         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Supported TLV         |         Supported TLV         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 19: SUPPORTED-TLVS format

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

   Padding: two bytes of padding added so that the contents of the
   SUPPORTED-TLVS TLV 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 the floor control server.  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]

                     Figure 20: 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)
                    (TRANSACTION-ID)
                    (USER-ID)
                    (FLOOR-REQUEST-ID)
                    [NONCE]
                    [DIGEST]

                     Figure 21: 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)
                              (TRANSACTION-ID)
                              (USER-ID)
                              [BENEFICIARY-ID]
                              [FLOOR-REQUEST-ID]
                              [NONCE]
                              [DIGEST]

                Figure 22: 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)
                          (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 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)
                       (TRANSACTION-ID)
                       (USER-ID)
                      *(FLOOR-ID)
                       [NONCE]
                       [DIGEST]

                   Figure 24: FloorInfoWanted format

5.3.6  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)
                            [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 to floor control servers by sending
   ChairAction messages.  The following 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 a ChairAction
   message by sending a ChairActionAck message.  The following 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 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)
                    [NONCE]
                    [DIGEST]

                        Figure 28: Hello format

5.3.10  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-TLVS)
                    [NONCE]

                       Figure 29: HelloAck format

5.3.11  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]
                          [HUMAN-READABLE-INFO]

                        Figure 30: 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 TLVs.

   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.  The floor control server MAY cancel all
   the floor participant's floor requests or it MAY keep them while the
   TCP connection is re-established.  Connection re-establishment is
   handled in different ways depending on how the client obtains
   information to contact the floor control server (as described in
   Section 3.2, two possibilities are CPCP and an offer/answer
   exchange).

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 .

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 TLV 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 message that triggered FIXED-HEADER of the Error message) that were
   unknown message to the receiver, encoded as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Unknown TLV Type         |      Unknown TLV Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      Unknown TLV Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Unknown TLV Type         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Padding: one, two, or three bytes of padding added so Conference ID
   for the conference that the
   contents of client obtained previously.

   The client MUST set the ERROR-CODE TLV is 32-bit aligned.  If Transaction ID value in the TRANSACTION-ID
   TLV is
   already 32-bit aligned, no padding is needed.

   The Padding bits SHOULD be set to zero by the sender and a number which MUST NOT be
   ignored by reused in another message from the receiver.  Note all
   client until a response from the Error Codes defined in server is received for the
   transaction.  The client uses the Transaction ID value to match this
   document but Error Code 2, result in
   message with the response from the floor control server.

8.2  Server Behavior

   A floor control server sending a TLV which is already 32-bit
   aligned (i.e., no need of padding).  Error Code 2 results in response within a TLV
   that may need 2 bytes of padding.

5.2.10  USER-DISPLAY-NAME

   The USER-DISPLAY-NAME attribute type is 9 client-initiated
   transaction MUST copy the Conference ID, the TRANSACTION-ID TLV, and its format is
   the same
   as USER-ID TLV from the HUMAN-READABLE-INFO attribute.  The Text field in request received from the
   USER-DISPLAY-NAME attribute contains client into the name
   response.  Server-initiated transactions MUST NOT contain a
   TRANSACTION-ID TLV.

9.  Authentication and Authorization

   BFCP uses the DIGEST TLV to provide client authentication.  The
   DIGEST TLV contains an HMAC-SHA1 [1] of the user.

5.2.11  USER-URI BFCP message.  The USER-URI attribute type use of
   SHA1 implies that the length of the HMAC is 10 and its format 20 bytes.  The text used
   as input to HMAC is the same as BFCP message, including the
   HUMAN-READABLE-INFO attribute.  The Text field in FIXED-HEADER, up
   to and including the USER-URI
   attribute contains TLV preceding the URI DIGEST TLV.  This text is then
   padded with zeroes so as to be a multiple of 64 bytes.  As a result,
   the user.

5.2.12  PRIORITY DIGEST TLV MUST be the last attribute in any BFCP message.  The following
   key used as input to HMAC is the format of secret shared between the contents of server and
   the PRIORITY
   attribute, whose attribute type is 11.

      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 = 7   |M|    Length     |   Priority    |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Priority: user identified by the higher USER-ID TLV in the 8-bit value, message.

9.1  Client Behavior

   Clients can authenticate floor control servers by checking the floor
   control server's certificate when the TLS connection is established
   between them.

   To achieve client authentication, a client needs to prove to the
   floor control server that the more priority is requested client can produce a DIGEST TLV for a given floor request.

   Reserved: at this point,
   message using their shared secret and that the 8 bits in message is fresh (to
   avoid replay attacks).  Clients prove the reserved field SHOULD be
   set to zero freshness of a message by
   including a NONCE TLV in the sender of message.  The NONCE TLV is the second to
   last TLV in the message and MUST be ignored by (the last one is the
   receiver.

6.  Message Format

   This section contains DIGEST TLV).

   The nonce in the ABNF [3] of NONCE TLV is provided by the BFCP messages.

6.1  FloorRequest

   Clients request a floor by sending control server
   using an out-of-band mechanism (e.g., using an offer/answer exchange
   as described in [15]), or in an Error response -- typically with
   Error Code 7 (DIGEST TLV Required) or 6 (Invalid Nonce).

   A client that obtains a FloorRequest nonce out-of-band SHOULD add a NONCE TLV and
   a DIGEST TLV to the first message it sends to the floor control
   server.  In addition,  Furthermore, if a client generates a message without this
   TLV and receives an Error response with Error Code 7 (DIGEST TLV
   Required), the client SHOULD re-send the FloorRequest message with a DIGEST TLV
   and a NONCE TLV with the nonce received 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 the message using the new nonce received in the Error
   response.  If the Error Code is also
   used to modify existing floor requests.  The following is 1 (Authentication Failed) instead,
   the format
   of client MUST NOT send further messages to the FloorRequest message:

   FloorRequest =   (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    [BENEFICIARY-ID]
                    [FLOOR-REQUEST-ID]
                   *(FLOOR-ID)
                    [HUMAN-READABLE-INFO]
                    [PRIORITY]
                    [INTEGRITY]

6.2  FloorRelease

   Clients release floor control server
   until it has obtained a different (hopefully valid) shared secret
   than the one used in the original message.

   If a floor by sending client receives a nonce in a FloorRelease message to from the floor control server.  Clients also use the FloorRelease message to
   cancel pending floor requests.  The following is the format of
   server, the
   FloorRelease message:

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

6.3  FloorRequestInfo

   Clients request information about client SHOULD add a floor request by sending NONCE TLV with this nonce and a
   FloorRequestInfo
   DIGEST TLV to its next message to the floor control server.  The following
   is the format of

9.2  Floor Control Server Behavior

   Before accepting any BFCP message, the FloorRequest message:

   FloorRequestInfo =   (FIXED-HEADER)
                        (TRANSACTION-ID)
                        (USER-ID)
                        [BENEFICIARY-ID]
                        [FLOOR-REQUEST-ID]
                        [INTEGRITY]

6.4  FloorRequestStatus

   The floor control server informs clients about the status of their
   floor requests by sending them FloorRequestStatus messages.  The
   following is SHOULD
   authenticate the format of client.  If the FloorRequestStatus message:

   FloorRequestStatus =   (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)     )
                          [INTEGRITY]

6.5  FloorInfo

   Clients request information about a floor or floors by sending control server receives a
   FloorInfo
   message to without DIGEST TLV from an unauthenticated client, the floor
   control server. server responds with an Error message with Error Code 7
   (DIGEST TLV Required).  The following floor control message MUST include a
   NONCE TLV with a nonce value that is the
   format of the FloorRequest message:

   FloorInfo =   (FIXED-HEADER)
                 (TRANSACTION-ID)
                 (USER-ID)
                *(FLOOR-ID)
                 [INTEGRITY]

6.6  FloorStatus

   The unguessable by attackers.

   When a floor control server informs clients about the status, e.g., receives a BFCP message with a DIGEST
   TLV, it checks whether the
   current holder(s), of NONCE TLV carries a floor nonce which was
   generated by sending them FloorStatus messages.
   The following is the format of floor control server for this client and which still
   has not expired.  If the FloorStatus message:

   FloorStatus        =     (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)      )
                            [INTEGRITY]

6.7  ChairAction

   Chairs send instructions nonce is not valid, authentication is
   considered to have failed, in which case the floor control servers by sending
   ChairAction messages.  The following server
   SHOULD return an Error message with Error Code 6 (Invalid Nonce) with
   a new nonce in a NONCE TLV.

   If the nonce is valid, the format floor control server calculates the
   HMAC-SHA1 [1] of the ChairAction
   message:

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

6.8  ChairActionAck

   Floor control servers condirm that they have accepted a ChairAction message by sending a ChairActionAck message. excluding the DIGEST TLV.  The following key used
   as input to HMAC is the
   format of the ChairActionAck message:

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

6.9  Ping

   Clients check secret shared between the liveness of servers, server and servers of clients, the user
   identified by
   sending a Ping the USER-ID TLV in the message.  The following  If the resulting value
   is the format of same as the Ping
   message:

   Ping         =   (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    [INTEGRITY]

6.10  PingAck

   Servers confirm one in the DIGEST TLV, authentication is
   considered successful.

   If the resulting value is different than the one in the DIGEST TLV,
   authentication is considered to have failed, in which case the server
   SHOULD return an Error message, as described in Section 13.7, with
   Error Code 1 (Authentication Failed).  Messages from a client that they are alive on reception of
   cannot be authenticated MUST NOT be processed further.

   Floor control servers may include a Ping NONCE TLV in their responses to
   provide the nonce to be used in the next message by
   sending a PingAck message.  The following the client.
   However, when TLS is used, floor control servers typically
   authenticate only the format of first message sent over the TLS connection.

   After authenticating a BCFP message, the
   PingAck message:

   PingAck      =   (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    [INTEGRITY]

6.11  Error

   The floor control server informs clients about errors processing
   requests by sending them Error messages.  The following checks
   whether or not the client is authorized to perform the operation it
   is requesting.  If the format
   of client is not authorized to perform the
   operation being requested, the floor control server generates an
   Error message:

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

7.  Transport

   BFCP entities exchange BFCP messages using TCP connections.  TCP
   provides message, as described in Section 13.7, with an in-order reliable delivery of Error code with
   a stream value of bytes.
   Consequently, message framing is implemented in the application
   layer.  BFCP implements application-layer framing using TLVs.

   Editor's note: We need to address how to handle lost TCP connections
   (e.g., 4 (Unauthorized Operation).  Messages from a client that the TCP connection will
   cannot be re-established in this case
   using O/A 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 further below).

8.  Lower-Layer Security

   BFCP relies on lower-layer security mechanisms in earlier sections.  Section 11 specifies operations that
   are specific to provide replay
   protection, and confidentiality.  BFCP servers MUST support TLS [4], floor chairs, such as instructing the floor control
   server to grant or revoke a floor, and clients SHOULD support TLS.  Clients Section 12 specifies
   operations that can be performed by any client (i.e., both floor
   participants and servers MAY support
   other security mechanisms.

   OPEN ISSUE: do we want floor chairs).

10.1  Requesting a Floor

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

10.1.1  Sending a FloorRequest Message

   The ABNF in Section 5.3.1 describes the protocol
   instead of relying on TLS?

   Servers and clients TLVs that implement TLS MUST support TBD.  (cypher a FloorRequest
   message can contain.  In addition, the ABNF specifies normatively
   which of these TLVs are mandatory, and
   hash algorithm).

9.  Protocol Transactions

   In BFCP, there which ones are two types of transactions: client-initiated
   transactions optional.

   The floor participant sets the Conference ID in the FIXED-HEADER and server-initiated transactions (notifications).
   Client-initiated transactions consist of a request from a client
   the TRANSACTION-ID TLV following the rules given in Section 8.1.
   Additionally, the floor participant follows the rules in Section 9.1
   which relate to a
   server and a response from the server authentication of the message (i.e., to the client.
   DIGEST TLV).

   The request
   carries floor participant must insert a TRANSACTION-ID TLV USER-ID TLV, which will be used
   by the floor control server copies into the
   response.  Clients use Transaction ID values to match responses with
   previously-issued requests.

   Server-initiated transactions consist authenticate and authorize the
   request.  If the sender of a single the FloorRequest message from (identified by
   the USER-ID TLV) is not the participant that would eventually get the
   floor (i.e., a
   server 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 client.  Consequently, since they do not trigger any
   response, server-initiated transactions do not have Transaction IDs
   associated with them.

9.1  Client Behavior

   A client starting given participant is identified by a client-initiated transaction MUST set
      single 16-bit value that can be used in USER-ID 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 floor requests as
   an atomic package.  That is, the
   Conference ID in floor control server will either
   grant or deny all the FIXED-HEADER of floors in the message FloorRequest message.

   The floor participant may use a HUMAN-READABLE-INFO TLV to state the Conference ID
   for the conference that
   reason why the client obtained previously. floor or floors are being requested.  The client MUST set the Transaction ID value Text field
   in the TRANSACTION-ID HUMAN-READABLE-INFO TLV is intended for human consumption.

   The floor participant may request the server to handle the floor
   request with a number which MUST NOT be reused in another certain priority using a PRIORITY TLV.

10.1.2  Receiving a Response

   A message from the
   client until floor control server is considered to be a
   response to the FloorRequest message if the message from the floor
   control server is received.  The client uses has the same Conference ID, Transaction ID, and User
   ID value to match this as the FloorRequest message, as described in Section 8.1.

   The successful processing of a FloorRequest message with the
   response from at the floor
   control server.

9.2  Server Behavior

   A server sending involves generating one or several FloorRequestInfo
   messages.  The floor participant obtains a response within Floor Request ID in a client-initiated transaction
   MUST copy
   FLOOR-REQUEST-ID TLV in the Conference ID and first FloorRequestInfo message from the TRANSACTION-ID TLV
   floor control server.  Subsequent FloorRequestInfo messages from the
   floor control server regarding the same floor request received from will carry the client into
   same Floor Request ID as the response.  Server-initiated
   transactions MUST NOT contain a TRANSACTION-ID TLV.

10.  Authentication

   BFCP uses initial FloorRequestInfo message.  This
   way, the INTEGRITY TLV to provide client and server
   authentication, and message integrity. floor participant can associate subsequent incoming
   FloorRequestInfo messages with the ongoing floor request.

   The INTEGRITY floor participant obtains information about the status of the
   floor request in the REQUEST-STATUS TLV contains an
   HMAC-SHA1 [1] of the BFCP message.  The use each of SHA1 implies that the
   length of
   FloorRequestInfo messages received from the HMAC floor control server.  If
   the Request Status value is 20 bytes.  The text used as input to HMAC Granted, all the floors that were
   requested in the FloorRequest message have been granted.  If the
   Request Status value is Denied, all the BFCP message, including floors that were requested in
   the FIXED-HEADER, up to and including FloorRequest message have been denied.  The HUMAN-READABLE-INFO
   TLV, if present, provides extra information which the
   TLV preceding floor
   participant MAY display to the INTEGRITY TLV.  This text user.

   A floor request is then padded with
   zeroes so as considered to be a multiple of 64 bytes.  As a result, ongoing while it is in the
   INTEGRITY TLV MUST be
   Pending, Accepted, or Granted states.

   If the last attribute in any BFCP message.  The
   key used as input to HMAC response is an Error message, the secret shared between the floor control server and
   the user identified by could
   not process the USER-ID TLV FloorRequest message for some reason, which is
   described in the Error message.

10.1  Client Behavior

   Clients SHOULD add

10.2  Cancelling a Floor Request and Releasing a Floor

   A floor participant that wishes to cancel an INTEGRITY TLV ongoing floor request
   does so by sending a FloorRelease message to all their messages.
   Furthermore, if the floor control
   server.  The FloorRelease message is also used by floor participants
   that hold a client generates floor and would like to release it.

10.2.1  Sending a FloorRelease Message

   The ABNF in Section 5.3.2 describes the TLVs that a FloorRelease
   message without this TLV and
   receives an Error response with Error Code 7 (INTEGRITY TLV
   Required), can contain.  In addition, the ABNF specifies normatively
   which of these TLVs are mandatory, and which ones are optional.

   The floor participant sets the client SHOULD NOT send more messages without Conference ID in the FIXED-HEADER and
   the
   INTEGRITY TRANSACTION-ID TLV to following the same server within rules given in Section 8.1.
   Additionally, the same conference.

   When a client receives a BFCP message with an INTEGRITY TLV, it
   calculates floor participant follows the HMAC-SHA1 [1] rules in Section 9.1
   which relate to the authentication of the message excluding (i.e., to the INTEGRITY
   TLV.
   DIGEST TLV).  The key floor participant must insert a USER-ID TLV, which
   will be used as input by the floor control server to HMAC is authenticate and
   authorize the secret shared between request.

      Note that the
   server FloorRelease message is used to release a floor or
      floors that were granted and to cancel ongoing floor requests
      (from the user identified by protocol perspective both are ongoing floor requests).
      Using the USER-ID TLV same message in both situations helps resolve the message.  If race
      condition that occurs when the resulting value is FloorRelease message and the same as
      FloorGrant message cross each other on the one wire.

   The floor participant uses the FLOOR-REQUEST-ID that was received in
   the INTEGRITY TLV,
   authentication is considered successful.  If response to the resulting value FloorRequest message that the FloorRelease
   message is
   different than cancelling.

      Note that if the one floor participant requested several floors as an
      atomic operation (i.e., in a single FloorRequest message), all the INTEGRITY TLV, authentication is
   considered to have failed and the message MUST NOT be processed
   further.

10.2  Server Behavior

   Servers SHOULD add
      floors are released as an INTEGRITY TLV to atomic operation as well (i.e., all their messages.
   Furthermore, if a client sends messages with this TLV to are
      released at the same time).

10.2.2  Receiving a server, Response

   A message from the floor control server MUST include it as well in its messages is considered to this client.

   If be a client does not add an INTEGRITY TLV
   response to a message, the server
   MAY request its addition by returning an Error message with Error
   Code 7 (INTEGRITY TLV Required).

   When a server receives a BFCP FloorRelease message with an INTEGRITY TLV, it
   calculates the HMAC-SHA1 [1] of if the message excluding the INTEGRITY
   TLV.  The key used as input to HMAC is the secret shared between from the floor
   control server and has the user identified by same Conference ID, Transaction ID, and User
   ID as the USER-ID TLV FloorRequest message, as described in the message. Section 8.1.

   If the resulting value response is a FloorRequestInfo message, the same as the one Request Status
   value in the INTEGRITY TLV,
   authentication is considered successful. REQUEST-STATUS-TLV will be Cancelled or Released.

   If the resulting value response is different than an Error message, the one in floor control server could
   not process the INTEGRITY
   TLV, authentication FloorRequest message for some reason, which is considered to have failed,
   described in which case the
   server SHOULD return an Error message.

   It is possible that the FloorRelease message crosses on the wire with Error Code 1
   (Authentication Failed).  Messages that cannot be authenticated MUST
   NOT
   a FloorRequestInfo message from the server with a Request Status
   different from Cancelled or Released.  In any case, such a
   FloorRequestInfo message will not be processed further. a response to the FloorRelease
   message, because its Transaction ID will not match that of the
   FloorRelease.

11.  Client  Chair Operations

   This section specifies how clients floor chairs can perform different operations,
   such as requesting a floor, using the protocol elements described in
   earlier sections.  Chair operations, such as instructing instruct the floor
   control server to grant or revoke a floor, are floor using the protocol elements
   described in Section 16.

11.1  Requesting a earlier sections.

   Floor

   A client chairs that wishes wish to request one or more floors does send instructions to a floor control server
   do so by sending a FloorRequest message to the floor control server. ChairAction message.

11.1  Sending a ChairAction Message

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

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

   The ChairAction message (identified by the USER-ID TLV) is
   not the same as the user requesting the floor (i.e., contains instructions that apply to one or
   more floors within a third party particular floor request), the client SHOULD add a BENEFICIARY-ID TLV to the
   message identifying the beneficiary of the floor. request.  The client must insert at least one floor or floors
   are identified by FLOOR-ID TLV TLVs and the floor request is identified
   by a FLOOR-REQUEST-ID TLV, which are carried in the FloorRequest ChairAction
   message.  If

      For example, if a floor request consists of two floors that depend
      on different floor chairs, each floor chair will grant its floor
      within the client inserts more than one FLOOR-ID TLVs, floor request.  Once both chairs have granted their
      floor, the floor control server will treat all grant the floor requests request as an atomic package.  That
   is, a
      whole.  On the other hand, if one of the floor chairs denies its
      floor, the floor control server will either grant or deny all the floor request as a
      whole, regardless of the other floor chair's decision.

   The floor chair provides the new status for one or more floors
   in within
   the floor request using a REQUEST-STATUS TLV.  If the new status of
   the floor request is Accepted, the FloorRequest message.

   The client may floor chair MAY use a HUMAN-READABLE-INFO TLV the Queue
   Position field to state provide a queue position for the reason why floor request.  If
   the floor or floors are being requested.  The Text field in chair does not wish to provide a queue position, all the
   HUMAN-READABLE-INFO TLV is intended for human consumption.
   bits of the Queue Position field SHOULD be set to zero.  The client may request floor
   chair SHOULD use the server Status Revoked to handle revoke a floor that was
   granted (i.e., Granted status) and the Status Denied to reject floor
   requests in any other status (e.g., Pending and Accepted).

      Note that a floor request with may involve several floors and that a
   certain priority using
      ChairAction message may only deal with a PRIORITY TLV.

11.1.1  Receiving subset of these floors
      (e.g., if a Response

   A message from the server single floor chair is considered to be a response not authorized to manage all the
   FloorRequest message if the message from the server has
      floors).  In this case, the same
   Conference ID and Transaction ID as REQUEST-STATUS that the FloorRequest message, as
   described floor chair
      provides in Section 9.1.

   If the response is a FloorRequestStatus message, the client obtains
   information about ChairAction message might not be the actual status of
      that the FloorRequest in a REQUEST-STATUS
   TLV.  If floor request gets at the Request Status value is Granted, server.  The floor control
      server will combine the client has been
   granted all instructions received from the floors that were requested in different
      floor chairs to come up with the FloorRequest
   message.  If actual status of the Request Status value is Denied, floor
      request.

   The floor chair may use a HUMAN-READABLE-INFO TLV to state the client has been
   denied all reason
   why the floor or floors that were requested are being accepted, granted, or revoked.  The
   Text in the FloorRequest
   message.  The HUMAN-READABLE-INFO TLV, if present, provides extra
   information which the client MAY display to the user. TLV is intended for human
   consumption.

11.2  Receiving a Response

   A message from the floor request control server is considered to be ongoing while it is in the
   Pending, Accepted, or Granted states.  FloorRequestStatus messages
   carrying any of these states will contain a FLOOR-REQUEST-ID TLV.
   The value of this TLV is used
   response to match subsequent messages received
   at the client side (e.g., further FloorRequestStatus messages) or at ChairAction message if the message from the server side (e.g., a FloorRelease message) with this
   has the same Conference ID, Transaction ID, and User ID as the
   ChairAction message, as described in Section 8.1.

   A ChairActionAck message from the floor
   request.

   If control server confirms that
   the response is an floor control server has accepted the ChairAction message.  An
   Error message, message indicates that the floor control server could not
   process the
   FloorRequest 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 participants or
   floor chairs.  They can be performed by both.

12.1  Requesting Information about Floor Requests 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 current status of one or several floor request floors
   by sending a FloorRequestInfo 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 9.1. 8.1.
   Additionally, the client follows the rules in Section 10.1 9.1 which
   relate to the authentication and the protection of the integrity of
   the message (i.e., to the INTEGRITY 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.

   If the

   The client wants to request the status of a single floor request,
   it MUST insert a FLOOR-REQUEST-ID TLV that identifies inserts in the floor
   request at message all the server. Floor IDs it wants to
   receive information about.  The client can also request floor control server will send
   periodic information about all the ongoing floor
   requests associated with a particular user.  In this case, the client
   MUST NOT insert a FLOOR-REQUEST-ID TLV. these floors.  If the beneficiary of the
   floor requests the client is requesting does not
   want to receive information about is not the
   client issuing the FloorRequestInfo message (which is identified by
   the USER-ID TLV in the message) the client SHOULD insert a
   BENEFICIARY-ID TLV.

12.1  Receiving a Response

   On reception of the FloorRequestInfo message, the server will respond
   with a FloorRequestStatus message or with an error message.  That is,
   the server will respond using the same message types as when particular floor any longer, it
   receives
   sends a FloorRequest message.  Consequently, after sending the
   FloorRequestInfo message, the client follows the steps described in
   Section 11.1.1.

   If the FloorRequestInfo new FloorInfoWanted message requested information about several
   floor requests, removing the FloorRequestStatus message will contain
   information about all FLOOR-ID of them.

13.  Cancelling a Floor Request and Releasing a Floor

   A this
   floor.  If the client that wishes to cancel an ongoing floor request does so by
   sending a FloorRelease message not want to the receive information about any
   floor control server.  The ABNF
   in Section 6.2 describes the TLVs that any longer, it sends a FloorRelease FloorInfoWanted message can
   contain.  In addition, the ABNF specifies which of these TLVs are
   mandatory, and which ones are optional.

   The client sets with no FLOOR-ID
   TLV.

12.1.2  Receiving a Response

   A message from the Conference ID in floor control server is considered to be a
   response to the FIXED-HEADER and FloorInfoWanted message if the
   TRANSACTION-ID TLV following message from the rules given in Section 9.1.
   Additionally, floor
   control server has the client follows same Conference ID, Transaction ID, and User
   ID as the rules FloorRequest message, as described in Section 10.1 which
   relate to the authentication and the protection 8.1.

   On reception of the integrity of FloorInfoWanted message, the floor control server
   will respond with a FloorInfo message (i.e., to or with an Error message.  If
   the INTEGRITY TLV).  The client must insert response is a
   USER-ID TLV, which FloorInfo message, it will be used by contain information
   about one of the server to authenticate and
   authorize floors the request.

      Note that client requested information about.  If
   the FloorRelease client did not include any FLOOR-ID TLV in its FloorInfoWanted
   message, the FloorInfo message is also used to release from the floor control server will not
   include any either.

   FloorInfo messages which carry information about a floor contain a
   FLOOR-ID TLV that identifies the floor.  After this TLV, FloorInfo
   messages contain information about existing (one or floors more) floor
   request that were granted relate to that floor.  The information about each
   particular floor request consist of a FLOOR-REQUEST-ID TLV that
   identifies the client (from the protocol
      perspective both are ongoing floor requests).  Using request followed by a set of TLVs that provide
   information about the same
      message in both situations helps resolve floor request.

   After the race condition that
      occurs when first FloorInfo, the FloorRelease message and floor control server will continue
   sending FloorInfo messages periodically informing the FloorGrant message
      cross each other client about
   changes on the wire.

   The floors the client requested information about.

12.2  Requesting Information about Floor Requests

   A client uses can obtain information about the FLOOR-REQUEST-ID that was received status of one or several
   floor requests in the
   response different ways, which include using BFCP and using
   out-of-band mechanisms.  Clients using BFCP to obtain such
   information use the FloorRequest message that procedures described in this section.

   Clients request information about the FloorRelease current status of one or
   several floor requests by sending a FloorRequestInfoWanted message to
   the floor control server.

      Requesting information about a particular floor request is
   cancelling.

13.1  Receiving useful
      in a Response

   On number of situations.  For example, on reception of the FloorRelease a
      FloorRequest message, the server will respond as
   with a FloorRequestStatus message or with an error message.  That is,
   the floor control server will respond using the same message types as may choose to return
      FloorRequestInfo messages only when it
   receives a FloorRequest message.  Consequently, after sending the
   FloorRelease message, the client follows floor request changes its
      state (e.g., from Accepted to Granted), but not when the steps described floor
      request advances in
   Section 11.1.1.

   It is possible that its queue.  In this situation, if the FloorRelease message crosses on user
      requests it, the wire with floor participant can use a FloorRequestStatus
      FloorRequestInfoWanted message from to poll the floor control server with a Request Status
   different from Cancelled.  In any case, such a FloorRequestStatus
   message will not
      for the status of the floor request.
      FloorRequestInfoWanted messages can also be a response used to request
      information on all the FloorRelease message, because floor requests associated with a floor
      participant.  For example, a floor participant, after experiencing
      connectivity problems (e.g., its Transaction ID will not match that of TCP connection with the FloorRelease.

14.  Requesting Information about Floors

   Clients floor
      control server was down for a while and eventually was
      re-established), may need to request information about all the status of one or several floors
   by sending a FloorInfo message
      still existing floor requests associated to the floor control server. participant.

12.2.1  Sending a FloorRequestInfoWanted Message

   The ABNF in Section 5.3.3 describes the TLVs that a
   FloorRequestInfoWanted 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 9.1. 8.1.
   Additionally, the client follows the rules in Section 10.1 9.1 which
   relate to the authentication and the protection of the integrity of the message (i.e., to the INTEGRITY 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

   If the FLOOR-IDs it client wants to
   receive information about. 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 server will send periodic client can also request information about all these floors.  If the client does not want to receive
   information about ongoing floor
   requests associated with a particular floor any longer, it sends participant.  In this case, the
   client MUST NOT insert a new
   FloorInfo message removing FLOOR-REQUEST-ID TLV.  If the FLOOR-ID beneficiary of this floor.  If
   the floor requests the client
   does not want to receive is requesting information about any floor, it sends a
   FloorInfo is not
   the client issuing the FloorRequestInfoWanted message with no FLOOR-ID (which is
   identified by the USER-ID TLV in the message) the client MUST insert
   a BENEFICIARY-ID TLV.

14.1

12.2.2  Receiving a Response

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

   On reception of the FloorInfo message, the server will respond with a
   FloorStatus message or with an Error message. 8.1.

   If the response is a
   FloorStatus FloorRequestInfo message, it the client obtains
   information about the status of the FloorRequest the client requested
   information about in a REQUEST-STATUS TLVs.  If the client requested
   information 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 contain include a
   REQUEST-STATUS TLV) providing information about one of the
   floors floor request
   identified by the client requested information about. FLOOR-REQUEST-ID TLV.

   If the client did not
   include any FLOOR-ID in its FloorInfo response is an Error message, the FloorStatus
   message from the floor control server will could
   not include any either.

   After the first FloorStatus, the server will continue sending
   FloorStatus messages periodically informing the client about changes
   on process the floors FloorRequestInfoWanted message for some reason, which
   is described in the client requested information about.

15.  Checking Error message.

12.3  Obtaining the Liveness Capabilities of a Floor Control Server

   A client that wishes to check obtain the liveness capabilities of a floor control
   server does so by sending a Ping Hello message to the floor control
   server.

12.3.1  Sending a Hello Message

   The ABNF in Section 6.9 5.3.9 describes the TLVs that a Ping Hello 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 9.1. 8.1.
   Additionally, the client follows the rules in Section 10.1 9.1 which
   relate to the authentication and the protection of the integrity of
   the message (i.e., to the INTEGRITY DIGEST TLV).

15.1  The client must insert a
   USER-ID TLV, which will be used by the floor control server to
   authenticate and authorize the request.

12.3.2  Receiving Responses

   A message from the floor control server is considered a response to
   the Ping Hello message by the client if the message from the floor control
   server has the same Conference ID and ID, Transaction ID, and User ID as the Ping
   Hello message, as described in Section 9.1. 8.1.

   If the response is a PingAck HelloAck message, the floor control server is alive and could
   process successfully the
   user identified Hello message.  The SUPPORTED-TLVS TLV
   indicates which TLVs are supported by the User ID was authenticated successfully. server.

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

16.  Chair

13.  Floor Control Server Operations

   This section specifies how clients acting as chairs floor control servers can perform
   different operations, such as instructing the floor server to grant
   or revoke granting a floor, using the protocol
   elements described in earlier sections.

16.1  Obtaining Information about Floor Requests

   A chair can obtain information about the floor requests that the
   floor control server receives in different ways, which include using
   out-of-band mechanisms.  Chairs using BFCP to obtain such information
   use the procedures described in Section 14.  As a result, they
   receive information about floor requests that relate to specific
   floors in FloorStatus messages from the floor control server.

16.2  Instructing the Floor Control Server

   Chairs that wish to send instructions to a floor control server does
   so by sending a ChairAction message.  The ABNF in Section 6.7
   describes the TLVs that

   On reception of a ChairAction message can contain.  In
   addition, from a client, the ABNF specifies which floor control server
   MUST check whether or not the value of these TLVs are mandatory, and
   which ones are optional.

   The chair sets the Conference ID in the FIXED-HEADER and the
   TRANSACTION-ID TLV following matched an
   existing conference.  If it does not, the rules given floor control server SHOULD
   send an Error message, as described in Section 9.1.
   Additionally, 13.7, with Error code
   0 (Conference does not Exist).

   On reception of a message from a client, the chair floor control server
   follows the rules in Section 10.1 9.2, which relate to the authentication and the protection
   of the integrity message.

   On reception of
   the message (i.e., to the INTEGRITY TLV).  The client must insert a
   USER-ID TLV, which will be used by the server to authenticate and
   authorize the request.

   The ChairAction message contains instructions that apply to one or
   more floors within from a particular floor request.  The client, the floor control server
   MUST check whether or floors
   are identified by FLOOR-ID TLVs and not it understands all the floor request is identified
   by a FLOOR-REQUEST-ID TLV, which are carries mandatory ( 'M' bit
   set) TLVs in the ChairAction message.

      For example, if a floor request consists of two floors that depend
      on different chairs, each chair will grant its floor within the
      floor request.  Once both chairs have grant their floor,  If the floor control server will grant does not
   understand all of them, the floor request control server SHOULD send an Error
   message, as described in Section 13.7, with Error code 2
   (Authentication Failed).  The Error message SHOULD list the TLVs that
   were not understood.

13.1  Reception of a whole. FloorRequest Message

   On reception of a FloorRequest message, the floor control server
   follows the
      other hand, if one of rules in Section 9.2 which relate to client
   authentication and authorization.  If while processing the chairs denies its floor,
   FloorRequest message, the floor control server will deny encounters an error,
   it SHOULD generate an Error response following the procedures
   described in Section 13.7

      BFCP allows floor request as a whole, regardless
      of participants to have several ongoing floor
      requests for the other chair's decision.

   The chair provides same floor (e.g., the new status for one or same floor participant can
      occupy more floors within than one position in a queue at the same time).  A
      floor request using control server that only supports a REQUEST-STATUS TLV.  If the new status certain number of the
      ongoing floor request is Accepted, the chair MAY requests per floor participant (e.g., one) can use
      Error Code 9 (You have Already Reached the Queue Position field
   to provide a queue position Maximum Number of
      Ongoing Floor Requests for this Floor) to inform the floor request.  If
      participant.

13.1.1  Generating the chair does
   not wish to provide First FloorRequestInfo Message

   The successful processing of a queue position, all FloorRequest message by a floor
   control server involves generating one or several FloorRequestInfo
   messages, the bits first of the Queue
   Position field which SHOULD be set to zero.  The chair SHOULD use generated as soon as possible.
   If the
   Status Revoked to revoke a floor that was granted (i.e., Granted
   status) and to reject floor requests in any other status (e.g.,
   Pending and Accepted).

      Note a control server cannot accept, grant, or deny the floor
   request may involve several floors and that a
      ChairAction message could only deal with a subset of these floors right away (e.g., if a single decision from a chair is not authorized to manage all the
      floors).  In this case, needed), it
   SHOULD use a Request Status value of Pending in the REQUEST-STATUS that the chair provides
      in
   TLV of the ChairAction first FloorRequestInfo message might not be the actual status that the
      floor request gets at the server. it generates.

      The policy a floor control server will
      combine the instructions received from the different chairs follows to
      come up with grant or deny floors
      is outside the actual status scope of the this document.  A given floor request.

   The chair control
      server may use perform these decisions automatically while another may
      contact a HUMAN-READABLE-INFO TLV to state the reason why
   the floor or floors are being accepted, granted, or revoked.  The
   Text in the HUMAN-READABLE-INFO TLV is intended for human
   consumption.

16.2.1  Receiving acting as a Response

   A message from the server is considered to be chair everytime a response decision needs to the
   ChairAction message if the message from the be
      made.

   The floor control server has copies the same Conference ID ID, the
   TRANSACTION-ID, and Transaction ID as the ChairAction message, USER-ID TLVs from the FloorRequest into the
   FloorRequestInfo, as described in Section 9.1.

   A ChairActionAck message from 8.2.  Additionally, the
   floor control server confirms that copies (if present) the server has
   accepted BENEFICIARY-ID TLV from
   the ChairAction message.  An Error message indicates that FloorRequest into the FloorRequestInfo.

   The floor control server could not process the ChairAction message for some reason,
   which MUST assign an identitifier that is described unique
   within the conference to this floor request, and insert it in a
   FLOOR-REQUEST-ID TLV into the Error FloorRequestInfo message.

17.  Server Operations  This section specifies how servers can perform different operations,
   such as granting a floor, using
   indentifier will be used by the protocol elements described in
   earlier sections.

   On reception of floor participant (or by a message chair or
   chairs) to refer to this specific floor request in the future.

   The floor control server copies the FLOOR-ID TLVs from a client, the
   FloorRequest into the FloorRequestInfo.  These FLOOR-ID TLVs identify
   the floors being requested (i.e., the floors associated with this
   particular floor request).

   The floor control server
   MUST check also copies (if present) the PRIORITY TLV
   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 value floor request.

13.1.2  Generation of Subsequent FloorRequestInfo Messages

   A floor request is considered to be ongoing as long as it is not in
   the Conference ID matched an
   existing conference. Cancelled, Released, or Revoked states.  If it does not, the REQUEST-STATUS
   TLV of the first FloorRequestInfo message generated by the floor
   control server SHOULD send an
   Error message, as described in Section 17.7, with Error code 0
   (Conference does did not Exist).

   On reception indicate any of a message from a client, these states, the floor
   control server
   follows the rules in Section 10.2, which relate will need to send subsequent FloorRequestInfo
   messages.

   When the authentication status of the message.

   On reception of a message from a client, floor request changes, the floor control floor
   control server SHOULD send new FloorRequestInfo messages with the
   appropriate Request Status.  These FloorRequestInfo messages MUST check whether or not it understands all
   contain a FLOOR-REQUEST-ID TLV equal to the mandatory ( 'M' bit
   set) TLVs one sent in the message.  If the server does not understand all of
   them, first
   FloorRequestInfo message, but MUST NOT contain any TRANSACTION-ID
   TLV.  (The Floor Request ID identifies the floor server SHOULD send an Error message, as described in
   Section 17.7, with Error code 2 (Authentication Failed).  The Error
   message SHOULD list request the
   FloorRequestInfo applies to.)

   The FIXED-HEADER and the rest of the TLVs that were not understood.

   OPEN ISSUE: can servers use new mandatory TLVs in their messages?
   Right now we do not have a way (expect for clients to complain about
   unsupported TLVs received from the server.

17.1  Reception of a FloorRequest Message
   HUMAN-READABLE-INFO TLV) are the same as in the first
   FloorRequestInfo message.

      The processing of a FloorRequest message by a rate at which the floor control server involves
   generating sends FloorRequestInfo
      messages is a FloorRequestStatus message.  The matter of local policy.  A floor control server
   SHOULD generate may
      choose to send a FloorRequestStatus new FloorRequestInfo message as soon as possible.  If every time the floor server cannot accept, grant, or deny
      request moves in the floor request
   right away (e.g., a decision from queue while another may choose
      to only send a chair new FloorRequestInfo message when the floor request
      is needed), it SHOULD use a
   Request Status value of Pending. Granted or Denied.

   The floor control server copies may add a HUMAN-READABLE-INFO TLV to any of
   the Conference ID and FloorRequestInfo messages it generates to provide extra
   information about its decisions regarding the TRANSACTION-ID TLV from floor request (e.g.,
   why it was denied).

      Floor participants and floor chairs may request to be informed
      about the FloorRequest into status of a floor following the FloorRequestStatus, as described procedures in Section
   9.2.  Additionally,
      12.1.  If the server MUST assign an identitifier that is
   unique within processing of a floor request changes the conference to this status of
      a floor request, (e.g., the floor request is granted and insert it in
   a FLOOR-REQUEST-ID TLV into consequently the FloorRequestStatus message.  This
   indentifier will be used by
      floor has a new holder), the client floor control server needs to refer follow
      the procedures in Section 13.4 to this specific inform the clients that have
      requested that information

   The floor control server can discard the state information about a
   particular floor request in when this reaches a status of Cancelled,
   Released, or Revoked.

13.2  Reception of a FloorRequestInfoWanted Message

   On reception of a FloorRequestInfoWanted message, the future.

   The floor control
   server follows the rules in Section 10.2 9.2 which relate to client
   authentication and authorization.  If while processing the use of the INTEGRITY TLV.

   At later time, when the status of
   FloorRequestInfoWanted message, the floor request changes, control server encounters
   an error, it SHOULD generate an Error response following the
   procedures described in Section 13.7

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

   The floor control server copies the Conference ID, the
   TRANSACTION-ID, and the USER-ID TLVs from the FloorRequestInfoWanted
   message
   with into the appropriate FloorRequestInfo message, as described in Section
   8.2.

13.2.1  Information on a Single Floor Request Status.  This FloorRequestStatus

   If the FloorRequestInfoWanted message
   MUST contain carries a FLOOR-REQUEST-ID TLV identifying FLOOR-REQUEST-ID, the
   sender of the message is requesting information about the floor request,
   but MUST NOT contain any TRANSACTION-ID
   request identified by the FLOOR-REQUEST-ID TLV.  The server may add a
   HUMAN-READABLE-INFO floor control
   servre copies the FLOOR-REQUEST-ID TLV to provide extra information to from the user
   about its decision.

      The rate at which
   FloorRequestInfoWanted message into the FloorRequestInfo message.

   The floor control server sends
      FloorRequestStatus messages is a matter of local policy.  A server
      may choose adds FLOOR-ID TLVs to send a new FloorRequestStatus the FloorRequestInfo
   message every time identifying the floors being requested (i.e., the floors
   associated with the floor request moves in identified by the FLOOR-REQUEST-ID
   TLV).

   The floor request queue while another control server may
      choose to only send also add a new FloorRequestStatus message when PRIORITY TLV with the
   Priority value requested for the floor request is Granted or Denied.

   Clients and chairs that request so need to be informed about changes
   in the status of a floor (e.g., a new floor request arrives).  To
   accomplish this,
   HUMAN-READABLE-INFO TLV with extra information about the floor
   request.

   The floor control server follows the rules in
   Section 17.4.

17.2  Reception of adds a FloorRequestInfo Message

   The processing REQUEST-STATUS TLV with the current
   status of the floor request.

13.2.2  Information on the Floor Requests Associated to a FloorRequestInfo Participant

   If the FloorRequestInfoWanted message by a server involves
   generating does not carry a FloorRequestStatus message.  The FloorRequestInfo
   FLOOR-REQUEST-ID TLV, the sender of the message can apply to a single floor request, identified by a
   FLOOR-REQUEST-ID, or to is requesting
   information about all the floor requests from a given user, the
   FloorRequestInfo does not carry a FLOOR-REQUEST-ID.  The user participant.
   This participant is identified by a BENEFICIARY-ID TLV or, in the
   absence of a BENEFICIARY-ID TLV, or if this is not present, by a USER-ID TLV.

   If

   The floor control server copies (if present) the FloorRequestInfo BENEFICIARY-ID TLV
   from the FloorRequestInfoWanted message contains an invalid FLOOR-REQUEST-ID, into the FloorRequestInfo
   message.  Additionally, the floor control server SHOULD respond with an Error response with
   Error Code 3 (Floor Request ID Does Not Exist).

   On reception of may provide extra
   information about the participant by adding a FloorRequestInfo message, USER-DISPLAY-NAME TLV,
   a USER-URI TLV, or both to the FloorRequestInfo message.

   The floor control server
   SHOULD generate adds a FloorRequestStatus message as soon as possible.

   The server copies the Conference ID and FLOOR-REQUEST-ID TLV for each floor
   request associated to the TRANSACTION-ID participant.  Each FLOOR-REQUEST-ID TLV from is
   followed by a number of TLVs which provide information about the FloorRequestInfo message into
   floor request.  The floor control server generates the FloorRequestStatus, as
   described TLVs that
   follow each FLOOR-REQUEST-ID following the rules in Section 9.2.

   The 13.2.1

13.3  Reception of a FloorRelease Message

   On reception of a FloorRelease message, the floor control server
   follows the rules in Section 10.2 9.2 which relate to client
   authentication and authorization.  If while processing the use of the INTEGRITY TLV.

17.3  Reception of a
   FloorRelease Message message, the floor control server encounters an error,
   it SHOULD generate an Error response following the procedures
   described in Section 13.7

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

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

   The FloorRelease message identifies the floor request it applies to
   using a FLOOR-REQUEST-ID.  If the beneficiary of the floor request is
   not the participant identified by the USER-ID TLV in the FloorRelease
   message, the floor control server adds a BENEFICIARY-ID TLV to the
   FloorRequestInfo message contains an invalid FLOOR-REQUEST-ID, identifying the beneficiary of the floor
   request.  Additionally, the floor control server SHOULD respond with an Error response with Error
   Code 3 (Floor Request ID Does Not Exist).

   On reception may provide extra
   information about the beneficiary of the floor request by adding a
   USER-DISPLAY-NAME TLV, a USER-URI TLV, or both to the
   FloorRequestInfo message.

   The floor control server copies the FLOOR-REQUEST-ID TLV from the
   FloorRelease message with a valid FLOOR-REQUEST-ID, into the FloorRequestInfo message.

   The floor control server SHOULD generate a FloorRequestStatus adds FLOOR-ID TLVs to the FloorRequestInfo
   message
   as soon as possible.  If identifying the floors being requested (i.e., the floors
   associated with the floor request identified by the FLOOR-REQUEST-ID
   TLV).

   The floor control server can authorize may also add a PRIORITY TLV with the release
   operation right away, it SHOULD use
   Priority value requested for the floor request and a
   HUMAN-READABLE-INFO TLV with extra information about the floor
   request.

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

13.4  Reception of a HUMAN-READABLE-INFO TLV to
   provide extra information to the user about its decision.

   The server copies the Conference ID and the TRANSACTION-ID TLV from
   the FloorRelease into FloorInfoWanted Message

   On reception of a FloorInfoWanted message, the FloorRequestStatus, as described in Section
   9.2.

   The floor control server
   follows the rules in Section 10.2 9.2 which relate to
   authentication and client
   authentication.  If while processing the use of FloorRelease message, the INTEGRITY TLV.

17.4  Reception of a FloorInfo Message
   floor control server encounters an error, it SHOULD generate an Error
   response following the procedures described in Section 13.7

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

   The

   An individual FloorInfo message carries information about a single
   floor.  So, when a FloorInfoWanted message requests information about
   more than one floors, 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.

   The server may provide information about a number of floor requests
   in a single FloorInfo message.  For each floor request, the server
   provides its FLOOR-REQUEST-ID and its REQUEST-STATUS, and may provide
   further information such as its BENEFICIARY-ID.

   On reception of a FloorInfo message with one or more FLOOR-ID TLVs,
   the server generates a FloorStatus message for one of the floors
   identified in the FloorInfo message.

   The server copies the Conference ID and the TRANSACTION-ID TLV from
   the FloorInfo message into the FloorStatus message, as described in
   Section 9.2.

   The server follows the rules in Section 10.2 which relate to
   authentication and the use of the INTEGRITY TLV.

   After sending this message, the server SHOULD continue sending
   FloorStatus messages about all the floors the client requested
   information about.  These messages MUST NOT carry a TRANSACTION-ID
   TLV.

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

17.5  Reception do so.

13.4.1  Generation of a ChairAction the First FloorInfo Message

   On reception

   The successful processing of a ChairAction message, 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
   checks whether copies the chair that send Conference ID, the
   TRANSACTION-ID, and the USER-ID TLVs from the FloorInfoWanted message is authorized to
   perform
   into the operation being requested. FloorInfo message, as described in Section 8.2.

   If the chair is authorized, FloorInfoWanted message did not contain any FLOOR-ID TLV, the
   floor control server performs sends the operation FloorInfo message without adding any
   additional TLV and sends a
   ChairActionAck does not send any subsequent FloorInfo message to
   the client. floor participant.

   If the new Status in the
   ChairAction FloorInfoWanted message is Accepted and all the bits of contained one or more FLOOR-ID TLVs,
   the Queue
   Position field are zero, floor control server chooses one among them and adds this
   FLOOR-ID TLV to the FloorInfo message.  The floor control server assigns adds
   a queue position (e.g.,
   the last in the queue) FLOOR-REQUEST-ID TLV for each floor request associated to the
   floor.  Each FLOOR-REQUEST-ID TLV is followed by a number of TLVs
   which provide information about the floor request based on local policy (in
   case request.

   For each FLOOR-REQUEST-ID TLV, the floor control server implements may add a queue).

   The server copies
   BENEFICIARY-ID TLV identifying the Conference ID and requester of the TRANSACTION-ID TLV from floor and a
   USER-DISPLAY-NAME TLV, a USER-URI TLV, or both providing information
   about the ChairAction message into requester.  Additionally, the ChairActionAck message, as described
   in Section 9.2.

   The floor control server follows the rules in Section 10.2 which relate adds
   FLOOR-ID TLVs to
   authentication and the use of FloorInfo message identifying the floors being
   requested (i.e., the INTEGRITY TLV.

   If floors associated with the floor control server cannot find a floor request that matches
   identified by the FLOOR-REQUEST-ID TLV in the ChairAction message the TLV).

   The floor control server generates an Error message, as described in Section 17.7, with
   an Error code with may also add a value of 3 (Floor Request ID Does Not Exist).

   If PRIORITY TLV with the chair is not authorized to perform
   Priority value requested for the operation being
   requested, floor request and a
   HUMAN-READABLE-INFO TLV with extra information about the floor
   request.

   The floor control server generates an Error message, as
   described in Section 17.7, with an Error code with adds a value of 4
   (Unauthorized Operation).

17.6  Reception REQUEST-STATUS TLV with the current
   status of a Ping Message

   The processing the floor request.

13.4.2  Generation of a Ping Subsequent  FloorInfo Messages

   If the FloorInfoWanted message by a server involves generating a
   PingAck message.  On reception of a Ping message, carried more than one FLOOR-ID TLV,
   the floor control server SHOULD generate a PingAck FloorInfo message for each
   of them (except for the FLOOR-ID TLV chosen for the first FloorInfo
   message) as soon as possible.  The
   server copies the Conference ID and the TRANSACTION-ID TLV from the
   Ping into  These FloorInfo messages are generated
   following the PingAck, same rules as described in for the first FloorInfo message (see
   Section 9.2.

   The 13.4.1, but without adding a TRANSACTION TLV.

   After generating these messages, the floor control server follows sends
   FloorInfo messages periodically keeping the rules in Section 10.2 which relate to
   authentication and client informed about all
   the use of floors the INTEGRITY client requested information about.  These messages
   MUST NOT carry a TRANSACTION-ID TLV.

17.7  Error Message Generation

   Error

      The rate at which the floor control server sends FloorInfo
      messages are always sent in response 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 previous new
      FloorInfo message from
   the client as part when a new floor request is Granted.

13.5  Reception of a client-initiated transaction.  The ABNF in
   Section 6.11 describes the TLVs that an Error message can contain.
   In addition, the ABNF specifies which ChairAction Message

   On reception of these TLVs are mandatory,
   and which ones are optional.

   Servers copy the Conference ID and the TRANSACTION-ID TLV from the
   message from the client into the Error a ChairAction message, as described in
   Section 9.2.

   The the floor control server
   follows the rules in Section 10.2 9.2 which relate to client
   authentication and authorization.  If while processing the use of the INTEGRITY TLV.

18.  BFCP and the Offer/Answer Model

   The way a client obtains a
   ChairAction message, the information needed to contact a BFCP floor control server is outside the scope of BCFP.  Nevertheless,
   this section describes how to obtain such encounters an information using error, it
   SHOULD generate an SDP
   [5] offer/answer [11] exchange.

   User agents typically use Error response following the offer/answer model to establish a
   number of media streams of different types.  Following this model, a
   BFCP connection is procedures described as any other media stream by using an
   SDP m line.

18.1  Fields
   in the m Line

   According to RFC 2327 [5], the m-line format is the following:

      m=<media> <port> <transport> <fmt list> Section 13.7

   The media field MUST have a value successful processing of "application".  The port field
   is not used a ChairAction message by BFCP, and MAY a floor control
   server involves generating a ChairActionAck message, which SHOULD be set to any value chosen by the
   endpoint.  A port field value of zero has
   generated as soon as possible.

   The floor control server copies the standard SDP meaning
   (i.e., rejection of Conference ID, the media stream).

   The port field is set following
   TRANSACTION-ID, and the rules in [14].  Depending on USER-ID TLVs from the
   value of ChairAction message
   into the setup attribute (disccused ChairActionAck message, as described in Section 18.4), the port
   field contains 8.2.

   The floor control server needs to take into consideration the port
   operation requested in the remote endpoint will initiate its TCP
   connection to, or is irrelevant (i.e., ChairAction message (e.g., granting a
   floor), but does not necessarily need to perform it as requested by
   the endpoint will initiate floor chair.  The operation that the
   connection towards floor control server
   performs depends on the remote endpoint) ChairAction message and should be set to a value
   of 9, which is the discard port.  Since BFCP only runs on top the internal state
   of TCP, the port is always floor control server.

   For example, a TCP port.

   We define two new values for the transport field: TCP/BFCP and TCP/
   TLS/BFCP.

   The fmt (format) list is ignored for BFCP.  The fmt list of BFCP m
   lines SHOULD contain floor chair may send a single "*" character.

   The following is an example ChairAction message granting a
   floor which was requested as part of an m line atomic floor request
   operation that involved several floors.  Even if the chair
   responsible for a BFCP connection:

   m=application 20000 TCP/BFCP *

18.2  The confid and userid SDP Parameters

   We define one of the confid and floors instructs the userid SDP media-level attributes.
   Their syntax is:

   confid-attribute      = "a=confid: " conference-id
   conference-id         = token

   userid-attribute      = "a=userid: " user-id
   user-id               = token

   The confid and floor control server
   to grant the userid attributes carry floor, the integer representation
   of a conference ID and a user ID respectively.

   Endpoints which use floor control server will not grant it until
   the offer/answer model to establish BFCP
   connections MUST support chairs responsible for the confid and other floors agree to grant them as
   well.

   So, the userid attributes.  A floor control server acting as an offerer or is ultimately responsible to keep a
   coherent floor state using instructions from floor chairs as an answerers SHOULD
   include these attributes in its session descriptions.

18.3  The k line input to
   this state.

   If the offer/answer exchange new Status in the ChairAction message is encrypted Accepted and integrity protected, all the offerer MAY use an SDP k line to provide
   bits of the Queue Position field are zero, the floor participant is
   requesting the answerer with a
   shared secret floor control server to be used assign a queue position (e.g.,
   the last in the queue) to calculate the value floor request based on the local policy
   of the INTEGRITY
   TLVs.  The following is an example floor control server.  (Of course, such as request only
   applies in case the floor control server implements a queue.)

13.6  Reception of a k line:

   k=base64:c2hhcmVkLXNlY3JldA==

18.4  TCP Connection Management

   The management Hello Message

   On reception of a Hello message, the TCP connection used to transport BFCP is
   performed using floor control server follows the setup and connid attributes as defined
   rules in [14].

   The setup attribute indicates Section 9.2 which of relate to client authentication.  If while
   processing the Hello message, the endpoints (client or floor control server) initiates server encounters an
   error, it SHOULD generate an Error response following the TCP connection. procedures
   described in Section 13.7

   The connid attribute
   handles TCP connection reestablishment.

   Editor's note: need to address loss and re-establishment successful processing of TCP
   connections.

18.5  Association between Streams and Floors

   EDITOR'S NOTE: We need a way for clients that don't support CPCP to
   at Hello message by a minimum learn enough information about floors to use the floor control protocol.  This section will need to
   server involves generating a HelloAck message, which SHOULD be harmonized with
   generated as soon as possible.  The floor control server copies the
   media policy work.

   We define
   Conference ID, the floorid SDP media-level attribute.  Its syntax is:

   floor-id-attribute    = "a=floorid:" token " mstream:" 1*(token)

   The floorid attribute is used in BFCP m lines TRANSACTION-ID, and associates a the USER-ID TLVs from the
   Hello into the HelloAck, as described in Section 8.2.

   The floor
   ID with control server adds a media stream.  The token representing SUPPORTED-TLVS TLV to the floor ID is HelloAck
   message listing all the
   integer representation of TLVs supported by the 16-bit floorid to be used floor control server.

13.7  Error Message Generation

   Error messages are always sent in BFCP.  The
   token representing response to a previous message from
   the media stream is client as part of a pointer to client-initiated transaction.  The ABNF in
   Section 5.3.11 describes the media stream, TLVs that an Error message can contain.

   In addition, the ABNF specifies normatively which is identified by an SDP label attribute
   [draft-levin-mmmusic-sdp-media-label-00.txt].

   Endpoints of these TLVs are
   mandatory, and which use ones are optional.

   The floor control server copies the offer/answer model to establish BFCP
   connections MUST support Conference ID, the floorid
   TRANSACTION-ID, and the label attributes.  A
   floor control server acting as an offerer or USER-ID TLVs from the message from the client
   into the Error message, as an answerers SHOULD
   include these attributes described in its session descriptions.

18.6  Example Section 8.2.

   The following is an example of an offer sent by a conference floor control server adds an ERROR-CODE TLV to a user.  For the purpose of brevity, the main portion of the
   session description is omitted in the examples, which only show m=
   lines and their attributes.

   m=application 20000 TCP/BFCP *
   k=base64:c2hhcmVkLXNlY3JldA==
   a=setup:passive
   a=connid:1
   a=confid:4321
   a=userid:1234
   a=floorid:1 m-stream:10
   a=floorid:2 m-stream:11
   m=audio 20000 RTP/AVP 0
   a=label:10
   m=video 30000 RTP/AVP 31
   a=label:11 Error message.
   The following is ERROR-CODE TLV contains an Error Code from Table 4.
   Additionally, the answer returned by floor control server may add a HUMAN-READABLE-INFO
   TLV with extra information about the user.

   m=application 9 TCP/BFCP *
   a=setup:active
   a=connid:1
   m=audio 25000 RTP/AVP 0
   m=video 35000 RTP/AVP 31

19. error.

14.  Security Considerations

   TBD.

20.

15.  IANA Considerations

   TBD

20.1  SDP Attributes Registration

   TBD:

21.

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 provided useful
   comments.

22.

17.  References

22.1

17.1  Normative References

   [1]  Krawczyk, H., Bellare, 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. 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]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
        63, RFC 3629, November 2003.

17.2  Informational References

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

   [6]   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [7]   Petke, R. and I. King, "Registration Procedures for URL Scheme
         Names", BCP 35, RFC 2717, November 1999.

   [8]   Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
         IPv6 Addresses in URL's", RFC 2732, December 1999.

   [9]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

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

   [11]

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

   [12]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Three: The Domain Name System (DNS) Database", RFC 3403,
         October 2002.

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

   [14]  Yon, D., "Connection-Oriented Media Transport in the Session
         Description Protocol  (SDP)", draft-ietf-mmusic-sdp-comedia-08
         (work in progress), July 2004.

22.2  Informational References

   [15]

   [9]   Schulzrinne, H., "Requirements for Floor Control Protocol",
         draft-ietf-xcon-floor-control-req-01 (work in progress), July
         2004.

   [16]

   [10]  Koskelainen, P. and H. Khartabil, "An Extensible Markup
         Language (XML) Configuration Access Protocol (XCAP)  Usage for
         Conference Policy Manipulation",
         draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress),
         February 2004.

   [17]

   [11]  Rosenberg, J. and H. Schulzrinne, "A Session Initiation
         Protocol (SIP) Event Package for Conference State",
         draft-ietf-sipping-conference-package-05 (work in progress),
         July 2004.

   [18]

   [12]  Arkko, J., "MIKEY: Multimedia Internet KEYing",
         draft-ietf-msec-mikey-08 (work in progress), December 2003.

   [19]

   [13]  Rosenberg, J., "An Extensible Markup Language (XML) Document
         Format for Indicating Changes  in XML Configuration Access
         Protocol (XCAP) Resources", draft-ietf-simple-xcap-package-02
         (work in progress), July 2004.

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

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

Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com

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

   EMail: jo@tzi.org

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

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