GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc4582

Network Working Group G. Camarillo Request for Comments: 4582 Ericsson Category: Standards Track J. Ott

                                     Helsinki University of Technology
                                                              K. Drage
                                                   Lucent Technologies
                                                         November 2006
              The Binary Floor Control Protocol (BFCP)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2006).

Abstract

 Floor control is a means to manage joint or exclusive access to
 shared resources in a (multiparty) conferencing environment.
 Thereby, floor control complements other functions -- such as
 conference and media session setup, conference policy manipulation,
 and media control -- that are realized by other protocols.
 This document specifies the Binary Floor Control Protocol (BFCP).
 BFCP is used between floor participants and floor control servers,
 and between floor chairs (i.e., moderators) and floor control
 servers.

Table of Contents

 1. Introduction ....................................................4
 2. Terminology .....................................................4
 3. Scope ...........................................................5
    3.1. Floor Creation .............................................7
    3.2. Obtaining Information to Contact a Floor Control Server ....7
    3.3. Obtaining Floor-Resource Associations ......................7
    3.4. Privileges of Floor Control ................................8
 4. Overview of Operation ...........................................8
    4.1. Floor Participant to Floor Control Server Interface ........8
    4.2. Floor Chair to Floor Control Server Interface .............13

Camarillo, et al. Standards Track [Page 1] RFC 4582 BFCP November 2006

 5. Packet Format ..................................................14
    5.1. COMMON-HEADER Format ......................................15
    5.2. Attribute Format ..........................................16
         5.2.1. BENEFICIARY-ID .....................................18
         5.2.2. FLOOR-ID ...........................................18
         5.2.3. FLOOR-REQUEST-ID ...................................19
         5.2.4. PRIORITY ...........................................19
         5.2.5. REQUEST-STATUS .....................................20
         5.2.6. ERROR-CODE .........................................21
                5.2.6.1. Error-Specific Details for Error Code 4 ...22
         5.2.7. ERROR-INFO .........................................22
         5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
         5.2.9. STATUS-INFO ........................................24
         5.2.10. SUPPORTED-ATTRIBUTES ..............................24
         5.2.11. SUPPORTED-PRIMITIVES ..............................25
         5.2.12. USER-DISPLAY-NAME .................................26
         5.2.13. USER-URI ..........................................26
         5.2.14. BENEFICIARY-INFORMATION ...........................27
         5.2.15. FLOOR-REQUEST-INFORMATION .........................27
         5.2.16. REQUESTED-BY-INFORMATION ..........................28
         5.2.17.  FLOOR-REQUEST-STATUS .............................29
         5.2.18.  OVERALL-REQUEST-STATUS ...........................30
    5.3. Message Format ............................................30
         5.3.1. FloorRequest .......................................31
         5.3.2. FloorRelease .......................................31
         5.3.3. FloorRequestQuery ..................................31
         5.3.4. FloorRequestStatus .................................31
         5.3.5. UserQuery ..........................................32
         5.3.6. UserStatus .........................................32
         5.3.7. FloorQuery .........................................32
         5.3.8. FloorStatus ........................................33
         5.3.9. ChairAction ........................................33
         5.3.10. ChairActionAck ....................................33
         5.3.11. Hello .............................................33
         5.3.12. HelloAck ..........................................34
         5.3.13. Error .............................................34
 6. Transport ......................................................34
 7. Lower-Layer Security ...........................................35
 8. Protocol Transactions ..........................................35
    8.1. Client Behavior ...........................................36
    8.2. Server Behavior ...........................................36
 9. Authentication and Authorization ...............................36
    9.1. TLS-Based Mutual Authentication ...........................37
 10. Floor Participant Operations ..................................37
    10.1. Requesting a Floor .......................................37
         10.1.1. Sending a FloorRequest Message ....................38
         10.1.2. Receiving a Response ..............................38
    10.2. Cancelling a Floor Request and Releasing a Floor .........40

Camarillo, et al. Standards Track [Page 2] RFC 4582 BFCP November 2006

         10.2.1. Sending a FloorRelease Message ....................40
         10.2.2. Receiving a Response ..............................40
 11. Chair Operations ..............................................41
    11.1. Sending a ChairAction Message ............................41
    11.2. Receiving a Response .....................................42
 12. General Client Operations .....................................43
    12.1. Requesting Information about Floors ......................43
         12.1.1. Sending a FloorQuery Message ......................43
         12.1.2. Receiving a Response ..............................43
    12.2. Requesting Information about Floor Requests ..............44
         12.2.1. Sending a FloorRequestQuery Message ...............45
         12.2.2. Receiving a Response ..............................45
    12.3. Requesting Information about a User ......................45
         12.3.1. Sending a UserQuery Message .......................46
         12.3.2. Receiving a Response ..............................46
    12.4. Obtaining the Capabilities of a Floor Control Server .....46
         12.4.1. Sending a Hello Message ...........................47
         12.4.2. Receiving Responses ...............................47
 13. Floor Control Server Operations ...............................47
    13.1. Reception of a FloorRequest Message ......................48
         13.1.1. Generating the First FloorRequestStatus Message ...48
         13.1.2. Generation of Subsequent
                 FloorRequestStatus Messages .......................50
    13.2. Reception of a FloorRequestQuery Message .................51
    13.3. Reception of a UserQuery Message .........................52
    13.4. Reception of a FloorRelease Message ......................53
    13.5. Reception of a FloorQuery Message ........................54
         13.5.1. Generation of the First FloorStatus Message .......55
         13.5.2. Generation of Subsequent FloorStatus Messages .....56
    13.6. Reception of a ChairAction Message .......................56
    13.7. Reception of a Hello Message .............................57
    13.8. Error Message Generation .................................58
 14. Security Considerations .......................................58
 15. IANA Considerations ...........................................59
    15.1. Attribute Subregistry ....................................59
    15.2. Primitive Subregistry ....................................60
    15.3. Request Status Subregistry ...............................61
    15.4. Error Code Subregistry ...................................62
 16. Acknowledgements ..............................................62
 17. References ....................................................63
    17.1. Normative References .....................................63
    17.2. Informational References .................................63

Camarillo, et al. Standards Track [Page 3] RFC 4582 BFCP November 2006

1. Introduction

 Within a conference, some applications need to manage the access to a
 set of shared resources, such as the right to send media to a
 particular media session.  Floor control enables such applications to
 provide users with coordinated (shared or exclusive) access to these
 resources.
 The Requirements for Floor Control Protocol [9] list a set of
 requirements that need to be met by floor control protocols.  The
 Binary Floor Control Protocol (BFCP), which is specified in this
 document, meets these requirements.
 In addition, BFCP has been designed so that it can be used in
 low-bandwidth environments.  The binary encoding used by BFCP
 achieves a small message size (when message signatures are not used)
 that keeps the time it takes to transmit delay-sensitive BFCP
 messages to a minimum.  Delay-sensitive BFCP messages include
 FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction.  It
 is expected that future extensions to these messages will not
 increase the size of these messages in a significant way.
 The remainder of this document is organized as follows: Section 2
 defines the terminology used throughout this document, Section 3
 discusses the scope of BFCP (i.e., which tasks fall within the scope
 of BFCP and which ones are performed using different mechanisms),
 Section 4 provides a non-normative overview of BFCP operation, and
 subsequent sections provide the normative specification of BFCP.

2. 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 [1] 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
 colocated with a floor participant, but it does not need to be.
 Third-party floor requests consist of having a floor participant
 request a floor for a media participant when they are not colocated.
 The protocol between a floor participant and a media participant
 (that are not colocated) is outside the scope of this document.
 Client: A floor participant or a floor chair that communicates with a
 floor control server using BFCP.

Camarillo, et al. Standards Track [Page 4] RFC 4582 BFCP November 2006

 Floor: A temporary permission to access or manipulate a specific
 shared resource or set of resources.
 Floor Chair: A logical entity that manages one floor (grants, denies,
 or revokes a floor).  An entity that assumes the logical role of a
 floor chair for a given transaction may assume a different role
 (e.g., floor participant) for a different transaction.  The roles of
 floor chair and floor participant are defined on a transaction-by-
 transaction basis.  BFCP transactions are defined in Section 8.
 Floor Control: A mechanism that enables applications or users to gain
 safe and mutually exclusive or non-exclusive input access to the
 shared object or resource.
 Floor Control Server: A logical entity that maintains the state of
 the floor(s), including which floors exists, who the floor chairs
 are, who holds a floor, etc.  Requests to manipulate a floor are
 directed at the floor control server.  The floor control server of a
 conference may perform other logical roles (e.g., floor participant)
 in another conference.
 Floor Participant: A logical entity that requests floors, and
 possibly information about them, from a floor control server.  An
 entity that assumes the logical role of a floor participant for a
 given transaction may assume a different role (e.g., a floor chair)
 for a different transaction.  The roles of floor participant and
 floor chair are defined on a transaction-by-transaction basis.  BFCP
 transactions are defined in Section 8.  In floor-controlled
 conferences, a given floor participant is typically colocated with a
 media participant, but it does not need to be.  Third-party floor
 requests consist of having a floor participant request a floor for a
 media participant when they are not colocated.
 Participant: An entity that acts as a floor participant, as a media
 participant, or as both.

3. Scope

 As stated earlier, BFCP is a protocol to coordinate access to shared
 resources in a conference following the requirements defined in [9].
 Floor control complements other functions defined in the XCON
 conferencing framework [10].  The floor control protocol BFCP defined
 in this document only specifies a means to arbitrate access to
 floors.  The rules and constraints for floor arbitration and the
 results of floor assignments are outside the scope of this document
 and are defined by other protocols [10].

Camarillo, et al. Standards Track [Page 5] RFC 4582 BFCP November 2006

 Figure 1 shows the tasks that BFCP can perform.
                            +---------+
                            |  Floor  |
                            |  Chair  |
                            |         |
                            +---------+
                               ^   |
                               |   |
                  Notification |   | Decision
                               |   |
                               |   |
                    Floor      |   v
 +-------------+   Request  +---------+              +-------------+
 |    Floor    |----------->|  Floor  | Notification |    Floor    |
 | Participant |            | Control |------------->| Participant |
 |             |<-----------|  Server |              |             |
 +-------------+ Granted or +---------+              +-------------+
                   Denied
               Figure 1: Functionality provided by BFCP
 BFCP provides a means:
 o  for floor participants to send floor requests to floor control
    servers.
 o  for floor control servers to grant or deny requests to access a
    given resource from floor participants.
 o  for floor chairs to send floor control servers decisions regarding
    floor requests.
 o  for floor control servers to keep floor participants and floor
    chairs informed about the status of a given floor or a given floor
    request.
 Even though tasks that do not belong to the previous list are outside
 the scope of BFCP, some of these out-of-scope tasks relate to floor
 control and are essential for creating floors and establishing BFCP
 connections between different entities.  In the following
 subsections, we discuss some of these tasks and mechanisms to perform
 them.

Camarillo, et al. Standards Track [Page 6] RFC 4582 BFCP November 2006

3.1. Floor Creation

 The association of a given floor with a resource or a set of
 resources (e.g., media streams) is out of the scope of BFCP as
 described in [10].  Floor creation and termination are also outside
 the scope of BFCP; these aspects are handled using the conference
 control protocol for manipulating the conference object.
 Consequently, the floor control server needs to stay up to date on
 changes to the conference object (e.g., when a new floor is created).

3.2. Obtaining Information to Contact a Floor Control Server

 A client needs a set of data in order to establish a BFCP connection
 to a floor control server.  These data include the transport address
 of the server, the conference identifier, and a user identifier.
 Clients can obtain this information in different ways.  One is to use
 an SDP offer/answer [8] exchange, which is described in [7].  Other
 mechanisms are described in the XCON framework [10] (and other
 related documents).

3.3. 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 session as
 its associated resource.  Associations between floors and resources
 are part of the conference object.
 Floor participants and floor chairs need to know which resources are
 associated with which floors.  They can obtain this information by
 using different mechanisms, such as an SDP offer/answer [8] exchange.
 How to use an SDP offer/answer exchange to obtain these associations
 is described in [7].
    Note that floor participants perform SDP offer/answer exchanges
    with the conference focus of the conference.  So, the conference
    focus needs to obtain information about associations between
    floors and resources in order to be able to provide this
    information to a floor participant in an SDP offer/answer
    exchange.
 Other mechanisms for obtaining this information, including discussion
 of how the information is made available to a (SIP) Focus, are
 described in the XCON framework [10] (and other related documents).

Camarillo, et al. Standards Track [Page 7] RFC 4582 BFCP November 2006

3.4. Privileges of Floor Control

 A participant whose floor request is granted has the right to use (in
 a certain way) the resource or resources associated with the floor
 that was requested.  For example, the participant may have the right
 to send media over a particular audio stream.
 Nevertheless, holding a floor does not imply that others will not be
 able to use its associated resources at the same time, even if they
 do not have the right to do so.  Determination of which media
 participants can actually use the resources in the conference is
 discussed in the XCON Framework [10].

