[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: January 4, 2005                                          J. Ott
                                                     Universitaet Bremen
                                                                K. Drage
                                                     Lucent Technologies
                                                            July 6, 2004


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I 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 January 4, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   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.






Camarillo, et al.       Expires January 4, 2005                 [Page 1]

Internet-Draft                    BFCP                         July 2004


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 . . .   6
     3.3  Generating a Shared Secret . . . . . . . . . . . . . . . .   6
     3.4  Obtaining Floor-Resource Associations  . . . . . . . . . .   7
     3.5  Policy Enforcement . . . . . . . . . . . . . . . . . . . .   7
   4.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   8
     4.1  User - Floor Control Server Interface  . . . . . . . . . .   8
     4.2  Floor Chair - Floor Control Server Interface . . . . . . .  10
   5.   Packet Format  . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1  FIXED-HEADER Format  . . . . . . . . . . . . . . . . . . .  11
     5.2  Attribute Format . . . . . . . . . . . . . . . . . . . . .  12
       5.2.1  FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . .  12
       5.2.2  USER-ID  . . . . . . . . . . . . . . . . . . . . . . .  13
       5.2.3  BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . .  13
       5.2.4  REQUEST-ID . . . . . . . . . . . . . . . . . . . . . .  13
       5.2.5  FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . .  14
       5.2.6  HUMAN-READABLE-INFO  . . . . . . . . . . . . . . . . .  14
       5.2.7  INTEGRITY  . . . . . . . . . . . . . . . . . . . . . .  14
       5.2.8  REQUEST-STATUS . . . . . . . . . . . . . . . . . . . .  15
       5.2.9  ERROR-CODE . . . . . . . . . . . . . . . . . . . . . .  16
       5.2.10   USER-DISPLAY-NAME  . . . . . . . . . . . . . . . . .  17
       5.2.11   USER-URI . . . . . . . . . . . . . . . . . . . . . .  17
       5.2.12   PRIORITY . . . . . . . . . . . . . . . . . . . . . .  18
       5.2.13   PRIVACY  . . . . . . . . . . . . . . . . . . . . . .  18
   6.   Message Format . . . . . . . . . . . . . . . . . . . . . . .  18
     6.1  FloorRequest . . . . . . . . . . . . . . . . . . . . . . .  18
     6.2  FloorRelease . . . . . . . . . . . . . . . . . . . . . . .  19
     6.3  FloorRequestInfo . . . . . . . . . . . . . . . . . . . . .  19
     6.4  FloorRequestStatus . . . . . . . . . . . . . . . . . . . .  19
     6.5  FloorInfo  . . . . . . . . . . . . . . . . . . . . . . . .  20
     6.6  FloorStatus  . . . . . . . . . . . . . . . . . . . . . . .  20
     6.7  ChairAction  . . . . . . . . . . . . . . . . . . . . . . .  21
     6.8  ChairActionAck . . . . . . . . . . . . . . . . . . . . . .  21
     6.9  Ping . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
     6.10   PingAck  . . . . . . . . . . . . . . . . . . . . . . . .  21
     6.11   Error  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   7.   Transport  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   8.   Lower-Layer Security . . . . . . . . . . . . . . . . . . . .  22
   9.   Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   10.  Protocol Transactions  . . . . . . . . . . . . . . . . . . .  23
     10.1   Client Behavior  . . . . . . . . . . . . . . . . . . . .  23
     10.2   Server Behavior  . . . . . . . . . . . . . . . . . . . .  23
   11.  Authentication . . . . . . . . . . . . . . . . . . . . . . .  24



Camarillo, et al.       Expires January 4, 2005                 [Page 2]

Internet-Draft                    BFCP                         July 2004


     11.1   Client Behavior  . . . . . . . . . . . . . . . . . . . .  24
     11.2   Server Behavior  . . . . . . . . . . . . . . . . . . . .  24
   12.  Client Operations  . . . . . . . . . . . . . . . . . . . . .  25
     12.1   Requesting a Floor . . . . . . . . . . . . . . . . . . .  25
       12.1.1   Receiving a Response . . . . . . . . . . . . . . . .  26
     12.2   Modifying a Floor Request  . . . . . . . . . . . . . . .  26
       12.2.1   Receiving a Response . . . . . . . . . . . . . . . .  27
     12.3   Requesting Information about Floor Requests  . . . . . .  27
       12.3.1   Receiving a Response . . . . . . . . . . . . . . . .  28
     12.4   Cancelling a Floor Request and Releasing a Floor . . . .  28
       12.4.1   Receiving a Response . . . . . . . . . . . . . . . .  28
     12.5   Requesting Information about Floors  . . . . . . . . . .  29
       12.5.1   Receiving a Response . . . . . . . . . . . . . . . .  29
     12.6   Checking the Liveness of a Server  . . . . . . . . . . .  30
       12.6.1   Receiving Responses  . . . . . . . . . . . . . . . .  30
   13.  Chair Operations . . . . . . . . . . . . . . . . . . . . . .  30
     13.1   Obtaining Information about Floor Requests . . . . . . .  30
     13.2   Instructing the Floor Control Server . . . . . . . . . .  30
       13.2.1   Receiving a Response . . . . . . . . . . . . . . . .  32
   14.  Server Operations  . . . . . . . . . . . . . . . . . . . . .  32
     14.1   Reception of a FloorRequest Message  . . . . . . . . . .  32
       14.1.1   Floor Request Modification . . . . . . . . . . . . .  33
     14.2   Reception of a FloorRequestInfo Message  . . . . . . . .  33
     14.3   Reception of a FloorRelease Message  . . . . . . . . . .  34
     14.4   Reception of a FloorInfo Message . . . . . . . . . . . .  34
     14.5   Reception of a ChairAction Message . . . . . . . . . . .  35
     14.6   Reception of a Ping Message  . . . . . . . . . . . . . .  36
     14.7   Error Message Generation . . . . . . . . . . . . . . . .  36
   15.  BFCP and the Offer/Answer Model  . . . . . . . . . . . . . .  36
     15.1   Fields in the m Line . . . . . . . . . . . . . . . . . .  37
     15.2   The confid and userid SDP Parameters . . . . . . . . . .  37
     15.3   The k line . . . . . . . . . . . . . . . . . . . . . . .  38
     15.4   TCP Connection Management  . . . . . . . . . . . . . . .  38
     15.5   Association between Streams and Floors . . . . . . . . .  38
     15.6   Example  . . . . . . . . . . . . . . . . . . . . . . . .  39
   16.  Security Considerations  . . . . . . . . . . . . . . . . . .  39
   17.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  39
     17.1   SDP Attributes Registration  . . . . . . . . . . . . . .  39
   18.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  40
   19.  References . . . . . . . . . . . . . . . . . . . . . . . . .  40
   19.1   Normative References . . . . . . . . . . . . . . . . . . .  40
   19.2   Informational References . . . . . . . . . . . . . . . . .  41
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  41
        Intellectual Property and Copyright Statements . . . . . . .  43







Camarillo, et al.       Expires January 4, 2005                 [Page 3]

Internet-Draft                    BFCP                         July 2004


1.  Introduction

   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 safe 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
   the floor(s) including which floors exists, who the floor chairs are,



Camarillo, et al.       Expires January 4, 2005                 [Page 4]

Internet-Draft                    BFCP                         July 2004


   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.

3.  Scope

   Figure 1 shows the tasks that BFCP can perform.


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



Camarillo, et al.       Expires January 4, 2005                 [Page 5]

Internet-Draft                    BFCP                         July 2004


   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 sections, 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 to 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
   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 15 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.



Camarillo, et al.       Expires January 4, 2005                 [Page 6]

Internet-Draft                    BFCP                         July 2004


   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.

3.4  Obtaining Floor-Resource Associations

   Floors are associated to 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 to
   which floors. They can obtain this information using different
   mechanisms, such as CPCP or an offer/answer [11] exchange. Section 15
   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 to 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 another 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.



Camarillo, et al.       Expires January 4, 2005                 [Page 7]

Internet-Draft                    BFCP                         July 2004


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

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).
      XXX: Users need a means to authorize 3rd parties to request floors
      on their behalf. CPCP?

   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.

   Users can request privacy by including a PRIVACY TLV in their
   FloorRequest messages. In this case, 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.



