[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-camarillo-xcon-bfcp) 00 01 02 03 04 05 06 RFC 4582

XCON Working Group                                          G. Camarillo
Internet-Draft                                                  Ericsson
Expires: June 2, 2006                                             J. Ott
                                       Helsinki University of Technology
                                                                K. Drage
                                                     Lucent Technologies
                                                       November 29, 2005


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on June 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   Floor control is a means to manage joint or exclusive access to
   shared resources in a (multiparty) conferencing environment.
   Thereby, floor control complements other functions -- such as
   conference and media session setup, conference policy manipulation,
   and media control -- that are realized by other protocols.



Camarillo, et al.         Expires June 2, 2006                  [Page 1]

Internet-Draft                    BFCP                     November 2005


   This document specifies the Binary Floor Control Protocol (BFCP).
   BFCP is used between floor participants and floor control servers,
   and between floor chairs (i.e., moderators) and floor control
   servers.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Floor Creation . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Obtaining Information to Contact a Floor Control Server  .  8
     3.3.  Obtaining Floor-Resource Associations  . . . . . . . . . .  8
     3.4.  Privileges of Floor Control  . . . . . . . . . . . . . . .  8
   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Floor Participant to Floor Control Server Interface  . . .  9
     4.2.  Floor Chair to Floor Control Server Interface  . . . . . . 13
   5.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 14
     5.2.  Attribute Format . . . . . . . . . . . . . . . . . . . . . 16
       5.2.1.  BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17
       5.2.2.  FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 18
       5.2.3.  FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18
       5.2.4.  PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 18
       5.2.5.  REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 19
       5.2.6.  ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 20
       5.2.7.  ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 22
       5.2.8.  PARTICIPANT-PROVIDED-INFO  . . . . . . . . . . . . . . 22
       5.2.9.  STATUS-INFO  . . . . . . . . . . . . . . . . . . . . . 23
       5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 24
       5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 24
       5.2.12. USER-DISPLAY-NAME  . . . . . . . . . . . . . . . . . . 25
       5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 26
       5.2.14. BENEFICIARY-INFORMATION  . . . . . . . . . . . . . . . 26
       5.2.15. FLOOR-REQUEST-INFORMATION  . . . . . . . . . . . . . . 27
       5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 28
     5.3.  Message Format . . . . . . . . . . . . . . . . . . . . . . 28
       5.3.1.  FloorRequest . . . . . . . . . . . . . . . . . . . . . 29
       5.3.2.  FloorRelease . . . . . . . . . . . . . . . . . . . . . 29
       5.3.3.  FloorRequestQuery  . . . . . . . . . . . . . . . . . . 29
       5.3.4.  FloorRequestStatus . . . . . . . . . . . . . . . . . . 29
       5.3.5.  UserQuery  . . . . . . . . . . . . . . . . . . . . . . 30
       5.3.6.  UserStatus . . . . . . . . . . . . . . . . . . . . . . 30
       5.3.7.  FloorQuery . . . . . . . . . . . . . . . . . . . . . . 30
       5.3.8.  FloorStatus  . . . . . . . . . . . . . . . . . . . . . 31
       5.3.9.  ChairAction  . . . . . . . . . . . . . . . . . . . . . 31
       5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 31



Camarillo, et al.         Expires June 2, 2006                  [Page 2]

Internet-Draft                    BFCP                     November 2005


       5.3.11. Hello  . . . . . . . . . . . . . . . . . . . . . . . . 32
       5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 32
       5.3.13. Error  . . . . . . . . . . . . . . . . . . . . . . . . 32
   6.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   7.  Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 33
   8.  Protocol Transactions  . . . . . . . . . . . . . . . . . . . . 34
     8.1.  Client Behavior  . . . . . . . . . . . . . . . . . . . . . 34
     8.2.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . 34
   9.  Authentication and Authorization . . . . . . . . . . . . . . . 34
     9.1.  TLS-based Mutual Authentication  . . . . . . . . . . . . . 35
   10. Floor Participant Operations . . . . . . . . . . . . . . . . . 36
     10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 36
       10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 36
       10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 37
     10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 38
       10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 38
       10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 39
   11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 39
     11.1. Sending a ChairAction Message  . . . . . . . . . . . . . . 39
     11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 40
   12. General Client Operations  . . . . . . . . . . . . . . . . . . 41
     12.1. Requesting Information about Floors  . . . . . . . . . . . 41
       12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 41
       12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 41
     12.2. Requesting Information about Floor Requests  . . . . . . . 42
       12.2.1. Sending a FloorRequestQuery Message  . . . . . . . . . 42
       12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 43
     12.3. Requesting Information about a User  . . . . . . . . . . . 43
       12.3.1. Sending a UserQuery Message  . . . . . . . . . . . . . 44
       12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 44
     12.4. Obtaining the Capabilities of a Floor Control Server . . . 44
       12.4.1. Sending a Hello Message  . . . . . . . . . . . . . . . 44
       12.4.2. Receiving Responses  . . . . . . . . . . . . . . . . . 45
   13. Floor Control Server Operations  . . . . . . . . . . . . . . . 45
     13.1. Reception of a FloorRequest Message  . . . . . . . . . . . 46
       13.1.1. Generating the First FloorRequestStatus Message  . . . 46
       13.1.2. Generation of Subsequent FloorRequestStatus
               Messages . . . . . . . . . . . . . . . . . . . . . . . 47
     13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 48
     13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 49
     13.4. Reception of a FloorRelease Message  . . . . . . . . . . . 51
     13.5. Reception of a FloorQuery Message  . . . . . . . . . . . . 52
       13.5.1. Generation of the First FloorStatus Message  . . . . . 52
       13.5.2. Generation of Subsequent FloorStatus Messages  . . . . 54
     13.6. Reception of a ChairAction Message . . . . . . . . . . . . 54
     13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 55
     13.8. Error Message Generation . . . . . . . . . . . . . . . . . 55
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 56