4. Overview of Operation

 This section provides a non-normative description of BFCP operations.
 Section 4.1 describes the interface between floor participants and
 floor control servers, and Section 4.2 describes the interface
 between floor chairs and floor control servers.
 BFCP messages, which use a TLV (Type-Length-Value) binary encoding,
 consist of a common header followed by a set of attributes.  The
 common header contains, among other information, a 32-bit conference
 identifier.  Floor participants, media participants, and floor chairs
 are identified by 16-bit user identifiers.
 BFCP supports nested attributes (i.e., attributes that contain
 attributes).  These are referred to as grouped attributes.
 There are two types of transactions in BFCP: client-initiated
 transactions and server-initiated transactions.  Client-initiated
 transactions consist of a message from a client to the floor control
 server and a response from the floor control server to the client.
 Both messages can be related because they carry the same Transaction
 ID value in their common headers.  Server-initiated transactions
 consist of a single message, whose Transaction ID is 0, from the
 floor control server to a client.

4.1. Floor Participant to Floor Control Server Interface

 Floor participants request a floor by sending a FloorRequest message
 to the floor control server.  BFCP supports third-party floor
 requests.  That is, the floor participant sending the floor request
 need not be colocated with the media participant that will get the
 floor once the floor request is granted.  FloorRequest messages carry
 the identity of the requester in the User ID field of the common
 header, and the identity of the beneficiary of the floor (in third-
 party floor requests) in a BENEFICIARY-ID attribute.

Camarillo, et al. Standards Track [Page 8] RFC 4582 BFCP November 2006

    Third-party floor requests can be sent, for example, by floor
    participants that have a BFCP connection to the floor control
    server but that are not media participants (i.e., they do not
    handle any media).
 FloorRequest messages identify the floor or floors being requested by
 carrying their 16-bit floor identifiers in FLOOR-ID attributes.  If a
 FloorRequest message carries more than one floor identifier, the
 floor control server treats all the floor requests as an atomic
 package.  That is, the floor control server either grants or denies
 all the floors in the FloorRequest message.
 Floor control servers respond to FloorRequest messages with
 FloorRequestStatus messages, which provide information about the
 status of the floor request.  The first FloorRequestStatus message is
 the response to the FloorRequest message from the client, and
 therefore has the same Transaction ID as the FloorRequest.
 Additionally, the first FloorRequestStatus message carries the Floor
 Request ID in a FLOOR-REQUEST-INFORMATION attribute.  Subsequent
 FloorRequestStatus messages related to the same floor request will
 carry the same Floor Request ID.  This way, the floor participant can
 associate them with the appropriate floor request.
 Messages from the floor participant related to a particular floor
 request also use the same Floor Request ID as the first
 FloorRequestStatus Message from the floor control server.
 Figure 2 shows how a floor participant requests a floor, obtains it,
 and, at a later time, releases it.  This figure illustrates the use,
 among other things, of the Transaction ID and the FLOOR-REQUEST-ID
 attribute.

Camarillo, et al. Standards Track [Page 9] RFC 4582 BFCP November 2006

    Floor Participant                                 Floor Control
                                                         Server
            |(1) FloorRequest                               |
            |Transaction ID: 123                            |
            |User ID: 234                                   |
            |FLOOR-ID: 543                                  |
            |---------------------------------------------->|
            |                                               |
            |(2) FloorRequestStatus                         |
            |Transaction ID: 123                            |
            |User ID: 234                                   |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 789                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Pending          |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |<----------------------------------------------|
            |                                               |
            |(3) FloorRequestStatus                         |
            |Transaction ID: 0                              |
            |User ID: 234                                   |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 789                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Accepted         |
            |              Queue Position: 1st              |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |<----------------------------------------------|
            |                                               |
            |(4) FloorRequestStatus                         |
            |Transaction ID: 0                              |
            |User ID: 234                                   |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 789                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Granted          |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |<----------------------------------------------|
            |                                               |
            |(5) FloorRelease                               |
            |Transaction ID: 154                            |
            |User ID: 234                                   |
            |FLOOR-REQUEST-ID: 789                          |
            |---------------------------------------------->|

Camarillo, et al. Standards Track [Page 10] RFC 4582 BFCP November 2006

            |                                               |
            |(6) FloorRequestStatus                         |
            |Transaction ID: 154                            |
            |User ID: 234                                   |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 789                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Released         |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |<----------------------------------------------|
              Figure 2: Requesting and releasing a floor
 Figure 3 shows how a floor participant requests to be informed on the
 status of a floor.  The first FloorStatus message from the floor
 control server is the response to the FloorQuery message and, as
 such, has the same Transaction ID as the FloorQuery message.
 Subsequent FloorStatus messages consist of server-initiated
 transactions, and therefore their Transaction ID is 0.  FloorStatus
 message (2) indicates that there are currently two floor requests for
 the floor whose Floor ID is 543.  FloorStatus message (3) indicates
 that the floor requests with Floor Request ID 764 has been granted,
 and the floor request with Floor Request ID 635 is the first in the
 queue.  FloorStatus message (4) indicates that the floor request with
 Floor Request ID 635 has been granted.
    Floor Participant                                 Floor Control
                                                         Server
            |(1) FloorQuery                                 |
            |Transaction ID: 257                            |
            |User ID: 234                                   |
            |FLOOR-ID: 543                                  |
            |---------------------------------------------->|

Camarillo, et al. Standards Track [Page 11] RFC 4582 BFCP November 2006

            |                                               |
            |(2) FloorStatus                                |
            |Transaction ID: 257                            |
            |User ID: 234                                   |
            |FLOOR-ID:543                                   |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 764                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Accepted         |
            |              Queue Position: 1st              |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |      BENEFICIARY-INFORMATION                  |
            |                  Beneficiary ID: 124          |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 635                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Accepted         |
            |              Queue Position: 2nd              |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |      BENEFICIARY-INFORMATION                  |
            |                  Beneficiary ID: 154          |
            |<----------------------------------------------|
            |                                               |
            |(3) FloorStatus                                |
            |Transaction ID: 0                              |
            |User ID: 234                                   |
            |FLOOR-ID:543                                   |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 764                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Granted          |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |      BENEFICIARY-INFORMATION                  |
            |                  Beneficiary ID: 124          |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 635                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Accepted         |
            |              Queue Position: 1st              |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |      BENEFICIARY-INFORMATION                  |
            |                  Beneficiary ID: 154          |
            |<----------------------------------------------|

Camarillo, et al. Standards Track [Page 12] RFC 4582 BFCP November 2006

            |                                               |
            |(4) FloorStatus                                |
            |Transaction ID: 0                              |
            |User ID: 234                                   |
            |FLOOR-ID:543                                   |
            |FLOOR-REQUEST-INFORMATION                      |
            |      Floor Request ID: 635                    |
            |      OVERALL-REQUEST-STATUS                   |
            |              Request Status: Granted          |
            |      FLOOR-REQUEST-STATUS                     |
            |            Floor ID: 543                      |
            |      BENEFICIARY-INFORMATION                  |
            |                  Beneficiary ID: 154          |
            |<----------------------------------------------|
         Figure 3: Obtaining status information about a floor
 FloorStatus messages contain information about the floor requests
 they carry.  For example, FloorStatus message (4) indicates that the
 floor request with Floor Request ID 635 has as the beneficiary (i.e.,
 the participant that holds the floor when a particular floor request
 is granted) the participant whose User ID is 154.  The floor request
 applies only to the floor whose Floor ID is 543.  That is, this is
 not a multi-floor floor request.
    A multi-floor floor request applies to more than one floor (e.g.,
    a participant wants to be able to speak and write on the
    whiteboard at the same time).  The floor control server treats a
    multi-floor floor request as an atomic package.  That is, the
    floor control server either grants the request for all floors or
    denies the request for all floors.

4.2. Floor Chair to Floor Control Server Interface

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

Camarillo, et al. Standards Track [Page 13] RFC 4582 BFCP November 2006

 For example, a floor chair may send a ChairAction message granting a
 floor that was requested as part of an atomic floor request operation
 that involved several floors.  Even if the chair responsible for one
 of the floors instructs the floor control server to grant the floor,
 the floor control server will not grant it until the chairs
 responsible for the other floors agree to grant them as well.  In
 another example, a floor chair may instruct the floor control server
 to grant a floor to a participant.  The floor control server needs to
 revoke the floor from its current holder before granting it to the
 new participant.
 So, the floor control server is ultimately responsible for keeping a
 coherent floor state using instructions from floor chairs as input to
 this state.
    Floor Chair                                    Floor Control
                                                      Server
         |(1) ChairAction                                |
         |Transaction ID: 769                            |
         |User ID: 357                                   |
         |FLOOR-REQUEST-INFORMATION                      |
         |      Floor Request ID: 635                    |
         |      FLOOR-REQUEST-STATUS                     |
         |            Floor ID: 543                      |
         |            Request Status: Granted            |
         |---------------------------------------------->|
         |                                               |
         |(2) ChairActionAck                             |
         |Transaction ID: 769                            |
         |User ID: 357                                   |
         |<----------------------------------------------|
         Figure 4: Chair instructing the floor control server

5. Packet Format

 BFCP packets consist of a 12-octet common header followed by
 attributes.  All the protocol values MUST be sent in network byte
 order.

Camarillo, et al. Standards Track [Page 14] RFC 4582 BFCP November 2006

5.1. COMMON-HEADER Format

 The following is the format of the common header.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Ver |Reserved |  Primitive    |        Payload Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Conference ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Transaction ID        |            User ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 5: COMMON-HEADER format
 Ver: The 3-bit version field MUST be set to 1 to indicate this
 version of BFCP.
 Reserved: At this point, the 5 bits in the reserved field SHOULD be
 set to zero by the sender of the message and MUST be ignored by the
 receiver.
 Primitive: This 8-bit field identifies the main purpose of the
 message.  The following primitive values are defined:
           +-------+--------------------+------------------+
           | Value | Primitive          | Direction        |
           +-------+--------------------+------------------+
           |   1   | FloorRequest       | P -> S           |
           |   2   | FloorRelease       | P -> S           |
           |   3   | FloorRequestQuery  | P -> S ; Ch -> S |
           |   4   | FloorRequestStatus | P <- S ; Ch <- S |
           |   5   | UserQuery          | P -> S ; Ch -> S |
           |   6   | UserStatus         | P <- S ; Ch <- S |
           |   7   | FloorQuery         | P -> S ; Ch -> S |
           |   8   | FloorStatus        | P <- S ; Ch <- S |
           |   9   | ChairAction        | Ch -> S          |
           |   10  | ChairActionAck     | Ch <- S          |
           |   11  | Hello              | P -> S ; Ch -> S |
           |   12  | HelloAck           | P <- S ; Ch <- S |
           |   13  | Error              | P <- S ; Ch <- S |
           +-------+--------------------+------------------+
                       S:  Floor Control Server
                       P:  Floor Participant
                       Ch: Floor Chair
                       Table 1: BFCP primitives

Camarillo, et al. Standards Track [Page 15] RFC 4582 BFCP November 2006

 Payload Length: This 16-bit field contains the length of the message
 in 4-octet units, excluding the common header.
 Conference ID: This 32-bit field identifies the conference the
 message belongs to.
 Transaction ID: This field contains a 16-bit value that allows users
 to match a given message with its response.  The value of the
 Transaction ID in server-initiated transactions is 0 (see Section 8).
 User ID: This field contains a 16-bit value that uniquely identifies
 a participant within a conference.
    The identity used by a participant in BFCP, which is carried in
    the User ID field, is generally mapped to the identity used by the
    same participant in the session establishment protocol (e.g., in
    SIP).  The way this mapping is performed is outside the scope of
    this specification.

5.2. Attribute Format

 BFCP attributes are encoded in TLV (Type-Length-Value) format.
 Attributes are 32-bit aligned.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Type     |M|    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                       Attribute Contents                      /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 6: Attribute format
 Type: This 7-bit field contains the type of the attribute.  Each
 attribute, identified by its type, has a particular format.  The
 attribute formats defined are:
    Unsigned16: The contents of the attribute consist of a 16-bit
    unsigned integer.
    OctetString16: The contents of the attribute consist of 16 bits of
    arbitrary data.