Camarillo, et al.       Expires January 4, 2005                 [Page 8]

Internet-Draft                    BFCP                         July 2004


   Client                     Floor Control
                                 Server

     |      FloorRequest            |
     |        TRANSACTION-ID: 123   |
     |----------------------------->|
     |                              |
     |   FloorRequestStatus         |
     |     TRANSACTION-ID: 123      |
     |     FLOOR-REQUEST-ID: 345    |
     |     REQUEST-STATUS: Pending  |
     |<-----------------------------|
     |                              |
     |   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 |
     |<-----------------------------|
     |                              |






    Client or                    Floor Control
      Chair                         Server

        |      FloorInfo               |
        |        TRANSACTION-ID: 123   |
        |        FLOOR-ID: 15          |



Camarillo, et al.       Expires January 4, 2005                 [Page 9]

Internet-Draft                    BFCP                         July 2004


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




4.2  Floor Chair - Floor Control Server Interface

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




     Chair                      Floor Control
                                   Server

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




Camarillo, et al.       Expires January 4, 2005                [Page 10]

Internet-Draft                    BFCP                         July 2004


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:



     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



Camarillo, et al.       Expires January 4, 2005                [Page 11]

Internet-Draft                    BFCP                         July 2004


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



Camarillo, et al.       Expires January 4, 2005                [Page 12]

