[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: February 17, 2005                                        J. Ott
                                                     Universitaet Bremen
                                                                K. Drage
                                                     Lucent Technologies
                                                         August 19, 2004


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

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

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

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

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

   This Internet-Draft will expire on February 17, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

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



Camarillo, et al.      Expires February 17, 2005                [Page 1]

Internet-Draft                    BFCP                       August 2004


   control -- that are realized by other protocols.

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

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1  Floor Creation . . . . . . . . . . . . . . . . . . . . . .   6
     3.2  Obtaining Information to Contact a BFCP Floor Server . . .   7
     3.3  Generating a Shared Secret . . . . . . . . . . . . . . . .   7
     3.4  Obtaining Floor-Resource Associations  . . . . . . . . . .   7
     3.5  Policy Enforcement . . . . . . . . . . . . . . . . . . . .   8
   4.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   8
     4.1  User - Floor Control Server Interface  . . . . . . . . . .   9
     4.2  Floor Chair - Floor Control Server Interface . . . . . . .  11
   5.   Packet Format  . . . . . . . . . . . . . . . . . . . . . . .  12
     5.1  FIXED-HEADER Format  . . . . . . . . . . . . . . . . . . .  12
     5.2  Attribute Format . . . . . . . . . . . . . . . . . . . . .  13
       5.2.1  FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . .  14
       5.2.2  USER-ID  . . . . . . . . . . . . . . . . . . . . . . .  14
       5.2.3  BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . .  14
       5.2.4  TRANSACTION-ID . . . . . . . . . . . . . . . . . . . .  15
       5.2.5  FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . .  15
       5.2.6  HUMAN-READABLE-INFO  . . . . . . . . . . . . . . . . .  15
       5.2.7  INTEGRITY  . . . . . . . . . . . . . . . . . . . . . .  16
       5.2.8  REQUEST-STATUS . . . . . . . . . . . . . . . . . . . .  16
       5.2.9  ERROR-CODE . . . . . . . . . . . . . . . . . . . . . .  17
       5.2.10   USER-DISPLAY-NAME  . . . . . . . . . . . . . . . . .  19
       5.2.11   USER-URI . . . . . . . . . . . . . . . . . . . . . .  19
       5.2.12   PRIORITY . . . . . . . . . . . . . . . . . . . . . .  19
   6.   Message Format . . . . . . . . . . . . . . . . . . . . . . .  19
     6.1  FloorRequest . . . . . . . . . . . . . . . . . . . . . . .  19
     6.2  FloorRelease . . . . . . . . . . . . . . . . . . . . . . .  20
     6.3  FloorRequestInfo . . . . . . . . . . . . . . . . . . . . .  20
     6.4  FloorRequestStatus . . . . . . . . . . . . . . . . . . . .  20
     6.5  FloorInfo  . . . . . . . . . . . . . . . . . . . . . . . .  21
     6.6  FloorStatus  . . . . . . . . . . . . . . . . . . . . . . .  21
     6.7  ChairAction  . . . . . . . . . . . . . . . . . . . . . . .  22
     6.8  ChairActionAck . . . . . . . . . . . . . . . . . . . . . .  22
     6.9  Ping . . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     6.10   PingAck  . . . . . . . . . . . . . . . . . . . . . . . .  22
     6.11   Error  . . . . . . . . . . . . . . . . . . . . . . . . .  23
   7.   Transport  . . . . . . . . . . . . . . . . . . . . . . . . .  23



Camarillo, et al.      Expires February 17, 2005                [Page 2]

Internet-Draft                    BFCP                       August 2004


   8.   Lower-Layer Security . . . . . . . . . . . . . . . . . . . .  23
   9.   Protocol Transactions  . . . . . . . . . . . . . . . . . . .  23
     9.1  Client Behavior  . . . . . . . . . . . . . . . . . . . . .  24
     9.2  Server Behavior  . . . . . . . . . . . . . . . . . . . . .  24
   10.  Authentication . . . . . . . . . . . . . . . . . . . . . . .  24
     10.1   Client Behavior  . . . . . . . . . . . . . . . . . . . .  24
     10.2   Server Behavior  . . . . . . . . . . . . . . . . . . . .  25
   11.  Client Operations  . . . . . . . . . . . . . . . . . . . . .  25
     11.1   Requesting a Floor . . . . . . . . . . . . . . . . . . .  25
       11.1.1   Receiving a Response . . . . . . . . . . . . . . . .  26
   12.  Requesting Information about Floor Requests  . . . . . . . .  27
     12.1   Receiving a Response . . . . . . . . . . . . . . . . . .  27
   13.  Cancelling a Floor Request and Releasing a Floor . . . . . .  28
     13.1   Receiving a Response . . . . . . . . . . . . . . . . . .  28
   14.  Requesting Information about Floors  . . . . . . . . . . . .  28
     14.1   Receiving a Response . . . . . . . . . . . . . . . . . .  29
   15.  Checking the Liveness of a Server  . . . . . . . . . . . . .  29
     15.1   Receiving Responses  . . . . . . . . . . . . . . . . . .  30
   16.  Chair Operations . . . . . . . . . . . . . . . . . . . . . .  30
     16.1   Obtaining Information about Floor Requests . . . . . . .  30
     16.2   Instructing the Floor Control Server . . . . . . . . . .  30
       16.2.1   Receiving a Response . . . . . . . . . . . . . . . .  31
   17.  Server Operations  . . . . . . . . . . . . . . . . . . . . .  32
     17.1   Reception of a FloorRequest Message  . . . . . . . . . .  32
     17.2   Reception of a FloorRequestInfo Message  . . . . . . . .  33
     17.3   Reception of a FloorRelease Message  . . . . . . . . . .  33
     17.4   Reception of a FloorInfo Message . . . . . . . . . . . .  34
     17.5   Reception of a ChairAction Message . . . . . . . . . . .  35
     17.6   Reception of a Ping Message  . . . . . . . . . . . . . .  35
     17.7   Error Message Generation . . . . . . . . . . . . . . . .  36
   18.  BFCP and the Offer/Answer Model  . . . . . . . . . . . . . .  36
     18.1   Fields in the m Line . . . . . . . . . . . . . . . . . .  36
     18.2   The confid and userid SDP Parameters . . . . . . . . . .  37
     18.3   The k line . . . . . . . . . . . . . . . . . . . . . . .  37
     18.4   TCP Connection Management  . . . . . . . . . . . . . . .  37
     18.5   Association between Streams and Floors . . . . . . . . .  38
     18.6   Example  . . . . . . . . . . . . . . . . . . . . . . . .  38
   19.  Security Considerations  . . . . . . . . . . . . . . . . . .  39
   20.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  39
     20.1   SDP Attributes Registration  . . . . . . . . . . . . . .  39
   21.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  39
   22.  References . . . . . . . . . . . . . . . . . . . . . . . . .  39
   22.1   Normative References . . . . . . . . . . . . . . . . . . .  39
   22.2   Informational References . . . . . . . . . . . . . . . . .  40
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  41
        Intellectual Property and Copyright Statements . . . . . . .  42





Camarillo, et al.      Expires February 17, 2005                [Page 3]

Internet-Draft                    BFCP                       August 2004


1.  Introduction

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

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

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

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [2] and indicate requirement levels for
   compliant implementations.

   Conference Policy: The complete set of rules for a particular
   conference manipulated by the conference policy server.  It includes
   the membership policy and the media policy.  There is an instance of
   conference policy for each conference.

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

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

   Floor chair: A user (or an entity) who manages one floor (grants,
   denies, or revokes a floor).  The floor chair does not have to be a
   member in a conference.

   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



Camarillo, et al.      Expires February 17, 2005                [Page 4]

Internet-Draft                    BFCP                       August 2004


   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.

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

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

3.  Scope

   As stated above, the BFCP is a protocol to coordinate access to
   shared resources in a conference setting following the requirements
   defined in [15].  Floor control complements other functions defined
   in the conference framework, such as conference policy and media
   policy.  In particular, it is the conference policy that defines
   which media streams and applications are floor-controlled, who is/are
   the respective floor chair(s), and how access to the floor is
   managed.  Furthermore, it is up to the media policy to define which
   (if any) impact on media stream handling (e.g.  switching or mixing)
   assignment of a floor to a participant has.

   The floor control protocol BFCP defined in this document only
   specifies a means to arbitrate access to floors.  The rules and
   constraints for floor arbitration and the results of floor
   assignments are outside the scope of this document and defined by the
   conference and media policy, respectively.

   Figure 1 shows the tasks that BFCP can perform.












Camarillo, et al.      Expires February 17, 2005                [Page 5]

Internet-Draft                    BFCP                       August 2004


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

                Figure 1: Functionality provided by BFCP

   BFCP provides a means:

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

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

3.1  Floor Creation

   The conference policy for a particular conference contains the floors
   of the conference and the resource or resources associated with each
   floor.  For example, a conference may have two floors: one
   controlling who can talk at a particular time and another controlling
   who can write on a shared whiteboard.

   According to the definitions in Section 2, the conference policy is
   manipulated using a Conference Policy Control Protocol (CPCP), such
   as [16].  Consequently, floor creation and termination is handled by



Camarillo, et al.      Expires February 17, 2005                [Page 6]

Internet-Draft                    BFCP                       August 2004


   CPCP.  In addition, CPCP also handles the association of a given
   floor with a resource or a set of resources (e.g., media streams).

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

3.2  Obtaining Information to Contact a BFCP Floor Server

   A user or a floor chair needs a set of data in order to establish a
   BFCP connection to a floor control server.  These data include the
   transport address of the server, the conference identifier, and the
   user identifier.

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

3.3  Generating a Shared Secret

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

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

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

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

3.4  Obtaining Floor-Resource Associations

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

   Users and floor chairs need to know which resources are associated
   with which floors.  They can obtain this information using different



Camarillo, et al.      Expires February 17, 2005                [Page 7]

Internet-Draft                    BFCP                       August 2004


   mechanisms, such as CPCP or an offer/answer [11] exchange.  Section
   18 describes how to use an offer/answer exchange to obtain these
   associations.

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

3.5  Policy Enforcement

   A user 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 user may have the right to talk
   (i.e., send media over a particular audio stream).

   Nevertheless, holding a floor does not imply that others will not be
   able to use its associated resources at the same time, even if they
   do not have the right to do so.  According to the definition in
   Section 2, the media policy of a conference is the one that
   determines which users can actually use the resources in the
   conference.

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

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

4.  Overview of Operation

   This section provides a non-normative description of BFCP operations.
   Section 4.1 describes the interface between users and floor control
   servers and Section 4.2 describes the interface between floor chairs
   and floor control servers

   BFCP messages, which use a TLV (Type-Length-Value) binary encoding,
   consist of a common header followed by a set of TLVs.  The common
   header contains, among other information, a 32-bit conference
   identifier.  Users and floor chairs are identified by a 16-bit user
   identifier, which is carried in a TLV.



Camarillo, et al.      Expires February 17, 2005                [Page 8]

Internet-Draft                    BFCP                       August 2004


4.1  User - Floor Control Server Interface

   Users request a floor by sending a FloorRequest message to the floor
   control server.  BFCP supports third party floor requests.  That is,
   the user sending the floor request need not be the same as the user
   who will get the floor once the floor request is granted.
   FloorRequest messages carry the identity of the requester in a
   USER-ID TLV, and the identity of the beneficiary of the floor, in
   third party floor requests, in a BENEFICIARY-ID TLV.

      Third party floor requests can be sent by users that have a BFCP
      connection to the floor control server, but who are not conference
      participants (i.e., they do not handle any media).

   FloorRequest messages identify the floor or floors being requested by
   carrying their 16-bit floor identifiers in FLOOR-ID TLVs.  If a
   FloorRequest message carries more than one floor identifier, the
   floor control server treats all the floor requests as an atomic
   package.  That is, the floor control server either grants or denies
   all the floors in the FloorRequest message.

   EDITOR'S NOTE: we need to explain in this paragraph that if a user is
   anonymous, the floor control server does not disclose the identity of
   the requester of the floor to the rest of the users and floor chairs.

   Floor control servers respond to FloorRequest messages with
   FloorStatus messages.

   Editor's note: This section will be finished when we have agreed on
   what it is specified in the rest of this document.  For the time
   being, below there are two typical call flows: a client requesting a
   floor and a client requesting information about a floor.




   Client                     Floor Control
                                 Server

     |      FloorRequest            |
     |        TRANSACTION-ID: 123   |
     |----------------------------->|
     |                              |
     |   FloorRequestStatus         |
     |     TRANSACTION-ID: 123      |
     |     FLOOR-REQUEST-ID: 345    |
     |     REQUEST-STATUS: Pending  |
     |<-----------------------------|



Camarillo, et al.      Expires February 17, 2005                [Page 9]

Internet-Draft                    BFCP                       August 2004


     |                              |
     |   FloorRequestStatus         |
     |     FLOOR-REQUEST-ID: 345    |
     |     REQUEST-STATUS: Accepted |
     |<-----------------------------|
     |                              |
     |                              |
     |   FloorRequestStatus         |
     |     FLOOR-REQUEST-ID: 345    |
     |     REQUEST-STATUS: Granted  |
     |<-----------------------------|
     |                              |
     |                              |
     |   FloorRelease               |
     |     TRANSACTION-ID: 124      |
     |     FLOOR-REQUEST-ID: 345    |
     |----------------------------->|
     |                              |
     |   FloorRequestStatus         |
     |     TRANSACTION-ID: 124      |
     |     FLOOR-REQUEST-ID: 345    |
     |     REQUEST-STATUS: Released |
     |<-----------------------------|
     |                              |



               Figure 2: Requesting and releasing a floor























Camarillo, et al.      Expires February 17, 2005               [Page 10]

Internet-Draft                    BFCP                       August 2004


    Client or                    Floor Control
      Chair                         Server

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



          Figure 3: Obtaining status information about a floor


4.2  Floor Chair - Floor Control Server Interface

   TBD.  For the time being, below there is the typical call flow for
   this interface.














Camarillo, et al.      Expires February 17, 2005               [Page 11]

Internet-Draft                    BFCP                       August 2004


     Chair                      Floor Control
                                   Server

       |   ChairAction                |
       |     TRANSACTION-ID: 123      |
       |     FLOOR-ID: 15             |
       |     FLOOR-REQUEST-ID: 345    |
       |     REQUEST-STATUS: Granted  |
       |----------------------------->|
       |                              |
       |   ChairActionAck             |
       |     TRANSACTION-ID: 123      |
       |<-----------------------------|
       |                              |



     Figure 4: Chair invoking an action at the floor control server


5.  Packet Format

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

5.1  FIXED-HEADER Format

   The following is the FIXED-HEADER format.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Ver |Reserved |  Primitive    |        Payload Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Conference ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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:




Camarillo, et al.      Expires February 17, 2005               [Page 12]

Internet-Draft                    BFCP                       August 2004


     Value        Primitive             Direction
     _________________________________________________________
       0          FloorRequest          C   ->  S
       1          FloorRelease          C   ->  S
       2          FloorRequestInfo      S   ->  C ; Ch  ->  S
       3          FloorRequestStatus    S   ->  C
       4          FloorInfo             C   ->  S ; Ch  ->  S
       5          FloorStatus           S   ->  C ; S   ->  Ch
       6          ChairAction           Ch  ->  S
       7          ChairActionAck        S   ->  Ch
       8          Ping                  C   ->  S ; Ch <->  S
       9          PingAck               S   ->  C ; Ch <->  S
      10          Error                 S   ->  C ; S   ->  Ch

       S: Server  C: Client  Ch: Chair


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

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

5.2  Attribute Format

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


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

   Type: this 7-bit field contains the code for the attribute.

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

   Length: this 8-bit field contains the length of the attribute in
   bytes, excluding any padding defined for specific attributes.  The



Camarillo, et al.      Expires February 17, 2005               [Page 13]

Internet-Draft                    BFCP                       August 2004


   Type, 'M' bit, and Length fields are included.

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

5.2.1  FLOOR-ID

   The following is the format of the contents of the FLOOR-ID
   attribute, whose attribute type is 1.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 1   |M|    Length     |           Floor ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

5.2.2  USER-ID

   The following is the format of the contents of the USER-ID attribute,
   whose attribute type is 2.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 2   |M|    Length     |            User ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

5.2.3  BENEFICIARY-ID

   The following is the format of the contents of the BENEFICIARY-ID
   attribute, whose attribute type is 2.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 2   |M|    Length     |        Beneficiary ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Beneficiary ID: this field contains a 16-bit value that uniquely



Camarillo, et al.      Expires February 17, 2005               [Page 14]

Internet-Draft                    BFCP                       August 2004


   identifies a user within a conference.

5.2.4  TRANSACTION-ID

   The following is the format of the contents of the TRANSACTION-ID
   attribute, whose attribute type is 3.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 3   |M|    Length     |        Transaction ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

5.2.5  FLOOR-REQUEST-ID

   The following is the format of the contents of the FLOOR-REQUEST-ID
   attribute, whose attribute type is 4.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 3   |M|    Length     |       Floor Request ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

5.2.6  HUMAN-READABLE-INFO

   The following is the format of the contents of the
   HUMAN-READABLE-INFO attribute, whose attribute type is 5.


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



Camarillo, et al.      Expires February 17, 2005               [Page 15]

Internet-Draft                    BFCP                       August 2004


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

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

   Padding: one, two, or three bytes of padding added so that the
   contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned.  The
   Padding bits SHOULD be set to zero by the sender and MUST be ignored
   by the receiver.  If the TLV is already 32-bit aligned, no padding is
   needed.

5.2.7  INTEGRITY

   The following is the format of the contents of the INTEGRITY
   attribute, whose attribute type is 6.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 5   |M|    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                                                               |
     +                                                               +
     |                                                               |
     +                          HMAC-SHA1                            +
     |                                                               |
     +                                                               +
     |                                                               |
     +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |             Padding           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

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

5.2.8  REQUEST-STATUS

   The following is the format of the contents of the REQUEST-STATUS
   attribute, whose attribute type is 7.



Camarillo, et al.      Expires February 17, 2005               [Page 16]

Internet-Draft                    BFCP                       August 2004


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 6   |M|    Length     |        Request Status         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Queue Position         |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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


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

   Queue Position: this 16-bit field contains, when applicable, the
   position of the floor request in the floor request queue at the
   server.  If the Request Status value is different from Accepted, the
   floor control server does not implement a floor request queue, or the
   floor control server does not want to provide the client with this
   information, all the bits of this field SHOULD be set to zero.

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

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

5.2.9  ERROR-CODE

   The following is the format of the contents of the ERROR-CODE
   attribute, whose attribute type is 8.


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



Camarillo, et al.      Expires February 17, 2005               [Page 17]

Internet-Draft                    BFCP                       August 2004


     |  Type = 7   |M|    Length     |          Error Code           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                     Error Specific Details                    |
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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


     Value        Meaning
     __________________________________________________________
       0          Conference does not Exist
       1          Authentication Failed
       2          Unknown Mandatory TLV
       3          Floor Request ID Does Not Exist
       4          Unauthorized Operation
       5          User does not Exist
       6          Invalid Request-ID
       7          INTEGRITY TLV Required

   Error Specific Details: Present only for certain Error Codes.  In
   this document, only for Error Code 2 (Unknown Mandatory TLV).  For
   Error Code 2, this field contains the Types of the TLVs (which were
   present in the message that triggered the Error message) that were
   unknown to the receiver, encoded as follows.


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

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

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



Camarillo, et al.      Expires February 17, 2005               [Page 18]

Internet-Draft                    BFCP                       August 2004


   ignored by the receiver.  Note all the Error Codes defined in this
   document but Error Code 2, result in a TLV which is already 32-bit
   aligned (i.e., no need of padding).  Error Code 2 results in a TLV
   that may need 2 bytes of padding.

5.2.10  USER-DISPLAY-NAME

   The USER-DISPLAY-NAME attribute type is 9 and its format is the same
   as the HUMAN-READABLE-INFO attribute.  The Text field in the
   USER-DISPLAY-NAME attribute contains the name of the user.

5.2.11  USER-URI

   The USER-URI attribute type is 10 and its format is the same as the
   HUMAN-READABLE-INFO attribute.  The Text field in the USER-URI
   attribute contains the URI of the user.

5.2.12  PRIORITY

   The following is the format of the contents of the PRIORITY
   attribute, whose attribute type is 11.


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Type = 7   |M|    Length     |   Priority    |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

6.  Message Format

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

6.1  FloorRequest

   Clients request a floor by sending a FloorRequest message to the
   floor control server.  In addition, the FloorRequest message is also
   used to modify existing floor requests.  The following is the format
   of the FloorRequest message:





Camarillo, et al.      Expires February 17, 2005               [Page 19]

Internet-Draft                    BFCP                       August 2004


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


6.2  FloorRelease

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


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


6.3  FloorRequestInfo

   Clients request information about a floor request by sending a
   FloorRequestInfo message to the floor control server.  The following
   is the format of the FloorRequest message:


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


6.4  FloorRequestStatus

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





Camarillo, et al.      Expires February 17, 2005               [Page 20]

Internet-Draft                    BFCP                       August 2004


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


6.5  FloorInfo

   Clients request information about a floor or floors by sending a
   FloorInfo message to the floor control server.  The following is the
   format of the FloorRequest message:


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


6.6  FloorStatus

   The floor control server informs clients about the status, e.g., the
   current holder(s), of a floor by sending them FloorStatus messages.
   The following is the format of the FloorStatus message:


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



Camarillo, et al.      Expires February 17, 2005               [Page 21]

Internet-Draft                    BFCP                       August 2004


6.7  ChairAction

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


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


6.8  ChairActionAck

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


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


6.9  Ping

   Clients check the liveness of servers, and servers of clients, by
   sending a Ping message.  The following is the format of the Ping
   message:


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


6.10  PingAck

   Servers confirm that they are alive on reception of a Ping message by
   sending a PingAck message.  The following is the format of the
   PingAck message:



Camarillo, et al.      Expires February 17, 2005               [Page 22]

Internet-Draft                    BFCP                       August 2004


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


6.11  Error

   The floor control server informs clients about errors processing
   requests by sending them Error messages.  The following is the format
   of the Error message:


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


7.  Transport

   BFCP entities exchange BFCP messages using TCP connections.  TCP
   provides an in-order reliable delivery of a stream of bytes.
   Consequently, message framing is implemented in the application
   layer.  BFCP implements application-layer framing using TLVs.

   Editor's note: We need to address how to handle lost TCP connections
   (e.g., that the TCP connection will be re-established in this case
   using O/A as described further below).

8.  Lower-Layer Security

   BFCP relies on lower-layer security mechanisms to provide replay
   protection, and confidentiality.  BFCP servers MUST support TLS [4],
   and clients SHOULD support TLS.  Clients and servers MAY support
   other security mechanisms.

   OPEN ISSUE: do we want to implement replay-protection in the protocol
   instead of relying on TLS?

   Servers and clients that implement TLS MUST support TBD.  (cypher and
   hash algorithm).

9.  Protocol Transactions

   In BFCP, there are two types of transactions: client-initiated



Camarillo, et al.      Expires February 17, 2005               [Page 23]

Internet-Draft                    BFCP                       August 2004


   transactions and server-initiated transactions (notifications).
   Client-initiated transactions consist of a request from a client to a
   server and a response from the server to the client.  The request
   carries a TRANSACTION-ID TLV which the 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
   server to a client.  Consequently, since they do not trigger any
   response, server-initiated transactions do not have Transaction IDs
   associated with them.

9.1  Client Behavior

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

   The client MUST set the Transaction ID value in the TRANSACTION-ID
   TLV to a number which MUST NOT be reused in another message from the
   client until a response from the server is received.  The client uses
   the Transaction ID value to match this FloorRequest message with the
   response from the floor control server.

9.2  Server Behavior

   A server sending a response within a client-initiated transaction
   MUST copy the Conference ID and the TRANSACTION-ID TLV from the
   request received from the client into the response.  Server-initiated
   transactions MUST NOT contain a TRANSACTION-ID TLV.

10.  Authentication

   BFCP uses the INTEGRITY TLV to provide client and server
   authentication, and message integrity.  The INTEGRITY TLV contains an
   HMAC-SHA1 [1] of the BFCP message.  The use of SHA1 implies that the
   length of the HMAC is 20 bytes.  The text used as input to HMAC is
   the BFCP message, including the FIXED-HEADER, up to and including the
   TLV preceding the INTEGRITY TLV.  This text is then padded with
   zeroes so as to be a multiple of 64 bytes.  As a result, the
   INTEGRITY TLV MUST be the last attribute in any BFCP message.  The
   key used as input to HMAC is the secret shared between the server and
   the user identified by the USER-ID TLV in the message.

10.1  Client Behavior

   Clients SHOULD add an INTEGRITY TLV to all their messages.
   Furthermore, if a client generates a message without this TLV and



Camarillo, et al.      Expires February 17, 2005               [Page 24]

Internet-Draft                    BFCP                       August 2004


   receives an Error response with Error Code 7 (INTEGRITY TLV
   Required), the client SHOULD NOT send more messages without the
   INTEGRITY TLV to the same server within the same conference.

   When a client receives a BFCP message with an INTEGRITY TLV, it
   calculates the HMAC-SHA1 [1] of the message excluding the INTEGRITY
   TLV.  The key used as input to HMAC is the secret shared between the
   server and the user identified by the USER-ID TLV in the message.  If
   the resulting value is the same as the one in the INTEGRITY TLV,
   authentication is considered successful.  If the resulting value is
   different than the one in the INTEGRITY TLV, authentication is
   considered to have failed and the message MUST NOT be processed
   further.

10.2  Server Behavior

   Servers SHOULD add an INTEGRITY TLV to all their messages.
   Furthermore, if a client sends messages with this TLV to a server,
   the server MUST include it as well in its messages to this client.

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

   When a server receives a BFCP message with an INTEGRITY TLV, it
   calculates the HMAC-SHA1 [1] of the message excluding the INTEGRITY
   TLV.  The key used as input to HMAC is the secret shared between the
   server and the user identified by the USER-ID TLV in the message.  If
   the resulting value is the same as the one in the INTEGRITY TLV,
   authentication is considered successful.

   If the resulting value is different than the one in the INTEGRITY
   TLV, authentication is considered to have failed, in which case the
   server SHOULD return an Error message with Error Code 1
   (Authentication Failed).  Messages that cannot be authenticated MUST
   NOT be processed further.

11.  Client Operations

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

11.1  Requesting a Floor

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



Camarillo, et al.      Expires February 17, 2005               [Page 25]

Internet-Draft                    BFCP                       August 2004


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

   The client sets the Conference ID in the FIXED-HEADER and the
   TRANSACTION-ID TLV following the rules given in Section 9.1.
   Additionally, the client follows the rules in Section 10.1 which
   relate to the authentication and the protection of the integrity of
   the message (i.e., to the INTEGRITY TLV).

   The client must insert a USER-ID TLV, which will be used by the
   server to authenticate and authorize the request.  If the user
   sending the FloorRequest message (identified by the USER-ID TLV) is
   not the same as the user requesting the floor (i.e., a third party
   floor request), the client SHOULD add a BENEFICIARY-ID TLV to the
   message identifying the beneficiary of the floor.

   The client must insert at least one FLOOR-ID TLV in the FloorRequest
   message.  If the client inserts more than one FLOOR-ID TLVs, the
   server will treat all the floor requests as an atomic package.  That
   is, the floor control server will either grant or deny all the floors
   in the FloorRequest message.

   The client may use a HUMAN-READABLE-INFO TLV to state the reason why
   the floor or floors are being requested.  The Text field in the
   HUMAN-READABLE-INFO TLV is intended for human consumption.

   The client may request the server to handle the floor request with a
   certain priority using a PRIORITY TLV.

11.1.1  Receiving a Response

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

   If the response is a FloorRequestStatus message, the client obtains
   information about the status of the FloorRequest in a REQUEST-STATUS
   TLV.  If the Request Status value is Granted, the client has been
   granted all the floors that were requested in the FloorRequest
   message.  If the Request Status value is Denied, the client has been
   denied all the floors that were requested in the FloorRequest
   message.  The HUMAN-READABLE-INFO TLV, if present, provides extra
   information which the client MAY display to the user.

   A floor request is considered to be ongoing while it is in the
   Pending, Accepted, or Granted states.  FloorRequestStatus messages



Camarillo, et al.      Expires February 17, 2005               [Page 26]

Internet-Draft                    BFCP                       August 2004


   carrying any of these states will contain a FLOOR-REQUEST-ID TLV.
   The value of this TLV is used to match subsequent messages received
   at the client side (e.g., further FloorRequestStatus messages) or at
   the server side (e.g., a FloorRelease message) with this floor
   request.

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

12.  Requesting Information about Floor Requests

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

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

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

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

12.1  Receiving a Response

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

   If the FloorRequestInfo message requested information about several
   floor requests, the FloorRequestStatus message will contain
   information about all of them.



Camarillo, et al.      Expires February 17, 2005               [Page 27]

Internet-Draft                    BFCP                       August 2004


13.  Cancelling a Floor Request and Releasing a Floor

   A client that wishes to cancel an ongoing floor request does so by
   sending a FloorRelease message to the floor control server.  The ABNF
   in Section 6.2 describes the TLVs that a FloorRelease message can
   contain.  In addition, the ABNF specifies which of these TLVs are
   mandatory, and which ones are optional.

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

      Note that the FloorRelease message is also used to release a floor
      or floors that were granted to the client (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 client uses the FLOOR-REQUEST-ID that was received in the
   response to the FloorRequest message that the FloorRelease message is
   cancelling.

13.1  Receiving a Response

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

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

14.  Requesting Information about Floors

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

   The client sets the Conference ID in the FIXED-HEADER and the



Camarillo, et al.      Expires February 17, 2005               [Page 28]

Internet-Draft                    BFCP                       August 2004


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

   The client inserts in the message all the FLOOR-IDs it wants to
   receive information about.  The 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
   FloorInfo message removing the FLOOR-ID of this floor.  If the client
   does not want to receive information about any floor, it sends a
   FloorInfo message with no FLOOR-ID TLV.

14.1  Receiving a Response

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

   On reception of the FloorInfo message, the server will respond with a
   FloorStatus message or with an Error message.  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 in its FloorInfo message, the FloorStatus
   message from the server will not include any either.

   After the first FloorStatus, the server will continue sending
   FloorStatus messages periodically informing the client about changes
   on the floors the client requested information about.

15.  Checking the Liveness of a Server

   A client that wishes to check the liveness of a server does so by
   sending a Ping message to the floor control server.  The ABNF in
   Section 6.9 describes the TLVs that a Ping message can contain.  In
   addition, the ABNF specifies which of these TLVs are mandatory, and
   which ones are optional.

   The client sets the Conference ID in the FIXED-HEADER and the
   TRANSACTION-ID TLV following the rules given in Section 9.1.
   Additionally, the client follows the rules in Section 10.1 which
   relate to the authentication and the protection of the integrity of
   the message (i.e., to the INTEGRITY TLV).





Camarillo, et al.      Expires February 17, 2005               [Page 29]

Internet-Draft                    BFCP                       August 2004


15.1  Receiving Responses

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

   If the response is a PingAck message, the server is alive and the
   user identified by the User ID was authenticated successfully.

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

16.  Chair Operations

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

16.1  Obtaining Information about Floor Requests

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

16.2  Instructing the Floor Control Server

   Chairs that wish to send instructions to a floor control server does
   so by sending a ChairAction message.  The ABNF in Section 6.7
   describes the TLVs that a ChairAction message can contain.  In
   addition, the ABNF specifies which of these TLVs are mandatory, and
   which ones are optional.

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

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



Camarillo, et al.      Expires February 17, 2005               [Page 30]

Internet-Draft                    BFCP                       August 2004


   are identified by FLOOR-ID TLVs and the floor request is identified
   by a FLOOR-REQUEST-ID TLV, which are carries in the ChairAction
   message.

      For example, if a floor request consists of two floors that depend
      on different chairs, each chair will grant its floor within the
      floor request.  Once both chairs have grant their floor, the floor
      control server will grant the floor request as a whole.  On the
      other hand, if one of the chairs denies its floor, the floor
      control server will deny the floor request as a whole, regardless
      of the other chair's decision.

   The chair provides the new status for one or more floors within the
   floor request using a REQUEST-STATUS TLV.  If the new status of the
   floor request is Accepted, the chair MAY use the Queue Position field
   to provide a queue position for the floor request.  If the chair does
   not wish to provide a queue position, all the bits of the Queue
   Position field SHOULD be set to zero.  The chair SHOULD use the
   Status Revoked to revoke a floor that was granted (i.e., Granted
   status) and to reject floor requests in any other status (e.g.,
   Pending and Accepted).

      Note a floor request may involve several floors and that a
      ChairAction message could only deal with a subset of these floors
      (e.g., if a single chair is not authorized to manage all the
      floors).  In this case, the REQUEST-STATUS that the 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 chairs to
      come up with the actual status of the floor request.

   The chair may use a HUMAN-READABLE-INFO TLV to state the reason why
   the floor or floors are being accepted, granted, or revoked.  The
   Text in the HUMAN-READABLE-INFO TLV is intended for human
   consumption.

16.2.1  Receiving a Response

   A message from the server is considered to be a response to the
   ChairAction message if the message from the server has the same
   Conference ID and Transaction ID as the ChairAction message, as
   described in Section 9.1.

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




Camarillo, et al.      Expires February 17, 2005               [Page 31]

Internet-Draft                    BFCP                       August 2004


17.  Server Operations

   This section specifies how 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 server SHOULD send an
   Error message, as described in Section 17.7, with Error code 0
   (Conference does not Exist).

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

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

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

17.1  Reception of a FloorRequest Message

   The processing of a FloorRequest message by a server involves
   generating a FloorRequestStatus message.  The floor control server
   SHOULD generate a FloorRequestStatus message as soon as possible.  If
   the floor 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.

   The server copies the Conference ID and the TRANSACTION-ID TLV from
   the FloorRequest into the FloorRequestStatus, as described in Section
   9.2.  Additionally, the server MUST assign an identitifier that is
   unique within the conference to this floor request, and insert it in
   a FLOOR-REQUEST-ID TLV into the FloorRequestStatus message.  This
   indentifier will be used by the client to refer to this specific
   floor request in the future.

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

   At later time, when the status of the floor request changes, the



Camarillo, et al.      Expires February 17, 2005               [Page 32]

Internet-Draft                    BFCP                       August 2004


   floor control server SHOULD send a new FloorRequestStatus message
   with the appropriate Request Status.  This FloorRequestStatus message
   MUST contain a FLOOR-REQUEST-ID TLV identifying the floor request,
   but MUST NOT contain any TRANSACTION-ID TLV.  The server may add a
   HUMAN-READABLE-INFO TLV to provide extra information to the user
   about its decision.

      The rate at which the floor control server sends
      FloorRequestStatus messages is a matter of local policy.  A 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.

   Clients and chairs that request so need to be informed about changes
   in the status of a floor (e.g., a new floor request arrives).  To
   accomplish this, the floor control server follows the rules in
   Section 17.4.

17.2  Reception of a FloorRequestInfo Message

   The processing of a FloorRequestInfo message by a server involves
   generating a FloorRequestStatus message.  The FloorRequestInfo
   message can apply to a single floor request, identified by a
   FLOOR-REQUEST-ID, or to all the floor requests from a given user, the
   FloorRequestInfo does not carry a FLOOR-REQUEST-ID.  The user is
   identified by a BENEFICIARY-ID TLV, or if this is not present, by a
   USER-ID TLV.

   If the FloorRequestInfo message contains an invalid FLOOR-REQUEST-ID,
   the floor control server SHOULD respond with an Error response with
   Error Code 3 (Floor Request ID Does Not Exist).

   On reception of a FloorRequestInfo message, the floor control server
   SHOULD generate a FloorRequestStatus message as soon as possible.

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

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

17.3  Reception of a FloorRelease Message

   The processing of a FloorRelease message by a server involves
   generating a FloorRequestStatus message.  The FloorRelease message
   identifies the floor request it applies to using a FLOOR-REQUEST-ID.



Camarillo, et al.      Expires February 17, 2005               [Page 33]

Internet-Draft                    BFCP                       August 2004


   If the FloorRelease message contains an invalid FLOOR-REQUEST-ID, the
   floor control server SHOULD respond with an Error response with Error
   Code 3 (Floor Request ID Does Not Exist).

   On reception of a FloorRelease message with a valid FLOOR-REQUEST-ID,
   the floor control server SHOULD generate a FloorRequestStatus message
   as soon as possible.  If the floor server can authorize the release
   operation right away, it SHOULD use a Request Status value of
   Released, if the floor had been previously granted, or of Cancelled,
   if it had not.  The server may add a HUMAN-READABLE-INFO TLV to
   provide extra information to the user about its decision.

   The server copies the Conference ID and the TRANSACTION-ID TLV from
   the FloorRelease into the FloorRequestStatus, as described in Section
   9.2.

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

17.4  Reception of a FloorInfo Message

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

   The information FloorInfo messages carry may depend on the user
   requesting the information.  For example, a chair may be able to
   receive information about pending requests while a regular user may
   not be authorized to do so.

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

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

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

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

   After sending this message, the server SHOULD continue sending



Camarillo, et al.      Expires February 17, 2005               [Page 34]

Internet-Draft                    BFCP                       August 2004


   FloorStatus messages about all the floors the client requested
   information about.  These messages MUST NOT carry a TRANSACTION-ID
   TLV.

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

17.5  Reception of a ChairAction Message

   On reception of a ChairAction message, the floor control server
   checks whether the chair that send the message is authorized to
   perform the operation being requested.  If the chair is authorized,
   the floor control server performs the operation and sends a
   ChairActionAck message to the client.  If the new Status in the
   ChairAction message is Accepted and all the bits of the Queue
   Position field are zero, the server assigns a queue position (e.g.,
   the last in the queue) to the floor request based on local policy (in
   case the server implements a queue).

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

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

   If the floor control server cannot find a floor request that matches
   the FLOOR-REQUEST-ID TLV in the ChairAction message the floor control
   server generates an Error message, as described in Section 17.7, with
   an Error code with a value of 3 (Floor Request ID Does Not Exist).

   If the chair is not authorized to perform the operation being
   requested, the floor control server generates an Error message, as
   described in Section 17.7, with an Error code with a value of 4
   (Unauthorized Operation).

17.6  Reception of a Ping Message

   The processing of a Ping message by a server involves generating a
   PingAck message.  On reception of a Ping message, the floor control
   server SHOULD generate a PingAck message as soon as possible.  The
   server copies the Conference ID and the TRANSACTION-ID TLV from the
   Ping into the PingAck, as described in Section 9.2.

   The server follows the rules in Section 10.2 which relate to



Camarillo, et al.      Expires February 17, 2005               [Page 35]

Internet-Draft                    BFCP                       August 2004


   authentication and the use of the INTEGRITY TLV.

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

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

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

18.  BFCP and the Offer/Answer Model

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

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

18.1  Fields in the m Line

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

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

   The media field MUST have a value of "application".  The port field
   is not used by BFCP, and MAY be set to any value chosen by the
   endpoint.  A port field value of zero has the standard SDP meaning
   (i.e., rejection of the media stream).

   The port field is set following the rules in [14].  Depending on the
   value of the setup attribute (disccused in Section 18.4), the port
   field contains the port the remote endpoint will initiate its TCP
   connection to, or is irrelevant (i.e., the endpoint will initiate the
   connection towards the remote endpoint) and should be set to a value
   of 9, which is the discard port.  Since BFCP only runs on top of TCP,
   the port is always a TCP port.




Camarillo, et al.      Expires February 17, 2005               [Page 36]

Internet-Draft                    BFCP                       August 2004


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

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

   The following is an example of an m line for a BFCP connection:

   m=application 20000 TCP/BFCP *

18.2  The confid and userid SDP Parameters

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



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

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

   The confid and the userid attributes carry the integer representation
   of a conference ID and a user ID respectively.

   Endpoints which use the offer/answer model to establish BFCP
   connections MUST support the confid and the userid attributes.  A
   floor control server acting as an offerer or as an answerers SHOULD
   include these attributes in its session descriptions.

18.3  The k line

   If the offer/answer exchange is encrypted and integrity protected,
   the offerer MAY use an SDP k line to provide the answerer with a
   shared secret to be used to calculate the value of the INTEGRITY
   TLVs.  The following is an example of a k line:



   k=base64:c2hhcmVkLXNlY3JldA==


18.4  TCP Connection Management

   The management of the TCP connection used to transport BFCP is
   performed using the setup and connid attributes as defined in [14].




Camarillo, et al.      Expires February 17, 2005               [Page 37]

Internet-Draft                    BFCP                       August 2004


   The setup attribute indicates which of the endpoints (client or floor
   control server) initiates the TCP connection.  The connid attribute
   handles TCP connection reestablishment.

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

18.5  Association between Streams and Floors

   EDITOR'S NOTE: We need a way for clients that don't support CPCP to
   at a minimum learn enough information about floors to use the floor
   control protocol.  This section will need to be harmonized with the
   media policy work.

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



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

   The floorid attribute is used in BFCP m lines and associates a floor
   ID with a media stream.  The token representing the floor ID is the
   integer representation of the 16-bit floorid to be used in BFCP.  The
   token representing the media stream is a pointer to the media stream,
   which is identified by an SDP label attribute
   [draft-levin-mmmusic-sdp-media-label-00.txt].

   Endpoints which use the offer/answer model to establish BFCP
   connections MUST support the floorid and the label attributes.  A
   floor control server acting as an offerer or as an answerers SHOULD
   include these attributes in its session descriptions.

18.6  Example

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


   m=application 20000 TCP/BFCP *
   k=base64:c2hhcmVkLXNlY3JldA==
   a=setup:passive
   a=connid:1
   a=confid:4321
   a=userid:1234
   a=floorid:1 m-stream:10
   a=floorid:2 m-stream:11



Camarillo, et al.      Expires February 17, 2005               [Page 38]

Internet-Draft                    BFCP                       August 2004


   m=audio 20000 RTP/AVP 0
   a=label:10
   m=video 30000 RTP/AVP 31
   a=label:11

   The following is the answer returned by the user.


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


19.  Security Considerations

   TBD.

20.  IANA Considerations

   TBD

20.1  SDP Attributes Registration

   TBD:

21.  Acknowledgments

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

22.  References

22.1  Normative References

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

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

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

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



Camarillo, et al.      Expires February 17, 2005               [Page 39]

Internet-Draft                    BFCP                       August 2004


         2246, January 1999.

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

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

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

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

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

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

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

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

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

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

22.2  Informational References

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

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



Camarillo, et al.      Expires February 17, 2005               [Page 40]

Internet-Draft                    BFCP                       August 2004


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

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

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


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com


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

   EMail: jo@tzi.org


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

   EMail: drage@lucent.com








Camarillo, et al.      Expires February 17, 2005               [Page 41]

Internet-Draft                    BFCP                       August 2004


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Camarillo, et al.      Expires February 17, 2005               [Page 42]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/