Camarillo, et al. Standards Track [Page 16] RFC 4582 BFCP November 2006

    OctetString: The contents of the attribute consist of arbitrary
    data of variable length.
    Grouped: The contents of the attribute consist of a sequence of
    attributes.
    Note that extension attributes defined in the future may define
    new attribute formats.
 The following attribute types are defined:
    +------+---------------------------+---------------+
    | Type | Attribute                 | Format        |
    +------+---------------------------+---------------+
    |   1  | BENEFICIARY-ID            | Unsigned16    |
    |   2  | FLOOR-ID                  | Unsigned16    |
    |   3  | FLOOR-REQUEST-ID          | Unsigned16    |
    |   4  | PRIORITY                  | OctetString16 |
    |   5  | REQUEST-STATUS            | OctetString16 |
    |   6  | ERROR-CODE                | OctetString   |
    |   7  | ERROR-INFO                | OctetString   |
    |   8  | PARTICIPANT-PROVIDED-INFO | OctetString   |
    |   9  | STATUS-INFO               | OctetString   |
    |  10  | SUPPORTED-ATTRIBUTES      | OctetString   |
    |  11  | SUPPORTED-PRIMITIVES      | OctetString   |
    |  12  | USER-DISPLAY-NAME         | OctetString   |
    |  13  | USER-URI                  | OctetString   |
    |  14  | BENEFICIARY-INFORMATION   | Grouped       |
    |  15  | FLOOR-REQUEST-INFORMATION | Grouped       |
    |  16  | REQUESTED-BY-INFORMATION  | Grouped       |
    |  17  | FLOOR-REQUEST-STATUS      | Grouped       |
    |  18  | OVERALL-REQUEST-STATUS    | Grouped       |
    +------+---------------------------+---------------+
                       Table 2: BFCP attributes
 M: The 'M' bit, known as the Mandatory bit, indicates whether support
 of the attribute is required.  If an unrecognized attribute with the
 'M' bit set is received, the message is rejected.  The 'M' bit is
 significant for extension attributes defined in other documents only.
 All attributes specified in this document MUST be understood by the
 receiver so that the setting of the 'M' bit is irrelevant for these.
 In all other cases, the unrecognised attribute is ignored but the
 message is processed.
 Length: This 8-bit field contains the length of the attribute in
 octets, excluding any padding defined for specific attributes.  The
 length of attributes that are not grouped includes the Type, 'M' bit,

Camarillo, et al. Standards Track [Page 17] RFC 4582 BFCP November 2006

 and Length fields.  The Length in grouped attributes is the length of
 the grouped attribute itself (including Type, 'M' bit, and Length
 fields) plus the total length (including padding) of all the included
 attributes.
 Attribute Contents: The contents of the different attributes are
 defined in the following sections.

5.2.1. BENEFICIARY-ID

 The following is the format of the BENEFICIARY-ID attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0|        Beneficiary ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 7: BENEFICIARY-ID format
 Beneficiary ID: This field contains a 16-bit value that uniquely
 identifies a user within a conference.
    Note that although the formats of the Beneficiary ID and of the
    User ID field in the common header are similar, their semantics
    are different.  The Beneficiary ID is used in third-party floor
    requests and to request information about a particular
    participant.

5.2.2. FLOOR-ID

 The following is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0|           Floor ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 8: FLOOR-ID format
 Floor ID: This field contains a 16-bit value that uniquely identifies
 a floor within a conference.

Camarillo, et al. Standards Track [Page 18] RFC 4582 BFCP November 2006

5.2.3. FLOOR-REQUEST-ID

 The following is the format of the FLOOR-REQUEST-ID attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0|       Floor Request ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 9: FLOOR-REQUEST-ID format
 Floor Request ID: This field contains a 16-bit value that identifies
 a floor request at the floor control server.

5.2.4. 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 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio |         Reserved        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 10: PRIORITY format
 Prio: This field contains a 3-bit priority value, as shown in
 Table 3.  Senders SHOULD NOT use values higher than 4 in this field.
 Receivers MUST treat values higher than 4 as if the value received
 were 4 (Highest).  The default priority value when the PRIORITY
 attribute is missing is 2 (Normal).
                         +-------+----------+
                         | Value | Priority |
                         +-------+----------+
                         |   0   | Lowest   |
                         |   1   | Low      |
                         |   2   | Normal   |
                         |   3   | High     |
                         |   4   | Highest  |
                         +-------+----------+
                       Table 3: Priority values
 Reserved: At this point, the 13 bits in the reserved field SHOULD be
 set to zero by the sender of the message and MUST be ignored by the
 receiver.

Camarillo, et al. Standards Track [Page 19] RFC 4582 BFCP November 2006

5.2.5. REQUEST-STATUS

 The following is the format of the REQUEST-STATUS attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 11: REQUEST-STATUS format
 Request Status: This 8-bit field contains the status of the request,
 as described in the following table.
                         +-------+-----------+
                         | Value | Status    |
                         +-------+-----------+
                         |   1   | Pending   |
                         |   2   | Accepted  |
                         |   3   | Granted   |
                         |   4   | Denied    |
                         |   5   | Cancelled |
                         |   6   | Released  |
                         |   7   | Revoked   |
                         +-------+-----------+
                    Table 4: Request Status values
 Queue Position: This 8-bit field contains, when applicable, the
 position of the floor request in the floor request queue at the
 server.  If the Request Status value is different from Accepted, if
 the floor control server does not implement a floor request queue, or
 if the floor control server does not want to provide the client with
 this information, all the bits of this field SHOULD be set to zero.
 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.

Camarillo, et al. Standards Track [Page 20] RFC 4582 BFCP November 2006

5.2.6. ERROR-CODE

 The following is the format of the ERROR-CODE attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 1 0|M|    Length     |  Error Code   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
   |                                                               |
   |                     Error Specific Details                    |
   /                                                               /
   /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |            Padding            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 12: ERROR-CODE format
 Error Code: This 8-bit field contains an error code from the
 following table.  If an error code is not recognised by the receiver,
 then the receiver MUST assume that an error exists, and therefore
 that the message is processed, but the nature of the error is
 unclear.
 +-------+-----------------------------------------------------------+
 | Value | Meaning                                                   |
 +-------+-----------------------------------------------------------+
 |   1   | Conference does not Exist                                 |
 |   2   | User does not Exist                                       |
 |   3   | Unknown Primitive                                         |
 |   4   | Unknown Mandatory Attribute                               |
 |   5   | Unauthorized Operation                                    |
 |   6   | Invalid Floor ID                                          |
 |   7   | Floor Request ID Does Not Exist                           |
 |   8   | You have Already Reached the Maximum Number of Ongoing    |
 |       | Floor Requests for this Floor                             |
 |   9   | Use TLS                                                   |
 +-------+-----------------------------------------------------------+
                      Table 5: Error Code meaning
 Error Specific Details: Present only for certain Error Codes.  In
 this document, only for Error Code 4 (Unknown Mandatory Attribute).
 See Section 5.2.6.1 for its definition.
 Padding: One, two, or three octets of padding added so that the
 contents of the ERROR-CODE attribute is 32-bit aligned.  If the
 attribute is already 32-bit aligned, no padding is needed.

Camarillo, et al. Standards Track [Page 21] RFC 4582 BFCP November 2006

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

5.2.6.1. Error-Specific Details for Error Code 4

 The following is the format of the Error-Specific Details field for
 Error Code 4.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               | Unknown Type|R| Unknown Type|R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Unknown Type|R| Unknown Type|R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 13: Unknown attributes format
 Unknown Type: These 7-bit fields contain the Types of the attributes
 (which were present in the message that triggered the Error message)
 that were unknown to the receiver.
 R: At this point, this bit is reserved.  It SHOULD be set to zero by
 the sender of the message and MUST be ignored by the receiver.

5.2.7. ERROR-INFO

 The following is the format of the ERROR-INFO attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 1 1 1|M|    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                             Text                              /
   /                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 14: ERROR-INFO format
 Text: This field contains UTF-8 [6] encoded text.

Camarillo, et al. Standards Track [Page 22] RFC 4582 BFCP November 2006

 In some situations, the contents of the Text field may be generated
 by an automaton.  If this automaton has information about the
 preferred language of the receiver of a particular ERROR-INFO
 attribute, it MAY use this language to generate the Text field.
 Padding: One, two, or three octets of padding added so that the
 contents of the ERROR-INFO attribute is 32-bit aligned.  The Padding
 bits SHOULD be set to zero by the sender and MUST be ignored by the
 receiver.  If the attribute is already 32-bit aligned, no padding is
 needed.

5.2.8. PARTICIPANT-PROVIDED-INFO

 The following is the format of the PARTICIPANT-PROVIDED-INFO
 attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1 0 0 0|M|    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                             Text                              /
   /                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 15: PARTICIPANT-PROVIDED-INFO format
 Text: This field contains UTF-8 [6] encoded text.
 Padding: One, two, or three octets of padding added so that the
 contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit
 aligned.  The Padding bits SHOULD be set to zero by the sender and
 MUST be ignored by the receiver.  If the attribute is already 32-bit
 aligned, no padding is needed.

Camarillo, et al. Standards Track [Page 23] RFC 4582 BFCP November 2006

5.2.9. STATUS-INFO

 The following is the format of the STATUS-INFO attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1 0 0 1|M|    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                             Text                              /
   /                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Figure 16: STATUS-INFO format
 Text: This field contains UTF-8 [6] encoded text.
 In some situations, the contents of the Text field may be generated
 by an automaton.  If this automaton has information about the
 preferred language of the receiver of a particular STATUS-INFO
 attribute, it MAY use this language to generate the Text field.
 Padding: One, two, or three octets of padding added so that the
 contents of the STATUS-INFO attribute is 32-bit aligned.  The Padding
 bits SHOULD be set to zero by the sender and MUST be ignored by the
 receiver.  If the attribute is already 32-bit aligned, no padding is
 needed.

5.2.10. SUPPORTED-ATTRIBUTES

 The following is the format of the SUPPORTED-ATTRIBUTES attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1 0 1 0|M|    Length     | Supp. Attr. |R| Supp. Attr. |R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                                                               /
   /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |            Padding            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 17: SUPPORTED-ATTRIBUTES format

Camarillo, et al. Standards Track [Page 24] RFC 4582 BFCP November 2006

 Supp. Attr.: These fields contain the Types of the attributes that
 are supported by the floor control server in the following format:
 R: Reserved: This bit MUST be set to zero upon transmission and MUST
 be ignored upon reception.
 Padding: Two octets of padding added so that the contents of the
 SUPPORTED-ATTRIBUTES attribute is 32-bit aligned.  If the attribute
 is already 32-bit aligned, no padding is needed.
 The Padding bits SHOULD be set to zero by the sender and MUST be
 ignored by the receiver.

5.2.11. SUPPORTED-PRIMITIVES

 The following is the format of the SUPPORTED-PRIMITIVES attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1 0 1 1|M|    Length     |   Primitive   |   Primitive   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Primitive   |   Primitive   |   Primitive   |   Primitive   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                                                               /
   /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |            Padding            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 18: SUPPORTED-PRIMITIVES format
 Primitive: These fields contain the types of the BFCP messages that
 are supported by the floor control server.  See Table 1 for the list
 of BFCP primitives.
 Padding: One, two, or three octets of padding added so that the
 contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned.  If
 the attribute is already 32-bit aligned, no padding is needed.
 The Padding bits SHOULD be set to zero by the sender and MUST be
 ignored by the receiver.

Camarillo, et al. Standards Track [Page 25] RFC 4582 BFCP November 2006

5.2.12. USER-DISPLAY-NAME

 The following is the format of the USER-DISPLAY-NAME attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1 1 0 0|M|    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                             Text                              /
   /                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 19: USER-DISPLAY-NAME format
 Text: This field contains the UTF-8 encoded name of the user.
 Padding: One, two, or three octets of padding added so that the
 contents of the USER-DISPLAY-NAME attribute is 32-bit aligned.  The
 Padding bits SHOULD be set to zero by the sender and MUST be ignored
 by the receiver.  If the attribute is already 32-bit aligned, no
 padding is needed.

5.2.13. USER-URI

 The following is the format of the USER-URI attribute.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1 1 0 1|M|    Length     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                             Text                              /
   /                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 20: USER-URI format
 Text: This field contains the UTF-8 encoded user's contact URI, that
 is, the URI used by the user to set up the resources (e.g., media
 streams) that are controlled by BFCP.  For example, in the context of
 a conference set up by SIP, the USER-URI attribute would carry the
 SIP URI of the user.

Camarillo, et al. Standards Track [Page 26] RFC 4582 BFCP November 2006

    Messages containing a user's URI in a USER-URI attribute also
    contain the user's User ID.  This way, a client receiving such a
    message can correlate the user's URI (e.g., the SIP URI the user
    used to join a conference) with the user's User ID.
 Padding: One, two, or three octets of padding added so that the
 contents of the USER-URI attribute is 32-bit aligned.  The Padding
 bits SHOULD be set to zero by the sender and MUST be ignored by the
 receiver.  If the attribute is already 32-bit aligned, no padding is
 needed.