Camarillo, et al.         Expires June 2, 2006                  [Page 3]

Internet-Draft                    BFCP                     November 2005


   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 57
     15.1. Attribute Subregistry  . . . . . . . . . . . . . . . . . . 57
     15.2. Primitive Subregistry  . . . . . . . . . . . . . . . . . . 58
     15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 58
     15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 59
   16. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 60
   17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
     17.1. Normative References . . . . . . . . . . . . . . . . . . . 60
     17.2. Informational References . . . . . . . . . . . . . . . . . 60
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
   Intellectual Property and Copyright Statements . . . . . . . . . . 63








































Camarillo, et al.         Expires June 2, 2006                  [Page 4]

Internet-Draft                    BFCP                     November 2005


1.  Introduction

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

   The Requirements for Floor Control Protocol [10] list a set of
   requirements that need to be met by floor control protocols.  The
   Binary Floor Control Protocol (BFCP), which is specified in this
   document, meets these requirements.

   In addition, BFCP has been designed so that it can be used in low-
   bandwidth environments.  The binary encoding used by BFCP achieves a
   small message size (when message signatures are not used) that keeps
   the time it takes to transmit delay-sensitive BFCP messages at
   minimum.  Delay-sensitive BFCP messages include FloorRequest,
   FloorRelease, FloorRequestStatus, and ChairAction.  It is expected
   that future extensions to these messages do not increase the size of
   these messages in a significant way.

   The remainder of this document is organized as follows: 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 co-
   located with a floor participant, but does not need to.  Third-party
   floor requests consist of having a floor participant request a floor
   for a media participant when they are not colocated.  The protocol
   between a floor participant and a media participant (that are not
   colocated) is outside the scope of this document.

   Client: a floor participant or a floor chair that communicate with a



Camarillo, et al.         Expires June 2, 2006                  [Page 5]

Internet-Draft                    BFCP                     November 2005


   floor control server using BFCP.

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

   Floor Chair: A logical entity that manages one floor (grants, denies,
   or revokes a floor).  An entity that assumes the logical role of a
   floor chair for a given transaction may assume a different role
   (e.g., floor participant) for a different transaction.  The roles of
   floor chair and floor participant are defined on a transaction-by-
   transaction basis.  BFCP transactions are defined in Section 8.

   Floor Control: A mechanism that enables applications or users to gain
   safe and mutually exclusive or non-exclusive input access to the
   shared object or resource.

   Floor Control Server: A logical entity that maintains the state of
   the floor(s) including which floors exists, who the floor chairs are,
   who holds a floor, etc.  Requests to manipulate a floor are directed
   at the floor control server.  The floor control server of a
   conference may perform other logical roles (e.g., floor participant)
   in another conference.

   Floor Participant: A logical entity that requests floors, and
   possibly information about them, from a floor control server.  An
   entity that assumes the logical role of a floor participant for a
   given transaction may assume a different role (e.g., a floor chair)
   for a different transaction.  The roles of floor participant and
   floor chair are defined on a transaction-by-transaction basis.  BFCP
   transactions are defined in Section 8.  In floor-controlled
   conferences, a given floor participant is typically co-located with a
   media participant, but does not need to.  Third-party floor requests
   consist of having a floor participant request a floor for a media
   participant when they are not co-located.

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


3.  Scope

   As stated earlier, BFCP is a protocol to coordinate access to shared
   resources in a conference following the requirements defined in [10].
   Floor control complements other functions defined in the XCON
   conferencing framework [12] and is compatible with the SIPPING
   conferencing framework [11].  The floor control protocol BFCP defined
   in this document only specifies a means to arbitrate access to
   floors.  The rules and constraints for floor arbitration and the