Internet-Draft                    BFCP                         July 2004


   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
   identifies a user within a conference.

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





Camarillo, et al.       Expires January 4, 2005                [Page 13]

Internet-Draft                    BFCP                         July 2004


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

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

   In some situations, the contents of the Text field may be generated
   by an automata. If such automata 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



Camarillo, et al.       Expires January 4, 2005                [Page 14]

Internet-Draft                    BFCP                         July 2004


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

   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.


      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



Camarillo, et al.       Expires January 4, 2005                [Page 15]

Internet-Draft                    BFCP                         July 2004


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



Camarillo, et al.       Expires January 4, 2005                [Page 16]

Internet-Draft                    BFCP                         July 2004


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



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

Internet-Draft                    BFCP                         July 2004


   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.

5.2.13  PRIVACY

   The following is the format of the contents of the PRIVACY attribute,
   whose attribute type is 12.


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

   Reserved: at this point, the 16 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 January 4, 2005                [Page 18]

Internet-Draft                    BFCP                         July 2004


   FloorRequest =   (FIXED-HEADER)
                    (TRANSACTION-ID)
                    (USER-ID)
                    [BENEFICIARY-ID]
                    [PRIVACY]
                    [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 January 4, 2005                [Page 19]

Internet-Draft                    BFCP                         July 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 holder 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 January 4, 2005                [Page 20]

Internet-Draft                    BFCP                         July 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 January 4, 2005                [Page 21]

Internet-Draft                    BFCP                         July 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.

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 XXX (cypher and
   hash algorithm).

9.  Privacy

   Clients may not want to disclose their identity to other users when
   they request a floor. Clients can request privacy by adding a PRIVACY
   TLV to their FloorRequest messages. This way, a client can request
   privacy for a particular floor request, and not request it for
   another one.



Camarillo, et al.       Expires January 4, 2005                [Page 22]

Internet-Draft                    BFCP                         July 2004


   Floor control servers do not disclose the identity of the user
   requesting a floor when privacy is requested (e.g., their
   FloorRequestStatus messages do not contain a BENEFICIARY-ID TLV).
   Nevertheless, if an attacker can get access to a given FloorRequest
   message, it will be able to discover the ID of the user requesting
   the floor, even if the message contains a PRIVACY TLV.

   So, clients that want to avoid this attack need to implement
   confidentiality underneath BFCP, as described in Section 8.

   OPEN ISSUE: shall we define the PRIVACY TLV as a simple flag, or do
   we want to have more options. For example, the floor control can
   disclose the user's identity to the chair, but not to the rest of the
   users.

10.  Protocol Transactions

   In BFCP, there are two types of transactions: client-initiated
   transactions and server-initiated transactions. 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 to them.

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

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



Camarillo, et al.       Expires January 4, 2005                [Page 23]

Internet-Draft                    BFCP                         July 2004


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

11.1  Client Behavior

   Clients SHOULD add an INTEGRITY TLV to all their messages.
   Furthermore, if a client generates a message without this TLV and
   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.

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




Camarillo, et al.       Expires January 4, 2005                [Page 24]

Internet-Draft                    BFCP                         July 2004


   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.

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

12.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
   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 10.1.
   Additionally, the client follows the rules in Section 11.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.





Camarillo, et al.       Expires January 4, 2005                [Page 25]

Internet-Draft                    BFCP                         July 2004


12.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 10.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
   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.2  Modifying a Floor Request

   Clients modify the HUMAN-READABLE-INFO and the PRIORITY attributes of
   ongoing floor requests by sending a FloorRequest message. The ABNF in
   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 10.1.
   Additionally, the client follows the rules in Section 11.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.

   FloorRequest messages sent to modify an existing floor request MUST
   NOT contain any BENEFICIARY or FLOOR-ID TLV. Instead, the client MUST
   insert a FLOOR-REQUEST-ID TLV identifying the floor request to be
   modified.




Camarillo, et al.       Expires January 4, 2005                [Page 26]

Internet-Draft                    BFCP                         July 2004


      Clients modifying a floor request can provide new HUMAN-READABLE
      INFO and PRIORITY TLVs but cannot modify the beneficiary of the
      floor request or the floors being requested.

   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.

12.2.1  Receiving a Response

   After sending the FloorRequest message, the client follows the steps
   described in Section 12.1.1. Effectively, the client has issued a new
   floor request and asked the server to substitute an existing floor
   request with this new one. So, the FloorRequestStatus response to the
   new FloorRequest message will carry a different FLOOR-REQUEST-ID
   value than the old floor request.

   If the modification is authorized by the server, the client will
   receive a FloorRequestStatus message with a Status Code 7 (Replaced)
   indicating that the old floor request has been replaced.

12.3  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 10.1.
   Additionally, the client follows the rules in Section 11.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



Camarillo, et al.       Expires January 4, 2005                [Page 27]

Internet-Draft                    BFCP                         July 2004


   BENEFICIARY-ID TLV.

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

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

12.4  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 10.1.
   Additionally, the client follows the rules in Section 11.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.

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



Camarillo, et al.       Expires January 4, 2005                [Page 28]

Internet-Draft                    BFCP                         July 2004


   FloorRelease message, the client follows the steps described in
   Section 12.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.

12.5  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
   TRANSACTION-ID TLV following the rules given in Section 10.1.
   Additionally, the client follows the rules in Section 11.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.

12.5.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 10.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 form the sever 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.




Camarillo, et al.       Expires January 4, 2005                [Page 29]

Internet-Draft                    BFCP                         July 2004


12.6  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 10.1.
   Additionally, the client follows the rules in Section 11.1 which
   relate to the authentication and the protection of the integrity of
   the message (i.e., to the INTEGRITY TLV).

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

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

13.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 12.5. As a result, they
   receive information about floor requests that relate to specific
   floors in FloorStatus messages from the floor control server.

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



Camarillo, et al.       Expires January 4, 2005                [Page 30]

Internet-Draft                    BFCP                         July 2004


   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 10.1.
   Additionally, the chair follows the rules in Section 11.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
   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.



Camarillo, et al.       Expires January 4, 2005                [Page 31]

Internet-Draft                    BFCP                         July 2004


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

14.  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 14.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 11.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 14.7, with Error code 2 (Authentication Failed). The Error
   message SHOULD list the TLVs that were not understood.

   OPEN ISSUE: can servers use new 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.

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




Camarillo, et al.       Expires January 4, 2005                [Page 32]

Internet-Draft                    BFCP                         July 2004


   The server copies the Conference ID and the TRANSACTION-ID TLV from
   the FloorRequest into the FloorRequestStatus, as described in Section
   10.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 11.2 which relate to
   authentication and the use of the INTEGRITY TLV.

   At later time, when the status of the floor request changes, the
   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 14.4.

14.1.1  Floor Request Modification

   If the FloorRequest message contains a FLOOR-REQUEST-ID TLV, it means
   that the client is requesting a floor control to be modified. In
   addition to the actions described in Section 14.1, if the
   modification is authorized, the floor control server SHOULD send a
   FloorRequestStatus message with Request Status 7 (Replaced) for the
   original floor request.

   If the FloorRequest 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).