5.2.14. BENEFICIARY-INFORMATION

 The BENEFICIARY-INFORMATION attribute is a grouped attribute that
 consists of a header, which is referred to as BENEFICIARY-
 INFORMATION-HEADER, followed by a sequence of attributes.  The
 following is the format of the BENEFICIARY-INFORMATION-HEADER:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1 1 1 0|M|    Length     |        Beneficiary ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 21: BENEFICIARY-INFORMATION-HEADER format
 Beneficiary ID: This field contains a 16-bit value that uniquely
 identifies a user within a conference.
 The following is the ABNF (Augmented Backus-Naur Form) [2] of the
 BENEFICIARY-INFORMATION grouped attribute.  (EXTENSION-ATTRIBUTE
 refers to extension attributes that may be defined in the future.)
 BENEFICIARY-INFORMATION =   (BENEFICIARY-INFORMATION-HEADER)
                             [USER-DISPLAY-NAME]
                             [USER-URI]
                            *[EXTENSION-ATTRIBUTE]
               Figure 22: BENEFICIARY-INFORMATION format

5.2.15. FLOOR-REQUEST-INFORMATION

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

Camarillo, et al. Standards Track [Page 27] RFC 4582 BFCP November 2006

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1 1 1 1|M|    Length     |       Floor Request ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format
 Floor Request ID: This field contains a 16-bit value that identifies
 a floor request at the floor control server.
 The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped
 attribute.  (EXTENSION-ATTRIBUTE refers to extension attributes that
 may be defined in the future.)
 FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
                               [OVERALL-REQUEST-STATUS]
                             1*(FLOOR-REQUEST-STATUS)
                               [BENEFICIARY-INFORMATION]
                               [REQUESTED-BY-INFORMATION]
                               [PRIORITY]
                               [PARTICIPANT-PROVIDED-INFO]
                              *[EXTENSION-ATTRIBUTE]
              Figure 24: FLOOR-REQUEST-INFORMATION format

5.2.16. REQUESTED-BY-INFORMATION

 The REQUESTED-BY-INFORMATION attribute is a grouped attribute that
 consists of a header, which is referred to as REQUESTED-BY-
 INFORMATION-HEADER, followed by a sequence of attributes.  The
 following is the format of the REQUESTED-BY-INFORMATION-HEADER:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 1 0 0 0 0|M|    Length     |       Requested-by ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Figure 25: REQUESTED-BY-INFORMATION-HEADER format
 Requested-by ID: This field contains a 16-bit value that uniquely
 identifies a user within a conference.
 The following is the ABNF of the REQUESTED-BY-INFORMATION grouped
 attribute.  (EXTENSION-ATTRIBUTE refers to extension attributes that
 may be defined in the future.)

Camarillo, et al. Standards Track [Page 28] RFC 4582 BFCP November 2006

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

5.2.17. FLOOR-REQUEST-STATUS

 The FLOOR-REQUEST-STATUS attribute is a grouped attribute that
 consists of a header, which is referred to as
 FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes.
 The following is the format of the FLOOR-REQUEST-STATUS-HEADER:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 1 0 0 0 1|M|    Length     |           Floor ID            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Figure 27: FLOOR-REQUEST-STATUS-HEADER format
 Floor ID: this field contains a 16-bit value that uniquely identifies
 a floor within a conference.
 The following is the ABNF of the FLOOR-REQUEST-STATUS grouped
 attribute.  (EXTENSION-ATTRIBUTE refers to extension attributes that
 may be defined in the future.)
 FLOOR-REQUEST-STATUS     =   (FLOOR-REQUEST-STATUS-HEADER)
                              [REQUEST-STATUS]
                              [STATUS-INFO]
                             *[EXTENSION-ATTRIBUTE]
                Figure 28: FLOOR-REQUEST-STATUS format

Camarillo, et al. Standards Track [Page 29] RFC 4582 BFCP November 2006

5.2.18. OVERALL-REQUEST-STATUS

 The OVERALL-REQUEST-STATUS attribute is a grouped attribute that
 consists of a header, which is referred to as
 OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes.
 The following is the format of the OVERALL-REQUEST-STATUS-HEADER:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 1 0 0 1 0|M|    Length     |       Floor Request ID        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 29: OVERALL-REQUEST-STATUS-HEADER format
 Floor Request ID: this field contains a 16-bit value that identifies
 a floor request at the floor control server.
 The following is the ABNF of the OVERALL-REQUEST-STATUS grouped
 attribute.  (EXTENSION-ATTRIBUTE refers to extension attributes that
 may be defined in the future.)
 OVERALL-REQUEST-STATUS   =   (OVERALL-REQUEST-STATUS-HEADER)
                              [REQUEST-STATUS]
                              [STATUS-INFO]
                             *[EXTENSION-ATTRIBUTE]
               Figure 30: OVERALL-REQUEST-STATUS format

5.3. Message Format

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

Camarillo, et al. Standards Track [Page 30] RFC 4582 BFCP November 2006

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 =   (COMMON-HEADER)
                1*(FLOOR-ID)
                  [BENEFICIARY-ID]
                  [PARTICIPANT-PROVIDED-INFO]
                  [PRIORITY]
                 *[EXTENSION-ATTRIBUTE]
                    Figure 31: 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 =   (COMMON-HEADER)
                  (FLOOR-REQUEST-ID)
                 *[EXTENSION-ATTRIBUTE]
                    Figure 32: FloorRelease format

5.3.3. FloorRequestQuery

 Floor participants and floor chairs request information about a floor
 request by sending a FloorRequestQuery message to the floor control
 server.  The following is the format of the FloorRequestQuery
 message:
 FloorRequestQuery =   (COMMON-HEADER)
                       (FLOOR-REQUEST-ID)
                      *[EXTENSION-ATTRIBUTE]
                  Figure 33: FloorRequestQuery format

5.3.4. FloorRequestStatus

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

Camarillo, et al. Standards Track [Page 31] RFC 4582 BFCP November 2006

 FloorRequestStatus =   (COMMON-HEADER)
                        (FLOOR-REQUEST-INFORMATION)
                       *[EXTENSION-ATTRIBUTE]
                 Figure 34: FloorRequestStatus format

5.3.5. UserQuery

 Floor participants and floor chairs request information about a
 participant and the floor requests related to this participant by
 sending a UserQuery message to the floor control server.  The
 following is the format of the UserQuery message:
 UserQuery =   (COMMON-HEADER)
               [BENEFICIARY-ID]
              *[EXTENSION-ATTRIBUTE]
                      Figure 35: UserQuery format

5.3.6. UserStatus

 The floor control server provides information about participants and
 their related floor requests to floor participants and floor chairs
 by sending them UserStatus messages.  The following is the format of
 the UserStatus message:
 UserStatus =   (COMMON-HEADER)
                [BENEFICIARY-INFORMATION]
               *(FLOOR-REQUEST-INFORMATION)
               *[EXTENSION-ATTRIBUTE]
                     Figure 36: UserStatus format

5.3.7. FloorQuery

 Floor participants and floor chairs request information about a floor
 or floors by sending a FloorQuery message to the floor control
 server.  The following is the format of the FloorRequest message:
 FloorQuery =   (COMMON-HEADER)
               *(FLOOR-ID)
               *[EXTENSION-ATTRIBUTE]
                     Figure 37: FloorQuery format

Camarillo, et al. Standards Track [Page 32] RFC 4582 BFCP November 2006

5.3.8. FloorStatus

 The floor control server informs floor participants and floor chairs
 about the status (e.g., the current holder) of a floor by sending
 them FloorStatus messages.  The following is the format of the
 FloorStatus message:
 FloorStatus        =     (COMMON-HEADER)
                        *1(FLOOR-ID)
                         *[FLOOR-REQUEST-INFORMATION]
                         *[EXTENSION-ATTRIBUTE]
                     Figure 38: FloorStatus format

5.3.9. ChairAction

 Floor chairs send instructions to floor control servers by sending
 ChairAction messages.  The following is the format of the ChairAction
 message:
 ChairAction  =   (COMMON-HEADER)
                  (FLOOR-REQUEST-INFORMATION)
                 *[EXTENSION-ATTRIBUTE]
                     Figure 39: ChairAction format

5.3.10. ChairActionAck

 Floor control servers confirm that they have accepted a ChairAction
 message by sending a ChairActionAck message.  The following is the
 format of the ChairActionAck message:
 ChairActionAck  =   (COMMON-HEADER)
                    *[EXTENSION-ATTRIBUTE]
                   Figure 40: ChairActionAck format

5.3.11. Hello

 Floor participants and floor chairs check the liveliness of floor
 control servers by sending a Hello message.  The following is the
 format of the Hello message:
 Hello         =  (COMMON-HEADER)
                 *[EXTENSION-ATTRIBUTE]
                        Figure 41: Hello format

Camarillo, et al. Standards Track [Page 33] RFC 4582 BFCP November 2006

5.3.12. HelloAck

 Floor control servers confirm that they are alive on reception of a
 Hello message by sending a HelloAck message.  The following is the
 format of the HelloAck message:
 HelloAck      =  (COMMON-HEADER)
                  (SUPPORTED-PRIMITIVES)
                  (SUPPORTED-ATTRIBUTES)
                 *[EXTENSION-ATTRIBUTE]
                      Figure 42: HelloAck format

5.3.13. Error

 Floor control servers inform floor participants and floor chairs
 about errors processing requests by sending them Error messages.  The
 following is the format of the Error message:
 Error              =   (COMMON-HEADER)
                        (ERROR-CODE)
                        [ERROR-INFO]
                       *[EXTENSION-ATTRIBUTE]
                        Figure 43: Error format

6. Transport

 BFCP entities exchange BFCP messages using TCP connections.  TCP
 provides an in-order reliable delivery of a stream of bytes.
 Consequently, message framing is implemented in the application
 layer.  BFCP implements application-layer framing using TLV-encoded
 attributes.
 A client MUST NOT use more than one TCP connection to communicate
 with a given floor control server within a conference.  Nevertheless,
 if the same physical box handles different clients (e.g., a floor
 chair and a floor participant), which are identified by different
 User IDs, a separate connection per client is allowed.
 If a BFCP entity (a client or a floor control server) receives data
 from TCP that cannot be parsed, the entity MUST close the TCP
 connection, and the connection SHOULD be reestablished.  Similarly,
 if a TCP connection cannot deliver a BFCP message and times out, the
 TCP connection SHOULD be reestablished.

Camarillo, et al. Standards Track [Page 34] RFC 4582 BFCP November 2006

 The way connection reestablishment is handled depends on how the
 client obtains information to contact the floor control server (e.g.,
 using an SDP offer/answer exchange [7]).  Once the TCP connection is
 reestablished, the client MAY resend those messages for which it did
 not get a response from the floor control server.
 If a floor control server detects that the TCP connection towards one
 of the floor participants is lost, it is up to the local policy of
 the floor control server what to do with the pending floor requests
 of the floor participant.  In any case, it is RECOMMENDED that the
 floor control server keep the floor requests (i.e., that it does not
 cancel them) while the TCP connection is reestablished.
 If a client wishes to end its BFCP connection with a floor control
 server, the client closes (i.e., a graceful close) the TCP connection
 towards the floor control server.  If a floor control server wishes
 to end its BFCP connection with a client (e.g., the Focus of the
 conference informs the floor control server that the client has been
 kicked out from the conference), the floor control server closes
 (i.e., a graceful close) the TCP connection towards the client.

7. Lower-Layer Security

 BFCP relies on lower-layer security mechanisms to provide replay and
 integrity protection and confidentiality.  BFCP floor control servers
 and clients (which include both floor participants and floor chairs)
 MUST support TLS [3].  Any BFCP entity MAY support other security
 mechanisms.
 BFCP entities MUST support, at a minimum, the TLS
 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5].
 Which party, the client or the floor control server, acts as the TLS
 server depends on how the underlying TCP connection is established.
 For example, when the TCP connection is established using an SDP
 offer/answer exchange [7], the answerer (which may be the client or
 the floor control server) always acts as the TLS server.

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

Camarillo, et al. Standards Track [Page 35] RFC 4582 BFCP November 2006

 Server-initiated transactions consist of a single message from a
 floor control server to a client.  Since they do not trigger any
 response, their Transaction ID is set to 0.

8.1. Client Behavior

 A client starting a client-initiated transaction MUST set the
 Conference ID in the common header of the message to the Conference
 ID for the conference that the client obtained previously.
 The client MUST set the Transaction ID value in the common header to
 a number that is different from 0 and that MUST NOT be reused in
 another message from the client until a response from the server is
 received for the transaction.  The client uses the Transaction ID
 value to match this message with the response from the floor control
 server.

8.2. Server Behavior

 A floor control server sending a response within a client-initiated
 transaction MUST copy the Conference ID, the Transaction ID, and the
 User ID from the request received from the client into the response.
 Server-initiated transactions MUST contain a Transaction ID equal to
 0.