Camarillo, et al.         Expires June 2, 2006                  [Page 6]

Internet-Draft                    BFCP                     November 2005


   results of floor assignments are outside the scope of this document
   and defined by other protocols [12].

   Figure 1 shows the tasks that BFCP can perform.


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

   Figure 1: Functionality provided by BFCP

   BFCP provides a means:

   o  for floor participants to send floor requests to floor control
      servers.
   o  for floor control servers to grant or deny requests to access a
      given resource from floor participants.
   o  for floor chairs to send floor control servers decisions regarding
      floor requests.
   o  for floor control servers to keep floor participants and floor
      chairs informed about the status of a given floor or a given floor
      request.

   Even though tasks that do not belong to the previous list are outside
   the scope of BFCP, some of these out-of-scope tasks relate to floor
   control and are essential to create floors and to establish BFCP
   connections between different entities.  In the following
   subsections, we discuss some of these tasks and mechanisms to perform
   them.

3.1.  Floor Creation

   The association of a given floor with a resource or a set of



Camarillo, et al.         Expires June 2, 2006                  [Page 7]

Internet-Draft                    BFCP                     November 2005


   resources (e.g., media streams) is out of the scope of BFCP as
   described in [12].  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 offer/answer [9] exchange, which is described in [7].  Other
   mechanisms are also described in the XCON framework (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 stream 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 using
   different mechanisms, such as an offer/answer [9] exchange.  How to
   use an offer/answer exchange to obtain these associations is
   described in [7].

      Note that floor participants perform offer/answer exchanges with
      the SIP [8] Focus of the conference.  So, the SIP Focus needs to
      obtain information about associations between floors and resources
      in order to be able to provide this information to a floor
      participant in an offer/answer exchange.

   Other mechanisms for obtaining this information, including discussion
   of how the information is made available to a (SIP) Focus, are
   described in the XCON framework (and other related documents).

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




Camarillo, et al.         Expires June 2, 2006                  [Page 8]

Internet-Draft                    BFCP                     November 2005


   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.


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 co-located with the media participant that will get the
   floor once the floor request is granted.  FloorRequest messages carry
   the identity of the requester in 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.

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




Camarillo, et al.         Expires June 2, 2006                  [Page 9]

Internet-Draft                    BFCP                     November 2005


   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.



     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                    |
             |      FLOOR-ID: 543                            |
             |      REQUEST-STATUS: Pending                  |
             |<----------------------------------------------|
             |                                               |
             |(3) FloorRequestStatus                         |



Camarillo, et al.         Expires June 2, 2006                 [Page 10]

Internet-Draft                    BFCP                     November 2005


             |Transaction ID: 0                              |
             |User ID: 234                                   |
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 789                    |
             |      FLOOR-ID: 543                            |
             |      REQUEST-STATUS: Accepted (1st in Queue)  |
             |<----------------------------------------------|
             |                                               |
             |(4) FloorRequestStatus                         |
             |Transaction ID: 0                              |
             |User ID: 234                                   |
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 789                    |
             |      FLOOR-ID: 543                            |
             |      REQUEST-STATUS: Granted                  |
             |<----------------------------------------------|
             |                                               |
             |(5) FloorRelease                               |
             |Transaction ID: 154                            |
             |User ID: 234                                   |
             |FLOOR-REQUEST-ID: 789                          |
             |---------------------------------------------->|
             |                                               |
             |(6) FloorRequestStatus                         |
             |Transaction ID: 154                            |
             |User ID: 234                                   |
             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 789                    |
             |      FLOOR-ID: 543                            |
             |      REQUEST-STATUS: Released                 |
             |<----------------------------------------------|


   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,
   while 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.



Camarillo, et al.         Expires June 2, 2006                 [Page 11]

Internet-Draft                    BFCP                     November 2005


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



Camarillo, et al.         Expires June 2, 2006                 [Page 12]

Internet-Draft                    BFCP                     November 2005


             |FLOOR-REQUEST-INFORMATION                      |
             |      Floor Request ID: 635                    |
             |      FLOOR-ID: 543                            |
             |      BENEFICIARY-INFORMATION                  |
             |                  Beneficiary ID: 154          |
             |      REQUEST-STATUS: Granted                  |
             |<----------------------------------------------|


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

4.2.  Floor Chair to Floor Control Server Interface

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

   For example, a floor chair may send a ChairAction message granting a
   floor which was requested as part of an atomic floor request
   operation that involved several floors.  Even if the chair
   responsible for one of the floors instructs the floor control server
   to grant the floor, the floor control server will not grant it until
   the chairs responsible for the other floors agree to grant them as
   well.  In another example, a floor chair may instruct the floor
   control server to grant a floor to a participant.  The floor control
   server needs to revoke the floor from its current holder before
   granting it to the new participant.




Camarillo, et al.         Expires June 2, 2006                 [Page 13]

Internet-Draft                    BFCP                     November 2005


   So, the floor control server is ultimately responsible to keep a
   coherent floor state using instructions from floor chairs as input to
   this state.



        Floor Chair                                    Floor Control
                                                          Server
             |(1) ChairAction                                |
             |Transaction ID: 769                            |
             |User ID: 357                                   |
             |FLOOR-ID: 543                                  |
             |FLOOR-REQUEST-ID: 635                          |
             |REQUEST-STATUS: Granted                        |
             |---------------------------------------------->|
             |                                               |
             |(2) ChairActionAck                             |
             |Transaction ID: 769                            |
             |User ID: 357                                   |
             |<----------------------------------------------|


   Figure 4: Chair instructing the floor control server


5.  Packet Format

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

5.1.  COMMON-HEADER Format

   The following is 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




Camarillo, et al.         Expires June 2, 2006                 [Page 14]

Internet-Draft                    BFCP                     November 2005


   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

   Payload Length: this 16-bit field contains 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.




Camarillo, et al.         Expires June 2, 2006                 [Page 15]

Internet-Draft                    BFCP                     November 2005


      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.

      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:






Camarillo, et al.         Expires June 2, 2006                 [Page 16]

Internet-Draft                    BFCP                     November 2005


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

                         Table 2: BFCP attributes

   M: the 'M' bit, known as the Mandatory bit, indicates whether support
   of the attribute is required.  If an unrecognized attribute with the
   'M' bit set is received, the message is rejected.

   Length: this 8-bit field contains the length of the attribute in
   octets, excluding any padding defined for specific attributes.  The
   Type, 'M' bit, and Length fields are included.  The Length in grouped
   attributes is the length of the grouped attribute itself (including
   Type, 'M' bit, and Length fields) plus the total length (including
   padding) of all the included attributes.

   Attribute Contents: the contents of the different 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         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Camarillo, et al.         Expires June 2, 2006                 [Page 17]

Internet-Draft                    BFCP                     November 2005


   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.

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.






Camarillo, et al.         Expires June 2, 2006                 [Page 18]

Internet-Draft                    BFCP                     November 2005


      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 had been 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.

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.






Camarillo, et al.         Expires June 2, 2006                 [Page 19]

Internet-Draft                    BFCP                     November 2005


                           +-------+-----------+
                           | 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, the
   floor control server does not implement a floor request queue, or the
   floor control server does not want to provide the client with this
   information, all the bits of this field SHOULD be set to zero.

   A floor request is in Pending state if the floor control server needs
   to contact a floor chair in order to accept the floor request, but
   has not done it yet.  Once the floor control chair accepts the floor
   request, the floor request is moved to the Accepted state.

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




Camarillo, et al.         Expires June 2, 2006                 [Page 20]

Internet-Draft                    BFCP                     November 2005


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

   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




Camarillo, et al.         Expires June 2, 2006                 [Page 21]

Internet-Draft                    BFCP                     November 2005


   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.

   In some situations, the contents of the Text field may be generated
   by an automaton.  If such automaton has information about the
   preferred language of the receiver of a particular 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.









Camarillo, et al.         Expires June 2, 2006                 [Page 22]

Internet-Draft                    BFCP                     November 2005


      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.

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



Camarillo, et al.         Expires June 2, 2006                 [Page 23]

Internet-Draft                    BFCP                     November 2005


   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     |      Supported Attribute      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Supported Attribute      |      Supported Attribute      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 17: SUPPORTED-ATTRIBUTES format

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

   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.














Camarillo, et al.         Expires June 2, 2006                 [Page 24]

Internet-Draft                    BFCP                     November 2005


      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.

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



Camarillo, et al.         Expires June 2, 2006                 [Page 25]

Internet-Draft                    BFCP                     November 2005


   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.

      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:






Camarillo, et al.         Expires June 2, 2006                 [Page 26]

Internet-Draft                    BFCP                     November 2005


      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:


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






Camarillo, et al.         Expires June 2, 2006                 [Page 27]

Internet-Draft                    BFCP                     November 2005


   FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
                                 (REQUEST-STATUS)
                               1*(FLOOR-ID)
                                 [BENEFICIARY-INFORMATION]
                                 [REQUESTED-BY-INFORMATION]
                                 [PRIORITY]
                                 [PARTICIPANT-PROVIDED-INFO]
                                 [STATUS-INFO]
                                *[EXTENSION-ATTRIBUTE]

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


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

   Figure 26: REQUESTED-BY-INFORMATION 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.         Expires June 2, 2006                 [Page 28]

Internet-Draft                    BFCP                     November 2005


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)
                   *(FLOOR-ID)
                    [BENEFICIARY-ID]
                    [PARTICIPANT-PROVIDED-INFO]
                    [PRIORITY]
                   *[EXTENSION-ATTRIBUTE]

   Figure 27: 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 28: 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 29: 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