14.2  Reception of a FloorRequestInfo Message

   The processing of a FloorRequestInfo message by a server involves
   generating a FloorRequestStatus message. The FloorRequestInfo message



Camarillo, et al.       Expires January 4, 2005                [Page 33]

Internet-Draft                    BFCP                         July 2004


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

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

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

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

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



Camarillo, et al.       Expires January 4, 2005                [Page 34]

Internet-Draft                    BFCP                         July 2004


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

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

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

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

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



Camarillo, et al.       Expires January 4, 2005                [Page 35]

Internet-Draft                    BFCP                         July 2004


   the ChairAction message into the ChairActionAck message, as described
   in Section 10.2.

   The server follows the rules in Section 11.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 14.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 14.7, with an Error code with a value of 4
   (Unauthorized Operation).

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

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

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

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

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



Camarillo, et al.       Expires January 4, 2005                [Page 36]

Internet-Draft                    BFCP                         July 2004


   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.

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

   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 *

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



Camarillo, et al.       Expires January 4, 2005                [Page 37]

Internet-Draft                    BFCP                         July 2004


   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.

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


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

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

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




Camarillo, et al.       Expires January 4, 2005                [Page 38]

Internet-Draft                    BFCP                         July 2004


   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.

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


16.  Security Considerations

   TBD.

17.  IANA Considerations

   TBD

17.1  SDP Attributes Registration

   TBD:




Camarillo, et al.       Expires January 4, 2005                [Page 39]

Internet-Draft                    BFCP                         July 2004


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

19.  References

19.1  Normative References

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

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

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

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

   [5]   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



Camarillo, et al.       Expires January 4, 2005                [Page 40]

Internet-Draft                    BFCP                         July 2004


         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 SDP",
         draft-ietf-mmusic-sdp-comedia-05 (work in progress), March
         2003.

19.2  Informational References

   [15]  Schulzrinne, H., "Requirements for Floor Control Protocol",
         draft-ietf-xcon-floor-control-req-00 (work in progress),
         January 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.

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

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

   [19]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
         Package for Modification Events  for the Extensible Markup
         Language (XML) Configuration Access Protocol (XCAP) Managed
         Documents", draft-ietf-simple-xcap-package-01 (work in
         progress), February 2004.


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com





Camarillo, et al.       Expires January 4, 2005                [Page 41]

Internet-Draft                    BFCP                         July 2004


   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 January 4, 2005                [Page 42]

Internet-Draft                    BFCP                         July 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 IETF's procedures with respect to rights in IETF 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 January 4, 2005                [Page 43]


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