9. Authentication and Authorization

 BFCP clients SHOULD authenticate the floor control server before
 sending any BFCP message to it or accepting any BFCP message from it.
 Similarly, floor control servers SHOULD authenticate a client before
 accepting any BFCP message from it or sending any BFCP message to it.
 BFCP supports TLS-based mutual authentication between clients and
 floor control servers, as specified in Section 9.1.  This is the
 RECOMMENDED authentication mechanism in BFCP.
    Note that future extensions may define additional authentication
    mechanisms.
 In addition to authenticating BFCP messages, floor control servers
 need to authorize them.  On receiving an authenticated BFCP message,
 the floor control server checks whether the client sending the
 message is authorized.  If the client is not authorized to perform
 the operation being requested, the floor control server generates an
 Error message, as described in Section 13.8, with an Error code with
 a value of 5 (Unauthorized Operation).  Messages from a client that
 cannot be authorized MUST NOT be processed further.

Camarillo, et al. Standards Track [Page 36] RFC 4582 BFCP November 2006

9.1. TLS-Based Mutual Authentication

 BFCP supports TLS-based mutual authentication between clients and
 floor control servers.  BFCP assumes that there is an integrity-
 protected channel between the client and the floor control server
 that can be used to exchange their self-signed certificates or, more
 commonly, the fingerprints of these certificates.  These certificates
 are used at TLS establishment time.
    The implementation of such an integrity-protected channel using
    SIP and the SDP offer/answer model is described in [7].
 BFCP messages received over an authenticated TLS connection are
 considered authenticated.  A floor control server that receives a
 BFCP message over TCP (no TLS) can request the use of TLS by
 generating an Error message, as described in Section 13.8, with an
 Error code with a value of 9 (Use TLS).  Clients SHOULD simply ignore
 unauthenticated messages.
    Note that future extensions may define additional authentication
    mechanisms that may not require an initial integrity-protected
    channel (e.g., authentication based on certificates signed by a
    certificate authority).
 As described in Section 9, floor control servers need to perform
 authorization before processing any message.  In particular, the
 floor control server SHOULD check that messages arriving over a given
 authenticated TLS connection use an authorized User ID (i.e., a User
 ID that the user that established the authenticated TLS connection is
 allowed to use).

10. Floor Participant Operations

 This section specifies how floor participants can perform different
 operations, such as requesting a floor, using the protocol elements
 described in earlier sections.  Section 11 specifies operations that
 are specific to floor chairs, such as instructing the floor control
 server to grant or revoke a floor, and Section 12 specifies
 operations that can be performed by any client (i.e., both floor
 participants and floor chairs).

10.1. Requesting a Floor

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

Camarillo, et al. Standards Track [Page 37] RFC 4582 BFCP November 2006

10.1.1. Sending a FloorRequest Message

 The ABNF in Section 5.3.1 describes the attributes that a
 FloorRequest message can contain.  In addition, the ABNF specifies
 normatively which of these attributes are mandatory, and which ones
 are optional.
 The floor participant sets the Conference ID and the Transaction ID
 in the common header following the rules given in Section 8.1.
 The floor participant sets the User ID in the common header to the
 floor participant's identifier.  This User ID will be used by the
 floor control server to authenticate and authorize the request.  If
 the sender of the FloorRequest message (identified by the User ID) is
 not the participant that would eventually get the floor (i.e., a
 third-party floor request), the sender SHOULD add a BENEFICIARY-ID
 attribute to the message identifying the beneficiary of the floor.
    Note that the name space for both the User ID and the Beneficiary
    ID is the same.  That is, a given participant is identified by a
    single 16-bit value that can be used in the User ID in the common
    header and in several attributes: BENEFICIARY-ID, BENEFICIARY-
    INFORMATION, and REQUESTED-BY-INFORMATION.
 The floor participant must insert at least one FLOOR-ID attribute in
 the FloorRequest message.  If the client inserts more than one
 FLOOR-ID attribute, the floor control server will treat all the floor
 requests as an atomic package.  That is, the floor control server
 will either grant or deny all the floors in the FloorRequest message.
 The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute
 to state the reason why the floor or floors are being requested.  The
 Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for
 human consumption.
 The floor participant may request that the server handle the floor
 request with a certain priority using a PRIORITY attribute.

10.1.2. Receiving a Response

 A message from the floor control server is considered a response to
 the FloorRequest message if the message from the floor control server
 has the same Conference ID, Transaction ID, and User ID as the
 FloorRequest message, as described in Section 8.1.  On receiving such
 a response, the floor participant follows the rules in Section 9 that
 relate to floor control server authentication.

Camarillo, et al. Standards Track [Page 38] RFC 4582 BFCP November 2006

 The successful processing of a FloorRequest message at the floor
 control server involves generating one or several FloorRequestStatus
 messages.  The floor participant obtains a Floor Request ID in the
 Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in
 the first FloorRequestStatus message from the floor control server.
 Subsequent FloorRequestStatus messages from the floor control server
 regarding the same floor request will carry the same Floor Request ID
 in a FLOOR-REQUEST-INFORMATION attribute as the initial
 FloorRequestStatus message.  This way, the floor participant can
 associate subsequent incoming FloorRequestStatus messages with the
 ongoing floor request.
 The floor participant obtains information about the status of the
 floor request in the FLOOR-REQUEST-INFORMATION attribute of each of
 the FloorRequestStatus messages received from the floor control
 server.  This attribute is a grouped attribute, and as such it
 includes a number of attributes that provide information about the
 floor request.
 The OVERALL-REQUEST-STATUS attribute provides information about the
 overall status of the floor request.  If the Request Status value is
 Granted, all the floors that were requested in the FloorRequest
 message have been granted.  If the Request Status value is Denied,
 all the floors that were requested in the FloorRequest message have
 been denied.  A floor request is considered to be ongoing while it is
 in the Pending, Accepted, or Granted states.  If the floor request
 value is unknown, then the response is still processed.  However, no
 meaningful value can be reported to the user.
 The STATUS-INFO attribute, if present, provides extra information
 that the floor participant MAY display to the user.
 The FLOOR-REQUEST-STATUS attributes provide information about the
 status of the floor request as it relates to a particular floor.  The
 STATUS-INFO attribute, if present, provides extra information that
 the floor participant MAY display to the user.
 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of
 the floor request in third-party floor requests.  The
 REQUESTED-BY-INFORMATION attribute need not be present in
 FloorRequestStatus messages received by the floor participant that
 requested the floor, as this floor participant is already identified
 by the User ID in the common header.
 The PRIORITY attribute, when present, contains the priority that was
 requested by the generator of the FloorRequest message.

Camarillo, et al. Standards Track [Page 39] RFC 4582 BFCP November 2006

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

10.2. Cancelling a Floor Request and Releasing a Floor

 A floor participant that wishes to cancel an ongoing floor request
 does so by sending a FloorRelease message to the floor control
 server.  The FloorRelease message is also used by floor participants
 that hold a floor and would like to release it.

10.2.1. Sending a FloorRelease Message

 The ABNF in Section 5.3.2 describes the attributes that a
 FloorRelease message can contain.  In addition, the ABNF specifies
 normatively which of these attributes are mandatory, and which ones
 are optional.
 The floor participant sets the Conference ID and the Transaction ID
 in the common header following the rules given in Section 8.1.  The
 floor participant sets the User ID in the common header to the floor
 participant's identifier.  This User ID will be used by the floor
 control server to authenticate and authorize the request.
    Note that the FloorRelease message is used to release a floor or
    floors that were granted and to cancel ongoing floor requests
    (from the protocol perspective, both are ongoing floor requests).
    Using the same message in both situations helps resolve the race
    condition that occurs when the FloorRelease message and the
    FloorGrant message cross each other on the wire.
 The floor participant uses the FLOOR-REQUEST-ID that was received in
 the response to the FloorRequest message that the FloorRelease
 message is cancelling.
    Note that if the floor participant requested several floors as an
    atomic operation (i.e., in a single FloorRequest message), all the
    floors are released as an atomic operation as well (i.e., all are
    released at the same time).

10.2.2. Receiving a Response

 A message from the floor control server is considered a response to
 the FloorRelease message if the message from the floor control server
 has the same Conference ID, Transaction ID, and User ID as the
 FloorRequest message, as described in Section 8.1.  On receiving such
 a response, the floor participant follows the rules in Section 9 that
 relate to floor control server authentication.

Camarillo, et al. Standards Track [Page 40] RFC 4582 BFCP November 2006

 If the response is a FloorRequestStatus message, the Request Status
 value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-
 REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.
 If the response is an Error message, the floor control server could
 not process the FloorRequest message for some reason, which is
 described in the Error message.
 It is possible that the FloorRelease message crosses on the wire with
 a FloorRequestStatus message from the server with a Request Status
 different from Cancelled or Released.  In any case, such a
 FloorRequestStatus message will not be a response to the FloorRelease
 message, as its Transaction ID will not match that of the
 FloorRelease.

11. Chair Operations

 This section specifies how floor chairs can instruct the floor
 control server to grant or revoke a floor using the protocol elements
 described in earlier sections.
 Floor chairs that wish to send instructions to a floor control server
 do so by sending a ChairAction message.

11.1. Sending a ChairAction Message

 The ABNF in Section 5.3.9 describes the attributes that a ChairAction
 message can contain.  In addition, the ABNF specifies normatively
 which of these attributes are mandatory, and which ones are optional.
 The floor chair sets the Conference ID and the Transaction ID in the
 common header following the rules given in Section 8.1.  The floor
 chair sets the User ID in the common header to the floor
 participant's identifier.  This User ID will be used by the floor
 control server to authenticate and authorize the request.
 The ChairAction message contains instructions that apply to one or
 more floors within a particular floor request.  The floor or floors
 are identified by the FLOOR-REQUEST-STATUS attributes and the floor
 request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which
 are carried in the ChairAction message.
 For example, if a floor request consists of two floors that depend on
 different floor chairs, each floor chair will grant its floor within
 the floor request.  Once both chairs have granted their floor, the
 floor control server will grant the floor request as a whole.  On the
 other hand, if one of the floor chairs denies its floor, the floor

Camarillo, et al. Standards Track [Page 41] RFC 4582 BFCP November 2006

 control server will deny the floor request as a whole, regardless of
 the other floor chair's decision.
 The floor chair provides the new status of the floor request as it
 relates to a particular floor using a FLOOR-REQUEST-STATUS attribute.
 If the new status of the floor request is Accepted, the floor chair
 MAY use the Queue Position field to provide a queue position for the
 floor request.  If the floor chair does not wish to provide a queue
 position, all the bits of the Queue Position field SHOULD be set to
 zero.  The floor chair SHOULD use the Status Revoked to revoke a
 floor that was granted (i.e., Granted status) and SHOULD use the
 Status Denied to reject floor requests in any other status (e.g.,
 Pending and Accepted).
 The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the
 ChairAction message to provide a new overall status for the floor
 request.  If the new overall status of the floor request is Accepted,
 the floor chair MAY use the Queue Position field to provide a queue
 position for the floor request.
    Note that a particular floor control server may implement a
    different queue for each floor containing all the floor requests
    that relate to that particular floor, a general queue for all
    floor requests, or both.  Also note that a floor request may
    involve several floors and that a ChairAction message may only
    deal with a subset of these floors (e.g., if a single floor chair
    is not authorized to manage all the floors).  In this case, the
    floor control server will combine the instructions received from
    the different floor chairs in FLOOR-REQUEST-STATUS attributes to
    come up with the overall status of the floor request.
    Note that, while the action of a floor chair may communicate
    information in the OVERALL-REQUEST-STATUS attribute, the floor
    control server may override, modify, or ignore this field's
    content.
 The floor chair may use STATUS-INFO attributes to state the reason
 why the floor or floors are being accepted, granted, or revoked.  The
 Text in the STATUS-INFO attribute is intended for human consumption.

11.2. Receiving a Response

 A message from the floor control server is considered a response to
 the ChairAction message if the message from the server has the same
 Conference ID, Transaction ID, and User ID as the ChairAction
 message, as described in Section 8.1.  On receiving such a response,
 the floor chair follows the rules in Section 9 that relate to floor
 control server authentication.

Camarillo, et al. Standards Track [Page 42] RFC 4582 BFCP November 2006

 A ChairActionAck message from the floor control server confirms that
 the floor control server has accepted the ChairAction message.  An
 Error message indicates that the floor control server could not
 process the ChairAction message for some reason, which is described
 in the Error message.

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 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 status of one or several floors
 by sending a FloorQuery message to the floor control server.