Camarillo, et al.         Expires June 2, 2006                 [Page 29]

Internet-Draft                    BFCP                     November 2005


   FloorRequestStatus messages.  The following is the format of the
   FloorRequestStatus message:


   FloorRequestStatus =   (COMMON-HEADER)
                          (FLOOR-REQUEST-INFORMATION)
                         *[EXTENSION-ATTRIBUTE]

   Figure 30: 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 31: UserQuery format

5.3.6.  UserStatus

   The floor control server provide 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]
                1*(FLOOR-REQUEST-INFORMATION)
                 *[EXTENSION-ATTRIBUTE]

   Figure 32: 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:







Camarillo, et al.         Expires June 2, 2006                 [Page 30]

Internet-Draft                    BFCP                     November 2005


   FloorQuery =   (COMMON-HEADER)
                 *(FLOOR-ID)
                 *[EXTENSION-ATTRIBUTE]

   Figure 33: FloorQuery format

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)
                            (FLOOR-ID)
                           *[FLOOR-REQUEST-INFORMATION]
                           *[EXTENSION-ATTRIBUTE]

   Figure 34: 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)
                  1*(FLOOR-ID)
                    (FLOOR-REQUEST-ID)
                    (REQUEST-STATUS)
                    [STATUS-INFO]
                   *[EXTENSION-ATTRIBUTE]

   Figure 35: 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 36: ChairActionAck format



Camarillo, et al.         Expires June 2, 2006                 [Page 31]

Internet-Draft                    BFCP                     November 2005


5.3.11.  Hello

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


   Hello         =  (COMMON-HEADER)
                   *[EXTENSION-ATTRIBUTE]

   Figure 37: Hello format

5.3.12.  HelloAck

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


   HelloAck      =  (COMMON-HEADER)
                    (SUPPORTED-PRIMITIVES)
                    (SUPPORTED-ATTRIBUTES)
                   *[EXTENSION-ATTRIBUTE]

   Figure 38: 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 39: 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



Camarillo, et al.         Expires June 2, 2006                 [Page 32]

Internet-Draft                    BFCP                     November 2005


   attributes.

   A client MUST NOT use more than one TCP connection to communicate
   with a given floor control server within a conference.  Nevertheless,
   if the same physical box handles different clients (e.g., a floor
   chair and a floor participant), which are identified by different
   User IDs, a separate connection per client is allowed.

   If a BFCP entity (a client or a floor control server) receives data
   from TCP that cannot be parsed the entity MUST close the TCP
   connection using a RESET call (send a TCP RST bit) and the connection
   SHOULD be reestablished.  Similarly, if a TCP connection cannot
   deliver a BFCP message and times out, the TCP connection SHOULD be
   reestablished.

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

   If a floor control server detects that the TCP connection towards one
   of the floor participants is lost, it is up to the local policy of
   the floor control server what to do with the pending floor requests
   of the floor participant.  In any case, it is RECOMMENDED that the
   floor control server keeps the floor requests (i.e., does not cancel
   them) while the TCP connection is reestablished.

   If a client wishes to end its BFCP connection with a floor control
   server, the client closes (i.e., a graceful close) the TCP connection
   towards the floor control server.  If a floor control server wishes
   to end its BFCP connection with a client (e.g., the Focus of the
   conference informs the floor control server that the client has been
   kicked out from the conference), the floor control server closes
   (i.e., a graceful close) the TCP connection towards the client.


7.  Lower-Layer Security

   BFCP relies on lower-layer security mechanisms to provide replay and
   integrity protection, and confidentiality.  BFCP floor control
   servers 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].




Camarillo, et al.         Expires June 2, 2006                 [Page 33]

Internet-Draft                    BFCP                     November 2005


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

   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 which is different to 0 and which MUST NOT be reused in
   another message from the client until a response from the server is
   received for the transaction.  The client uses the Transaction ID
   value to match this message with the response from the floor control
   server.

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.



Camarillo, et al.         Expires June 2, 2006                 [Page 34]

Internet-Draft                    BFCP                     November 2005


   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.

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



Camarillo, et al.         Expires June 2, 2006                 [Page 35]

Internet-Draft                    BFCP                     November 2005


   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.

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 attributes, 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.



Camarillo, et al.         Expires June 2, 2006                 [Page 36]

Internet-Draft                    BFCP                     November 2005


   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 the server to 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 to be 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 which relate to floor control server authentication.

   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 REQUEST-STATUS attribute.  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.

   The STATUS-INFO attribute, if present, provides extra information
   which 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-



Camarillo, et al.         Expires June 2, 2006                 [Page 37]