12.1.1. Sending a FloorQuery Message

 The ABNF in Section 5.3.7 describes the attributes that a FloorQuery
 message can contain.  In addition, the ABNF specifies normatively
 which of these attributes are mandatory, and which ones are optional.
 The client sets the Conference ID and the Transaction ID in the
 common header following the rules given in Section 8.1.  The client
 sets the User ID in the common header to the client's identifier.
 This User ID will be used by the floor control server to authenticate
 and authorize the request.
 The client inserts in the message all the Floor IDs it wants to
 receive information about.  The floor control server will send
 periodic information about all of these floors.  If the client does
 not want to receive information about a particular floor any longer,
 it sends a new FloorQuery message removing the FLOOR-ID of this
 floor.  If the client does not want to receive information about any
 floor any longer, it sends a FloorQuery message with no FLOOR-ID
 attribute.

12.1.2. Receiving a Response

 A message from the floor control server is considered a response to
 the FloorQuery message if the message from the floor control server
 has the same Conference ID, Transaction ID, and User ID as the

Camarillo, et al. Standards Track [Page 43] RFC 4582 BFCP November 2006

 FloorRequest message, as described in Section 8.1.  On receiving such
 a response, the client follows the rules in Section 9 that relate to
 floor control server authentication.
 On reception of the FloorQuery message, the floor control server will
 respond with a FloorStatus message or with an Error message.  If the
 response is a FloorStatus message, it will contain information about
 one of the floors the client requested information about.  If the
 client did not include any FLOOR-ID attribute in its FloorQuery
 message (i.e., the client does not want to receive information about
 any floor any longer), the FloorStatus message from the floor control
 server will not include any FLOOR-ID attribute either.
 FloorStatus messages that carry information about a floor contain a
 FLOOR-ID attribute that identifies the floor.  After this attribute,
 FloorStatus messages contain information about existing (one or more)
 floor requests that relate to that floor.  The information about each
 particular floor request is encoded in a FLOOR-REQUEST-INFORMATION
 attribute.  This grouped attribute carries a Floor Request ID that
 identifies the floor request, followed by a set of attributes that
 provide information about the floor request.
 After the first FloorStatus, the floor control server will continue
 sending FloorStatus messages, periodically informing the client about
 changes on the floors the client requested information about.

12.2. Requesting Information about Floor Requests

 A client can obtain information about the status of one or several
 floor requests in different ways, which include using BFCP and using
 out-of-band mechanisms.  Clients using BFCP to obtain such
 information use the procedures described in this section.
 Clients request information about the current status of a floor
 request by sending a FloorRequestQuery message to the floor control
 server.
 Requesting information about a particular floor request is useful in
 a number of situations.  For example, on reception of a FloorRequest
 message, a floor control server may choose to return
 FloorRequestStatus messages only when the floor request changes its
 state (e.g., from Accepted to Granted), but not when the floor
 request advances in its queue.  In this situation, if the user
 requests it, the floor participant can use a FloorRequestQuery
 message to poll the floor control server for the status of the floor
 request.

Camarillo, et al. Standards Track [Page 44] RFC 4582 BFCP November 2006

12.2.1. Sending a FloorRequestQuery Message

 The ABNF in Section 5.3.3 describes the attributes that a
 FloorRequestQuery message can contain.  In addition, the ABNF
 specifies normatively which of these attributes are mandatory, and
 which ones are optional.
 The client sets the Conference ID and the Transaction ID in the
 common header following the rules given in Section 8.1.  The client
 sets the User ID in the common header to the client's identifier.
 This User ID will be used by the floor control server to authenticate
 and authorize the request.
 The client must insert a FLOOR-REQUEST-ID attribute that identifies
 the floor request at the floor control server.

12.2.2. Receiving a Response

 A message from the floor control server is considered a response to
 the FloorRequestQuery message if the message from the floor control
 server has the same Conference ID, Transaction ID, and User ID as the
 FloorRequestQuery message, as described in Section 8.1.  On receiving
 such a response, the client follows the rules in Section 9 that
 relate to floor control server authentication.
 If the response is a FloorRequestStatus message, the client obtains
 information about the status of the FloorRequest the client requested
 information about in a FLOOR-REQUEST-INFORMATION attribute.
 If the response is an Error message, the floor control server could
 not process the FloorRequestQuery message for some reason, which is
 described in the Error message.

12.3. Requesting Information about a User

 A client can obtain information about a participant and the floor
 requests related to this participant in different ways, which include
 using BFCP and using out-of-band mechanisms.  Clients using BFCP to
 obtain such information use the procedures described in this section.
 Clients request information about a participant and the floor
 requests related to this participant by sending a UserQuery message
 to the floor control server.
 This functionality may be useful for floor chairs or floor
 participants interested in the display name and the URI of a
 particular floor participant.  In addition, a floor participant may
 find it useful to request information about itself.  For example, a

Camarillo, et al. Standards Track [Page 45] RFC 4582 BFCP November 2006

 floor participant, after experiencing connectivity problems (e.g.,
 its TCP connection with the floor control server was down for a while
 and eventually was re-established), may need to request information
 about all the floor requests associated to itself that still exist.

12.3.1. Sending a UserQuery Message

 The ABNF in Section 5.3.5 describes the attributes that a UserQuery
 message can contain.  In addition, the ABNF specifies normatively
 which of these attributes are mandatory, and which ones are optional.
 The client sets the Conference ID and the Transaction ID in the
 common header following the rules given in Section 8.1.  The client
 sets the User ID in the common header to the client's identifier.
 This User ID will be used by the floor control server to authenticate
 and authorize the request.
 If the floor participant the client is requesting information about
 is not the client issuing the UserQuery message (which is identified
 by the User ID in the common header of the message), the client MUST
 insert a BENEFICIARY-ID attribute.

12.3.2. Receiving a Response

 A message from the floor control server is considered a response to
 the UserQuery message if the message from the floor control server
 has the same Conference ID, Transaction ID, and User ID as the
 UserQuery message, as described in Section 8.1.  On receiving such a
 response, the client follows the rules in Section 9 that relate to
 floor control server authentication.
 If the response is a UserStatus message, the client obtains
 information about the floor participant in a BENEFICIARY-INFORMATION
 grouped attribute and about the status of the floor requests
 associated with the floor participant in FLOOR-REQUEST-INFORMATION
 attributes.
 If the response is an Error message, the floor control server could
 not process the UserQuery message for some reason, which is described
 in the Error message.

12.4. Obtaining the Capabilities of a Floor Control Server

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

Camarillo, et al. Standards Track [Page 46] RFC 4582 BFCP November 2006

12.4.1. Sending a Hello Message

 The ABNF in Section 5.3.11 describes the attributes that a Hello
 message can contain.  In addition, the ABNF specifies normatively
 which of these attributes are mandatory, and which ones are optional.
 The client sets the Conference ID and the Transaction ID in the
 common header following the rules given in Section 8.1.  The client
 sets the User ID in the common header to the client's identifier.
 This User ID will be used by the floor control server to authenticate
 and authorize the request.

12.4.2. Receiving Responses

 A message from the floor control server is considered a response to
 the Hello message by the client if the message from the floor control
 server has the same Conference ID, Transaction ID, and User ID as the
 Hello message, as described in Section 8.1.  On receiving such a
 response, the client follows the rules in Section 9 that relate to
 floor control server authentication.
 If the response is a HelloAck message, the floor control server could
 process the Hello message successfully.  The SUPPORTED-PRIMITVIES and
 SUPPORTED-ATTRIBUTES attributes indicate which primitives and
 attributes, respectively, are supported by the server.
 If the response is an Error message, the floor control server could
 not process the Hello message for some reason, which is described in
 the Error message.

13. Floor Control Server Operations

 This section specifies how floor control servers can perform
 different operations, such as granting a floor, using the protocol
 elements described in earlier sections.
 On reception of a message from a client, the floor control server
 MUST check whether the value of the Primitive is supported.  If it
 does not, the floor control server SHOULD send an Error message, as
 described in Section 13.8, with Error code 3 (Unknown Primitive).
 On reception of a message from a client, the floor control server
 MUST check whether the value of the Conference ID matched an existing
 conference.  If it does not, the floor control server SHOULD send an
 Error message, as described in Section 13.8, with Error code 1
 (Conference does not Exist).

Camarillo, et al. Standards Track [Page 47] RFC 4582 BFCP November 2006

 On reception of a message from a client, the floor control server
 follows the rules in Section 9 that relate to the authentication of
 the message.
 On reception of a message from a client, the floor control server
 MUST check whether it understands all the mandatory ('M' bit set)
 attributes in the message.  If the floor control server does not
 understand all of them, the floor control server SHOULD send an Error
 message, as described in Section 13.8, with Error code 2
 (Authentication Failed).  The Error message SHOULD list the
 attributes that were not understood.

13.1. Reception of a FloorRequest Message

 On reception of a FloorRequest message, the floor control server
 follows the rules in Section 9 that relate to client authentication
 and authorization.  If while processing the FloorRequest message, the
 floor control server encounters an error, it SHOULD generate an Error
 response following the procedures described in Section 13.8.
    BFCP allows floor participants to have several ongoing floor
    requests for the same floor (e.g., the same floor participant can
    occupy more than one position in a queue at the same time).  A
    floor control server that only supports a certain number of
    ongoing floor requests per floor participant (e.g., one) can use
    Error Code 8 (You have Already Reached the Maximum Number of
    Ongoing Floor Requests for this Floor) to inform the floor
    participant.

13.1.1. Generating the First FloorRequestStatus Message

 The successful processing of a FloorRequest message by a floor
 control server involves generating one or several FloorRequestStatus
 messages, the first of which SHOULD be generated as soon as possible.
 If the floor control server cannot accept, grant, or deny the floor
 request right away (e.g., a decision from a chair is needed), it
 SHOULD use a Request Status value of Pending in the OVERALL-REQUEST-
 STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped
 attribute) of the first FloorRequestStatus message it generates.
    The policy that a floor control server follows to grant or deny
    floors is outside the scope of this document.  A given floor
    control server may perform these decisions automatically while
    another may contact a human acting as a chair every time a
    decision needs to be made.
 The floor control server MUST copy the Conference ID, the Transaction
 ID, and the User ID from the FloorRequest into the

Camarillo, et al. Standards Track [Page 48] RFC 4582 BFCP November 2006

 FloorRequestStatus, as described in Section 8.2.  Additionally, the
 floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
 attribute to the FloorRequestStatus.  The attributes contained in
 this grouped attribute carry information about the floor request.
 The floor control server MUST assign an identifier that is unique
 within the conference to this floor request, and MUST insert it in
 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
 attribute.  This identifier will be used by the floor participant (or
 by a chair or chairs) to refer to this specific floor request in the
 future.
 The floor control server MUST copy the Floor IDs in the FLOOR-ID
 attributes of the FloorRequest into the FLOOR-REQUEST-STATUS
 attributes in the FLOOR-REQUEST-INFORMATION grouped attribute.  These
 Floor IDs identify the floors being requested (i.e., the floors
 associated with this particular floor request).
 The floor control server SHOULD copy (if present) the contents of the
 BENEFICIARY-ID attribute from the FloorRequest into a
 BENEFICIARY-INFORMATION attribute inside the
 FLOOR-REQUEST-INFORMATION grouped attribute.  Additionally, the floor
 control server MAY provide the display name and the URI of the
 beneficiary in this BENEFICIARY-INFORMATION attribute.
 The floor control server MAY provide information about the requester
 of the floor in a REQUESTED-BY-INFORMATION attribute inside the
 FLOOR-REQUEST-INFORMATION grouped attribute.
 The floor control server MAY copy (if present) the PARTICIPANT-
 PROVIDED-INFO attribute from the FloorRequest into the FLOOR-
 REQUEST-INFORMATION grouped attribute.
    Note that this attribute carries the priority requested by the
    participant.  The priority that the floor control server assigns
    to the floor request depends on the priority requested by the
    participant and the rights the participant has according to the
    policy of the conference.  For example, a participant that is only
    allowed to use the Normal priority may request Highest priority
    for a floor request.  In that case, the floor control server would
    ignore the priority requested by the participant.
 The floor control server MAY copy (if present) the
 PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the
 FLOOR-REQUEST-INFORMATION grouped attribute.

Camarillo, et al. Standards Track [Page 49] RFC 4582 BFCP November 2006