Internet-Draft                    BFCP                     November 2005


   INFORMATION attribute may be not be present in FloorRequestStatus
   messages received by the floor participant that requested the floor
   because 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.

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




Camarillo, et al.         Expires June 2, 2006                 [Page 38]

Internet-Draft                    BFCP                     November 2005


10.2.2.  Receiving a Response

   A message from the floor control server is considered to be 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 which relate to floor control server authentication.

   If the response is a FloorRequestStatus message, the Request Status
   value in the 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, because its Transaction ID will not match that of the
   FloorRelease.


11.  Chair Operations

   This section specifies how floor chairs can instruct the floor
   control server 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
   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.

   The ChairAction message contains instructions that apply to one or
   more floors within a particular floor request.  The floor or floors



Camarillo, et al.         Expires June 2, 2006                 [Page 39]

Internet-Draft                    BFCP                     November 2005


   are identified by FLOOR-ID attributes and the floor request is
   identified by a FLOOR-REQUEST-ID attribute, 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 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 for one or more floors within
   the floor request using a 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 the Status Denied
   to reject floor requests in any other status (e.g., Pending and
   Accepted).

      Note that a floor request may involve several floors and that a
      ChairAction message may only deal with a subset of these floors
      (e.g., if a single floor chair is not authorized to manage all the
      floors).  In this case, the REQUEST-STATUS that the floor chair
      provides in the ChairAction message might not be the actual status
      that the floor request gets at the server.  The floor control
      server will combine the instructions received from the different
      floor chairs to come up with the actual status of the floor
      request.

   The floor chair may use a STATUS-INFO attribute to state the reason
   why the floor or floors are 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 to be 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 which
   relate to floor control server authentication.

   A ChairActionAck message from the floor control server confirms that
   the floor control server has accepted the ChairAction message.  An



Camarillo, et al.         Expires June 2, 2006                 [Page 40]

Internet-Draft                    BFCP                     November 2005


   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 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 to be a
   response to the FloorQuery message if the message from the floor
   control server has the same Conference ID, Transaction ID, and User
   ID as the FloorRequest message, as described in Section 8.1.  On
   receiving such a response, the client follows the rules in Section 9



Camarillo, et al.         Expires June 2, 2006                 [Page 41]

Internet-Draft                    BFCP                     November 2005


   which 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 which 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 request that relate to that floor.  The information about each
   particular floor request is encoded in a FLOOR-REQUEST-INFORMATION
   attribute.  This grouped attribute carries a Floor Request ID that
   identifies the 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
   requests 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.

12.2.1.  Sending a FloorRequestQuery Message

   The ABNF in Section 5.3.3 describes the attributes that a



Camarillo, et al.         Expires June 2, 2006                 [Page 42]

Internet-Draft                    BFCP                     November 2005


   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 to be 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 which 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
   floor participant, after experiencing connectivity problems (e.g.,
   its TCP connection with the floor control server was down for a while



Camarillo, et al.         Expires June 2, 2006                 [Page 43]

Internet-Draft                    BFCP                     November 2005


   and eventually was re-established), may need to request information
   about all the still existing floor requests associated to itself.

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 to be 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
   which 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.

12.4.1.  Sending a Hello Message

   The ABNF in Section 5.3.11 describes the attributes that a Hello



Camarillo, et al.         Expires June 2, 2006                 [Page 44]

Internet-Draft                    BFCP                     November 2005


   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 which relate to
   floor control server authentication.

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

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


13.  Floor Control Server Operations

   This section specifies how floor control servers can perform
   different operations, such as granting a floor, using the protocol
   elements described in earlier sections.

   On reception of a message from a client, the floor control server
   MUST check whether or not the value of the Conference ID matched an
   existing conference.  If it does not, the floor control server SHOULD
   send an Error message, as described in Section 13.8, with Error code
   1 (Conference does not Exist).

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

   On reception of a message from a client, the floor control server
   MUST check whether or not it understands all the mandatory ( 'M' bit
   set) 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



Camarillo, et al.         Expires June 2, 2006                 [Page 45]

Internet-Draft                    BFCP                     November 2005


   (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 which relate to client authentication
   and authorization.  If while processing the FloorRequest message, the
   floor control server encounters an error, it SHOULD generate an Error
   response following the procedures described in Section 13.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 REQUEST-STATUS
   attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of
   the first FloorRequestStatus message it generates.

      The policy a floor control server follows to grant or deny floors
      is outside the scope of this document.  A given floor control
      server may perform these decisions automatically while another may
      contact a human acting as a chair everytime a decision needs to be
      made.

   The floor control server MUST copy the Conference ID, the Transaction
   ID, and the User ID from the FloorRequest into the
   FloorRequestStatus, as described in Section 8.2.  Additionally, the
   floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
   attribute to the FloorRequestStatus.  The attributes contained in
   this grouped attribute carry information about the floor request.

   The floor control server MUST assign an identitifier 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



Camarillo, et al.         Expires June 2, 2006                 [Page 46]

Internet-Draft                    BFCP                     November 2005


   by a chair or chairs) to refer to this specific floor request in the
   future.

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

   The floor control server SHOULD copy (if present) the contents of the
   BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-
   INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped
   attribute.  Additionally, the floor control server MAY provide the
   display name and the URI of the beneficiary in this BENEFICIARY-
   INFORMATION attribute.

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

   The floor control server MAY copy (if present) the PRIORITY attribute
   from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped
   attribute.  Note that this attribute carries the priority requested
   by the participant.  The priority the floor control server assigns to
   the floor request depends on the priority requested by the
   participant and the rights the participant has according to the
   policy of the conference.  For example, a participant that is only
   allowed to use the Normal priority may request Highest priority for a
   floor request.  In that case, the floor control server 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-
   INFO grouped attribute.

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



Camarillo, et al.         Expires June 2, 2006                 [Page 47]

Internet-Draft                    BFCP                     November 2005


   FloorRequestStatus related to the same floor request.  (The Floor
   Request ID identifies the floor request the FloorRequestStatus
   applies to.)

   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 to only 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.

13.2.  Reception of a FloorRequestQuery Message

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



Camarillo, et al.         Expires June 2, 2006                 [Page 48]

Internet-Draft                    BFCP                     November 2005


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

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

13.3.  Reception of a UserQuery Message

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



Camarillo, et al.         Expires June 2, 2006                 [Page 49]