13.1.2. Generation of Subsequent FloorRequestStatus Messages

 A floor request is considered to be ongoing as long as it is not in
 the Cancelled, Released, or Revoked states.  If the OVERALL-REQUEST-
 STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped
 attribute) of the first FloorRequestStatus message generated by the
 floor control server did not indicate any of these states, the floor
 control server will need to send subsequent FloorRequestStatus
 messages.
 When the status of the floor request changes, the floor control
 server SHOULD send new FloorRequestStatus messages with the
 appropriate Request Status.  The floor control server MUST add a
 FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to
 the one sent in the first FloorRequestStatus message to any new
 FloorRequestStatus related to the same floor request.  (The Floor
 Request ID identifies the floor request to which the
 FloorRequestStatus applies.)
 The floor control server MUST set the Transaction ID of subsequent
 FloorRequestStatus messages to 0.
    The rate at which the floor control server sends
    FloorRequestStatus messages is a matter of local policy.  A floor
    control server may choose to send a new FloorRequestStatus message
    every time the floor request moves in the floor request queue,
    while another may choose only to send a new FloorRequestStatus
    message when the floor request is Granted or Denied.
 The floor control server may add a STATUS-INFO attribute to any of
 the FloorRequestStatus messages it generates to provide extra
 information about its decisions regarding the floor request (e.g.,
 why it was denied).
    Floor participants and floor chairs may request to be informed
    about the status of a floor following the procedures in
    Section 12.1.  If the processing of a floor request changes the
    status of a floor (e.g., the floor request is granted and
    consequently the floor has a new holder), the floor control server
    needs to follow the procedures in Section 13.5 to inform the
    clients that have requested that information.
 The common header and the rest of the attributes are the same as in
 the first FloorRequestStatus message.
 The floor control server can discard the state information about a
 particular floor request when this reaches a status of Cancelled,
 Released, or Revoked.

Camarillo, et al. Standards Track [Page 50] RFC 4582 BFCP November 2006

13.2. Reception of a FloorRequestQuery Message

 On reception of a FloorRequestQuery message, the floor control server
 follows the rules in Section 9 that relate to client authentication
 and authorization.  If while processing the FloorRequestQuery
 message, the floor control server encounters an error, it SHOULD
 generate an Error response following the procedures described in
 Section 13.8.
 The successful processing of a FloorRequestQuery message by a floor
 control server involves generating a FloorRequestStatus message,
 which SHOULD be generated as soon as possible.
 The floor control server MUST copy the Conference ID, the Transaction
 ID, and the User ID from the FloorRequestQuery message into the
 FloorRequestStatus message, as described in Section 8.2.
 Additionally, the floor control server MUST include information about
 the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute
 to the FloorRequestStatus.
 The floor control server MUST copy the contents of the
 FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into
 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
 attribute.
 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to
 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
 floors being requested (i.e., the floors associated with the floor
 request identified by the FLOOR-REQUEST-ID attribute).
 The floor control server SHOULD add a BENEFICIARY-ID attribute to the
 FLOOR-REQUEST-INFORMATION grouped attribute identifying the
 beneficiary of the floor request.  Additionally, the floor control
 server MAY provide the display name and the URI of the beneficiary in
 this BENEFICIARY-INFORMATION attribute.
 The floor control server MAY provide information about the requester
 of the floor in a REQUESTED-BY-INFORMATION attribute inside the
 FLOOR-REQUEST-INFORMATION grouped attribute.
 The floor control server MAY provide the reason why the floor
 participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
 The floor control server MAY also add to the
 FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with
 the Priority value requested for the floor request and a STATUS-INFO
 attribute with extra information about the floor request.

Camarillo, et al. Standards Track [Page 51] RFC 4582 BFCP November 2006

 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current
 status of the floor request.  The floor control server MAY provide
 information about the status of the floor request as it relates to
 each of the floors being requested in the FLOOR-REQUEST-STATUS
 attributes.

13.3. Reception of a UserQuery Message

 On reception of a UserQuery message, the floor control server follows
 the rules in Section 9 that relate to client authentication and
 authorization.  If while processing the UserQuery message, the floor
 control server encounters an error, it SHOULD generate an Error
 response following the procedures described in Section 13.8.
 The successful processing of a UserQuery message by a floor control
 server involves generating a UserStatus message, which SHOULD be
 generated as soon as possible.
 The floor control server MUST copy the Conference ID, the Transaction
 ID, and the User ID from the UserQuery message into the USerStatus
 message, as described in Section 8.2.
 The sender of the UserQuery message is requesting information about
 all the floor requests associated with a given participant (i.e., the
 floor requests where the participant is either the beneficiary or the
 requester).  This participant is identified by a BENEFICIARY-ID
 attribute or, in the absence of a BENEFICIARY-ID attribute, by a the
 User ID in the common header of the UserQuery message.
 The floor control server MUST copy, if present, the contents of the
 BENEFICIARY-ID attribute from the UserQuery message into a
 BENEFICIARY-INFORMATION attribute in the UserStatus message.
 Additionally, the floor control server MAY provide the display name
 and the URI of the participant about which the UserStatus message
 provides information in this BENEFICIARY-INFORMATION attribute.
 The floor control server SHOULD add to the UserStatus message a
 FLOOR-REQUEST-INFORMATION grouped attribute for each floor request
 related to the participant about which the message provides
 information (i.e., the floor requests where the participant is either
 the beneficiary or the requester).  For each
 FLOOR-REQUEST-INFORMATION attribute, the floor control server follows
 the following steps.
 The floor control server MUST identify the floor request the
 FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor
 Request ID field of the FLOOR-REQUEST-INFORMATION attribute.

Camarillo, et al. Standards Track [Page 52] RFC 4582 BFCP November 2006

 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to
 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
 floors being requested (i.e., the floors associated with the floor
 request identified by the FLOOR-REQUEST-ID attribute).
 The floor control server SHOULD add a BENEFICIARY-ID attribute to the
 FLOOR-REQUEST-INFORMATION grouped attribute identifying the
 beneficiary of the floor request.  Additionally, the floor control
 server MAY provide the display name and the URI of the beneficiary in
 this BENEFICIARY-INFORMATION attribute.
 The floor control server MAY provide information about the requester
 of the floor in a REQUESTED-BY-INFORMATION attribute inside the
 FLOOR-REQUEST-INFORMATION grouped attribute.
 The floor control server MAY provide the reason why the floor
 participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
 The floor control server MAY also add to the FLOOR-REQUEST-
 INFORMATION grouped attribute a PRIORITY attribute with the Priority
 value requested for the floor request.
 The floor control server MUST include the current status of the floor
 request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-
 INFORMATION grouped attribute.  The floor control server MAY add a
 STATUS-INFO attribute with extra information about the floor request.
 The floor control server MAY provide information about the status of
 the floor request as it relates to each of the floors being requested
 in the FLOOR-REQUEST-STATUS attributes.

13.4. Reception of a FloorRelease Message

 On reception of a FloorRelease message, the floor control server
 follows the rules in Section 9 that relate to client authentication
 and authorization.  If while processing the FloorRelease message, the
 floor control server encounters an error, it SHOULD generate an Error
 response following the procedures described in Section 13.8.
 The successful processing of a FloorRelease message by a floor
 control server involves generating a FloorRequestStatus message,
 which SHOULD be generated as soon as possible.
 The floor control server MUST copy the Conference ID, the Transaction
 ID, and the User ID from the FloorRelease message into the
 FloorRequestStatus message, as described in Section 8.2.

Camarillo, et al. Standards Track [Page 53] RFC 4582 BFCP November 2006

 The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
 attribute to the FloorRequestStatus.  The attributes contained in
 this grouped attribute carry information about the floor request.
 The FloorRelease message identifies the floor request it applies to
 using a FLOOR-REQUEST-ID.  The floor control server MUST copy the
 contents of the FLOOR-REQUEST-ID attribute from the FloorRelease
 message into the Floor Request ID field of the
 FLOOR-REQUEST-INFORMATION attribute.
 The floor control server MUST identify the floors being requested
 (i.e., the floors associated with the floor request identified by the
 FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the
 FLOOR-REQUEST-INFORMATION grouped attribute.
 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
 to the FLOOR-REQUEST-INFORMATION grouped attribute.  The Request
 Status value SHOULD be Released, if the floor (or floors) had been
 previously granted, or Cancelled, if the floor (or floors) had not
 been previously granted.  The floor control server MAY add a STATUS-
 INFO attribute with extra information about the floor request.

13.5. Reception of a FloorQuery Message

 On reception of a FloorQuery message, the floor control server
 follows the rules in Section 9 that relate to client authentication.
 If while processing the FloorRelease message, the floor control
 server encounters an error, it SHOULD generate an Error response
 following the procedures described in Section 13.8.
 A floor control server receiving a FloorQuery message from a client
 SHOULD keep this client informed about the status of the floors
 identified by FLOOR-ID attributes in the FloorQuery message.  Floor
 Control Servers keep clients informed by using FloorStatus messages.
 An individual FloorStatus message carries information about a single
 floor.  So, when a FloorQuery message requests information about more
 than one floor, the floor control server needs to send separate
 FloorStatus messages for different floors.
 The information FloorQuery messages carry may depend on the user
 requesting the information.  For example, a chair may be able to
 receive information about pending requests, while a regular user may
 not be authorized to do so.

Camarillo, et al. Standards Track [Page 54] RFC 4582 BFCP November 2006

13.5.1. Generation of the First FloorStatus Message

 The successful processing of a FloorQuery message by a floor control
 server involves generating one or several FloorStatus messages, the
 first of which SHOULD be generated as soon as possible.
 The floor control server MUST copy the Conference ID, the Transaction
 ID, and the User ID from the FloorQuery message into the FloorStatus
 message, as described in Section 8.2.
 If the FloorQuery message did not contain any FLOOR-ID attribute, the
 floor control server sends the FloorStatus message without adding any
 additional attribute and does not send any subsequent FloorStatus
 message to the floor participant.
 If the FloorQuery message contained one or more FLOOR-ID attributes,
 the floor control server chooses one from among them and adds this
 FLOOR-ID attribute to the FloorStatus message.  The floor control
 server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for
 each floor request associated to the floor.  Each
 FLOOR-REQUEST-INFORMATION grouped attribute contains a number of
 attributes that provide information about the floor request.  For
 each FLOOR-REQUEST-INFORMATION attribute, the floor control server
 follows the following steps.
 The floor control server MUST identify the floor request the
 FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor
 Request ID field of the FLOOR-REQUEST-INFORMATION attribute.
 The floor control server MUST add FLOOR-REQUEST-STATUS attributes to
 the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
 floors being requested (i.e., the floors associated with the floor
 request identified by the FLOOR-REQUEST-ID attribute).
 The floor control server SHOULD add a BENEFICIARY-ID attribute to the
 FLOOR-REQUEST-INFORMATION grouped attribute identifying the
 beneficiary of the floor request.  Additionally, the floor control
 server MAY provide the display name and the URI of the beneficiary in
 this BENEFICIARY-INFORMATION attribute.
 The floor control server MAY provide information about the requester
 of the floor in a REQUESTED-BY-INFORMATION attribute inside the
 FLOOR-REQUEST-INFORMATION grouped attribute.

Camarillo, et al. Standards Track [Page 55] RFC 4582 BFCP November 2006

 The floor control server MAY provide the reason why the floor
 participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
 The floor control server MAY also add to the FLOOR-REQUEST-
 INFORMATION grouped attribute a PRIORITY attribute with the Priority
 value requested for the floor request.
 The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
 to the FLOOR-REQUEST-INFORMATION grouped attribute with the current
 status of the floor request.  The floor control server MAY add a
 STATUS-INFO attribute with extra information about the floor request.
 The floor control server MAY provide information about the status of
 the floor request as it relates to each of the floors being requested
 in the FLOOR-REQUEST-STATUS attributes.

13.5.2. Generation of Subsequent FloorStatus Messages

 If the FloorQuery message carried more than one FLOOR-ID attribute,
 the floor control server SHOULD generate a FloorStatus message for
 each of them (except for the FLOOR-ID attribute chosen for the first
 FloorStatus message) as soon as possible.  These FloorStatus messages
 are generated following the same rules as those for the first
 FloorStatus message (see Section 13.5.1), but their Transaction ID is
 0.
 After generating these messages, the floor control server sends
 FloorStatus messages, periodically keeping the client informed about
 all the floors for which the client requested information.  The
 Transaction ID of these messages MUST be 0.
    The rate at which the floor control server sends FloorStatus
    messages is a matter of local policy.  A floor control server may
    choose to send a new FloorStatus message every time a new floor
    request arrives, while another may choose to only send a new
    FloorStatus message when a new floor request is Granted.

13.6. Reception of a ChairAction Message

 On reception of a ChairAction message, the floor control server
 follows the rules in Section 9 that relate to client authentication
 and authorization.  If while processing the ChairAction message, the
 floor control server encounters an error, it SHOULD generate an Error
 response following the procedures described in Section 13.8.
 The successful processing of a ChairAction message by a floor control
 server involves generating a ChairActionAck message, which SHOULD be
 generated as soon as possible.

Camarillo, et al. Standards Track [Page 56] RFC 4582 BFCP November 2006

 The floor control server MUST copy the Conference ID, the Transaction
 ID, and the User ID from the ChairAction message into the
 ChairActionAck message, as described in Section 8.2.
 The floor control server needs to take into consideration the
 operation requested in the ChairAction message (e.g., granting a
 floor) but does not necessarily need to perform it as requested by
 the floor chair.  The operation that the floor control server
 performs depends on the ChairAction message and on the internal state
 of the floor control server.
 For example, a floor chair may send a ChairAction message granting a
 floor that was requested as part of an atomic floor request operation
 that involved several floors.  Even if the chair responsible for one
 of the floors instructs the floor control server to grant the floor,
 the floor control server will not grant it until the chairs
 responsible for the other floors agree to grant them as well.
 So, the floor control server is ultimately responsible for keeping a
 coherent floor state using instructions from floor chairs as input to
 this state.
 If the new Status in the ChairAction message is Accepted and all the
 bits of the Queue Position field are zero, the floor chair is
 requesting that the floor control server assign a queue position
 (e.g., the last in the queue) to the floor request based on the local
 policy of the floor control server.  (Of course, such a request only
 applies if the floor control server implements a queue.)

13.7. Reception of a Hello Message

 On reception of a Hello message, the floor control server follows the
 rules in Section 9 that relate to client authentication.  If while
 processing the Hello message, the floor control server encounters an
 error, it SHOULD generate an Error response following the procedures
 described in Section 13.8.
 The successful processing of a Hello message by a floor control
 server involves generating a HelloAck message, which SHOULD be
 generated as soon as possible.  The floor control server MUST copy
 the Conference ID, the Transaction ID, and the User ID from the Hello
 into the HelloAck, as described in Section 8.2.
 The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to
 the HelloAck message listing all the primitives (i.e., BFCP messages)
 supported by the floor control server.

Camarillo, et al. Standards Track [Page 57] RFC 4582 BFCP November 2006

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

13.8. Error Message Generation

 Error messages are always sent in response to a previous message from
 the client as part of a client-initiated transaction.  The ABNF in
 Section 5.3.13 describes the attributes that an Error message can
 contain.  In addition, the ABNF specifies normatively which of these
 attributes are mandatory and which ones are optional.
 The floor control server MUST copy the Conference ID, the Transaction
 ID, and the User ID from the message from the client into the Error
 message, as described in Section 8.2.
 The floor control server MUST add an ERROR-CODE attribute to the
 Error message.  The ERROR-CODE attribute contains an Error Code from
 Table 5.  Additionally, the floor control server may add an
 ERROR-INFO attribute with extra information about the error.

14. Security Considerations

 BFCP uses TLS to provide mutual authentication between clients and
 servers.  TLS also provides replay and integrity protection and
 confidentiality.  It is RECOMMENDED that TLS with non-null encryption
 always be used.  BFCP entities MAY use other security mechanisms as
 long as they provide similar security properties.
 The remainder of this section analyzes some of the threats against
 BFCP and how they are addressed.
 An attacker may attempt to impersonate a client (a floor participant
 or a floor chair) in order to generate forged floor requests or to
 grant or deny existing floor requests.  Client impersonation is
 avoided by having servers only accept BFCP messages over
 authenticated TLS connections.  The floor control server assumes that
 attackers cannot highjack the TLS connection and, therefore, that
 messages over the TLS connection come from the client that was
 initially authenticated.
 An attacker may attempt to impersonate a floor control server.  A
 successful attacker would be able to make clients think that they
 hold a particular floor so that they would try to access a resource
 (e.g., sending media) without having legitimate rights to access it.
 Floor control server impersonation is avoided by having servers only
 accept BFCP messages over authenticated TLS connections.

Camarillo, et al. Standards Track [Page 58] RFC 4582 BFCP November 2006

 Attackers may attempt to modify messages exchanged by a client and a
 floor control server.  The integrity protection provided by TLS
 connections prevents this attack.
 An attacker may attempt to fetch a valid message sent by a client to
 a floor control server and replay it over a connection between the
 attacker and the floor control server.  This attack is prevented by
 having floor control servers check that messages arriving over a
 given authenticated TLS connection use an authorized user ID (i.e., a
 user ID that the user that established the authenticated TLS
 connection is allowed to use).
 Attackers may attempt to pick messages from the network to get access
 to confidential information between the floor control server and a
 client (e.g., why a floor request was denied).  TLS confidentiality
 prevents this attack.  Therefore, it is RECOMMENDED that TLS be used
 with a non-null encryption algorithm.

15. IANA Considerations

 The IANA has created a new registry for BFCP parameters called
 "Binary Floor Control Protocol (BFCP) Parameters".  This new registry
 has a number of subregistries, which are described in the following
 sections.

15.1. Attribute Subregistry

 This section establishes the Attribute subregistry under the BFCP
 Parameters registry.  As per the terminology in RFC 2434 [4], the
 registration policy for BFCP attributes shall be "Specification
 Required".  For the purposes of this subregistry, the BFCP attributes
 for which IANA registration is requested MUST be defined by a
 standards-track RFC.  Such an RFC MUST specify the attribute's type,
 name, format, and semantics.
 For each BFCP attribute, the IANA registers its type, its name, and
 the reference to the RFC where the attribute is defined.  The
 following table contains the initial values of this subregistry.

Camarillo, et al. Standards Track [Page 59] RFC 4582 BFCP November 2006

         +------+---------------------------+------------+
         | Type | Attribute                 | Reference  |
         +------+---------------------------+------------+
         |   1  | BENEFICIARY-ID            | [RFC 4582] |
         |   2  | FLOOR-ID                  | [RFC 4582] |
         |   3  | FLOOR-REQUEST-ID          | [RFC 4582] |
         |   4  | PRIORITY                  | [RFC 4582] |
         |   5  | REQUEST-STATUS            | [RFC 4582] |
         |   6  | ERROR-CODE                | [RFC 4582] |
         |   7  | ERROR-INFO                | [RFC 4582] |
         |   8  | PARTICIPANT-PROVIDED-INFO | [RFC 4582] |
         |   9  | STATUS-INFO               | [RFC 4582] |
         |  10  | SUPPORTED-ATTRIBUTES      | [RFC 4582] |
         |  11  | SUPPORTED-PRIMITIVES      | [RFC 4582] |
         |  12  | USER-DISPLAY-NAME         | [RFC 4582] |
         |  13  | USER-URI                  | [RFC 4582] |
         |  14  | BENEFICIARY-INFORMATION   | [RFC 4582] |
         |  15  | FLOOR-REQUEST-INFORMATION | [RFC 4582] |
         |  16  | REQUESTED-BY-INFORMATION  | [RFC 4582] |
         |  17  | FLOOR-REQUEST-STATUS      | [RFC 4582] |
         |  18  | OVERALL-REQUEST-STATUS    | [RFC 4582] |
         +------+---------------------------+------------+
       Table 6: Initial values of the BFCP Attribute subregistry

15.2. Primitive Subregistry

 This section establishes the Primitive subregistry under the BFCP
 Parameters registry.  As per the terminology in RFC 2434 [4], the
 registration policy for BFCP primitives shall be "Specification
 Required".  For the purposes of this subregistry, the BFCP primitives
 for which IANA registration is requested MUST be defined by a
 standards-track RFC.  Such an RFC MUST specify the primitive's value,
 name, format, and semantics.
 For each BFCP primitive, the IANA registers its value, its name, and
 the reference to the RFC where the primitive is defined.  The
 following table contains the initial values of this subregistry.

Camarillo, et al. Standards Track [Page 60] RFC 4582 BFCP November 2006

              +-------+--------------------+------------+
              | Value | Primitive          | Reference  |
              +-------+--------------------+------------+
              |   1   | FloorRequest       | [RFC 4582] |
              |   2   | FloorRelease       | [RFC 4582] |
              |   3   | FloorRequestQuery  | [RFC 4582] |
              |   4   | FloorRequestStatus | [RFC 4582] |
              |   5   | UserQuery          | [RFC 4582] |
              |   6   | UserStatus         | [RFC 4582] |
              |   7   | FloorQuery         | [RFC 4582] |
              |   8   | FloorStatus        | [RFC 4582] |
              |   9   | ChairAction        | [RFC 4582] |
              |   10  | ChairActionAck     | [RFC 4582] |
              |   11  | Hello              | [RFC 4582] |
              |   12  | HelloAck           | [RFC 4582] |
              |   13  | Error              | [RFC 4582] |
              +-------+--------------------+------------+
       Table 7: Initial values of the BFCP primitive subregistry

15.3. Request Status Subregistry

 This section establishes the Request Status subregistry under the
 BFCP Parameters registry.  As per the terminology in RFC 2434 [4],
 the registration policy for BFCP request status shall be
 "Specification Required".  For the purposes of this subregistry, the
 BFCP request status for which IANA registration is requested MUST be
 defined by a standards-track RFC.  Such an RFC MUST specify the value
 and the semantics of the request status.
 For each BFCP request status, the IANA registers its value, its
 meaning, and the reference to the RFC where the request status is
 defined.  The following table contains the initial values of this
 subregistry.
                  +-------+-----------+------------+
                  | Value | Status    | Reference  |
                  +-------+-----------+------------+
                  |   1   | Pending   | [RFC 4582] |
                  |   2   | Accepted  | [RFC 4582] |
                  |   3   | Granted   | [RFC 4582] |
                  |   4   | Denied    | [RFC 4582] |
                  |   5   | Cancelled | [RFC 4582] |
                  |   6   | Released  | [RFC 4582] |
                  |   7   | Revoked   | [RFC 4582] |
                  +-------+-----------+------------+
       Table 8: Initial values of the Request Status subregistry

Camarillo, et al. Standards Track [Page 61] RFC 4582 BFCP November 2006

15.4. Error Code Subregistry

 This section establishes the Error Code subregistry under the BFCP
 Parameters registry.  As per the terminology in RFC 2434 [4], the
 registration policy for BFCP error codes shall be "Specification
 Required".  For the purposes of this subregistry, the BFCP error
 codes for which IANA registration is requested MUST be defined by a
 standards-track RFC.  Such an RFC MUST specify the value and the
 semantics of the error code, and any Error Specific Details that
 apply to it.
 For each BFCP primitive, the IANA registers its value, its meaning,
 and the reference to the RFC where the primitive is defined.  The
 following table contains the initial values of this subregistry.

+——-+———————————————–+————+ | Value | Meaning | Reference | +——-+———————————————–+————+ | 1 | Conference does not Exist | [RFC 4582] | | 2 | User does not Exist | [RFC 4582] | | 3 | Unknown Primitive | [RFC 4582] | | 4 | Unknown Mandatory Attribute | [RFC 4582] | | 5 | Unauthorized Operation | [RFC 4582] | | 6 | Invalid Floor ID | [RFC 4582] | | 7 | Floor Request ID Does Not Exist | [RFC 4582] | | 8 | You have Already Reached the Maximum Number | [RFC 4582] | | | of Ongoing Floor Requests for this Floor | | | 9 | Use TLS | [RFC 4582] | +——-+———————————————–+———–+

         Table 9: Initial Values of the Error Code subregistry

16. Acknowledgements

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

Camarillo, et al. Standards Track [Page 62] RFC 4582 BFCP November 2006

17. References

17.1. Normative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [2]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
      Specifications: ABNF", RFC 4234, October 2005.
 [3]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
      Protocol Version 1.1", RFC 4346, April 2006.
 [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 [5]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
      Transport Layer Security (TLS)", RFC 3268, June 2002.
 [6]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
      63, RFC 3629, November 2003.
 [7]  Camarillo, G., "Session Description Protocol (SDP) Format for
      Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
      November 2006.

17.2. Informational References

 [8]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
       Session Description Protocol (SDP)", RFC 3264, June 2002.
 [9]  Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
       "Requirements for Floor Control Protocols", RFC 4376, February
       2006.
 [10]  Barnes, M. and C. Boulton, "A Framework and Data Model for
       Centralized Conferencing", Work in Progress, February 2005.

Camarillo, et al. Standards Track [Page 63] RFC 4582 BFCP November 2006

Authors' Addresses

 Gonzalo Camarillo
 Ericsson
 Hirsalantie 11
 Jorvas  02420
 Finland
 EMail: Gonzalo.Camarillo@ericsson.com
 Joerg Ott
 Helsinki University of Technology
 Department for Electrical and Communications Engineering
 Networking Laboratory
 PO Box 3000
 02015 TKK
 Finland
 EMail: jo@netlab.hut.fi
 Keith Drage
 Lucent Technologies
 Windmill Hill Business Park
 Swindon
 Wiltshire  SN5 6PP
 UK
 EMail: drage@lucent.com

Camarillo, et al. Standards Track [Page 64] RFC 4582 BFCP November 2006

Full Copyright Statement

 Copyright (C) The IETF Trust (2006).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
 PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 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.

Acknowledgement

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

Camarillo, et al. Standards Track [Page 65]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4582.txt · Last modified: 2006/11/18 03:42 (external edit)