Internet-Draft                    BFCP                     November 2005


   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 to a given participant (i.e., the
   floor requests where the participant is either the beneficiary or the
   requester).  This participant is identified by a BENEFICIARY-ID
   attribute or, in the absence of a BENEFICIARY-ID attribute, by a 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 the UserStatus message provides
   information on 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 the message provides information on (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 identity 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-ID 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



Camarillo, et al.         Expires June 2, 2006                 [Page 50]

Internet-Draft                    BFCP                     November 2005


   participant requested the floor in a PARTICIPANT-PROVIDED-INFO.

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

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

13.4.  Reception of a FloorRelease Message

   On reception of a FloorRelease message, the floor control server
   follows the rules in Section 9 which relate to client authentication
   and authorization.  If while processing the FloorRelease message, the
   floor control server encounters an error, it SHOULD generate an Error
   response following the procedures described in Section 13.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.

   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 add FLOOR-ID attributes to the FLOOR-
   REQUEST-INFORMATION grouped attribute identifying the floors being
   requested (i.e., the floors associated with the floor request
   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.




Camarillo, et al.         Expires June 2, 2006                 [Page 51]

Internet-Draft                    BFCP                     November 2005


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

   The floor control server MAY provide the reason why the floor
   participant requested the floor in a PARTICIPANT-PROVIDED-INFO.

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

   The floor control server MUST add a 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.

13.5.  Reception of a FloorQuery Message

   On reception of a FloorQuery message, the floor control server
   follows the rules in Section 9 which relate to client authentication.
   If while processing the FloorRelease message, the floor control
   server encounters an error, it SHOULD generate an Error response
   following the procedures described in Section 13.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.

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



Camarillo, et al.         Expires June 2, 2006                 [Page 52]

Internet-Draft                    BFCP                     November 2005


   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 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 which
   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 identity 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-ID 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.

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



Camarillo, et al.         Expires June 2, 2006                 [Page 53]

Internet-Draft                    BFCP                     November 2005


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 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 the client requested information about.  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 which relate to client authentication
   and authorization.  If while processing the ChairAction message, the
   floor control server encounters an error, it SHOULD generate an Error
   response following the procedures described in Section 13.8

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

   The floor control server MUST copy the Conference ID, the Transaction
   ID, and the User ID from the ChairAction message into the
   ChairActionAck message, as described in Section 8.2.

   The floor control server needs to take into consideration the
   operation requested in the ChairAction message (e.g., granting a
   floor), but does not necessarily need to perform it as requested by
   the floor chair.  The operation that the floor control server
   performs depends on the ChairAction message and on the internal state
   of the floor control server.

   For example, a floor chair may send a ChairAction message granting a
   floor which was requested as part of an atomic floor request
   operation that involved several floors.  Even if the chair
   responsible for one of the floors instructs the floor control server
   to grant the floor, the floor control server will not grant it until



Camarillo, et al.         Expires June 2, 2006                 [Page 54]

Internet-Draft                    BFCP                     November 2005


   the chairs responsible for the other floors agree to grant them as
   well.

   So, the floor control server is ultimately responsible to keep a
   coherent floor state using instructions from floor chairs as input to
   this state.

   If the new Status in the ChairAction message is Accepted and all the
   bits of the Queue Position field are zero, the floor chair is
   requesting the floor control server to assign a queue position (e.g.,
   the last in the queue) to the floor request based on the local policy
   of the floor control server.  (Of course, such a request only applies
   in case the floor control server implements a queue.)

13.7.  Reception of a Hello Message

   On reception of a Hello message, the floor control server follows the
   rules in Section 9 which relate to client authentication.  If while
   processing the Hello message, the floor control server encounters an
   error, it SHOULD generate an Error response following the procedures
   described in Section 13.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.

   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.




Camarillo, et al.         Expires June 2, 2006                 [Page 55]

Internet-Draft                    BFCP                     November 2005


   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 a 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
   is always 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 hickjack 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.

   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



Camarillo, et al.         Expires June 2, 2006                 [Page 56]

Internet-Draft                    BFCP                     November 2005


   prevents this attack.  Therefore, it is RECOMMENDED that TLS is used
   with a non-null encryption algorithm.


15.  IANA Considerations

   This document instructs the IANA to create a new registry for BFCP
   parameters called "Binary Floor Control Protocol (BFCP) Parameters".
   This new registry has a number of subregistries, which are described
   in the following Sections

15.1.  Attribute Subregistry

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

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

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

         Table 6: Initial values of the BFCP Attribute subregistry




Camarillo, et al.         Expires June 2, 2006                 [Page 57]

Internet-Draft                    BFCP                     November 2005


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 RFC MUST specify the primitive's value,
   name, format, and semantics.

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

                +-------+--------------------+------------+
                | Value | Primitive          | Reference  |
                +-------+--------------------+------------+
                |   1   | FloorRequest       | [RFC XXXX] |
                |   2   | FloorRelease       | [RFC XXXX] |
                |   3   | FloorRequestQuery  | [RFC XXXX] |
                |   4   | FloorRequestStatus | [RFC XXXX] |
                |   5   | UserQuery          | [RFC XXXX] |
                |   6   | UserStatus         | [RFC XXXX] |
                |   7   | FloorQuery         | [RFC XXXX] |
                |   8   | FloorStatus        | [RFC XXXX] |
                |   9   | ChairAction        | [RFC XXXX] |
                |   10  | ChairActionAck     | [RFC XXXX] |
                |   11  | Hello              | [RFC XXXX] |
                |   12  | HelloAck           | [RFC XXXX] |
                |   13  | Error              | [RFC XXXX] |
                +-------+--------------------+------------+

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



Camarillo, et al.         Expires June 2, 2006                 [Page 58]

Internet-Draft                    BFCP                     November 2005


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

         Table 8: Initial values of the Request Status subregistry

15.4.  Error Code Subregistry

   This Section establishes the Error Code subregistry under the BFCP
   Parameters registry.  As per the terminology in RFC 2434 [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 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      |
|       |                                                  | XXXX]     |
|   2   | User does not Exist                              | [RFC      |
|       |                                                  | XXXX]     |
|   3   | Unknown Primitive                                | [RFC      |
|       |                                                  | XXXX]     |
|   4   | Unknown Mandatory Attribute                      | [RFC      |
|       |                                                  | XXXX]     |
|   5   | Unauthorized Operation                           | [RFC      |
|       |                                                  | XXXX]     |
|   6   | Invalid Floor ID                                 | [RFC      |
|       |                                                  | XXXX]     |
|   7   | Floor Request ID Does Not Exist                  | [RFC      |
|       |                                                  | XXXX]     |
|   8   | You have Already Reached the Maximum Number of   | [RFC      |
|       | Ongoing Floor Requests for this Floor            | XXXX]     |



Camarillo, et al.         Expires June 2, 2006                 [Page 59]

Internet-Draft                    BFCP                     November 2005


|   9   | Use TLS                                          | [RFC      |
|       |                                                  | XXXX]     |
+-------+--------------------------------------------------+-----------+

           Table 9: Initial Values of the Error Code subregistry


16.  Acknowledgments

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


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 2234, November 1997.

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

   [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",
        draft-ietf-mmusic-sdp-bfcp-02 (work in progress), July 2005.

17.2.  Informational References

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

   [9]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with



Camarillo, et al.         Expires June 2, 2006                 [Page 60]

Internet-Draft                    BFCP                     November 2005


         Session Description Protocol (SDP)", RFC 3264, June 2002.

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

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

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





































Camarillo, et al.         Expires June 2, 2006                 [Page 61]

Internet-Draft                    BFCP                     November 2005


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
   Helsinki
   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.         Expires June 2, 2006                 [Page 62]

Internet-Draft                    BFCP                     November 2005


Intellectual Property Statement

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

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Camarillo, et al.         Expires June 2, 2006                 [Page 63]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/