[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-xcon-bfcp

XCON Working Group                                          G. Camarillo
Internet-Draft                                                  Ericsson
Expires: September 30, 2004                                       J. Ott
                                                     Universitaet Bremen
                                                                K. Drage
                                                     Lucent Technologies
                                                              April 2004


                The Binary Floor Control Protocol (BFCP)
                    draft-camarillo-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 September 30, 2004.

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 and floor control servers.







Camarillo, et al.      Expires September 30, 2004               [Page 1]

Internet-Draft                    BFCP                        April 2004


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   5
   4.   Packet Format  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1  FIXED-HEADER Format  . . . . . . . . . . . . . . . . . . .   5
     4.2  Attribute Format . . . . . . . . . . . . . . . . . . . . .   6
       4.2.1  FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.2  USER-ID  . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.3  REQUEST-ID . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.4  HUMAN-READABLE-INFO  . . . . . . . . . . . . . . . . .   7
       4.2.5  TOKEN  . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.6  REQUEST-STATUS . . . . . . . . . . . . . . . . . . . .   8
       4.2.7  ERROR-CODE . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.8  USER-DISPLAY-NAME  . . . . . . . . . . . . . . . . . .  11
       4.2.9  USER-URI . . . . . . . . . . . . . . . . . . . . . . .  11
       4.2.10   PRIORITY . . . . . . . . . . . . . . . . . . . . . .  11
   5.   Message Format . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1  FloorRequest . . . . . . . . . . . . . . . . . . . . . . .  11
     5.2  FloorRelease . . . . . . . . . . . . . . . . . . . . . . .  12
     5.3  FloorRequestStatus . . . . . . . . . . . . . . . . . . . .  12
     5.4  FloorStatus  . . . . . . . . . . . . . . . . . . . . . . .  12
     5.5  ChairAction  . . . . . . . . . . . . . . . . . . . . . . .  13
     5.6  Ping . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.7  PingAck  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.8  Error  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   6.   bfcp and bfcps URI Definitions . . . . . . . . . . . . . . .  14
   7.   Contacting a bfcp or bfcps URI . . . . . . . . . . . . . . .  15
     7.1  Selecting a Transport Protocol . . . . . . . . . . . . . .  15
     7.2  Determining Port and IP Address  . . . . . . . . . . . . .  16
     7.3  Lower-Layer Security . . . . . . . . . . . . . . . . . . .  17
     7.4  Conference ID, User ID, and Token Values . . . . . . . . .  17
   8.   Client Operations  . . . . . . . . . . . . . . . . . . . . .  18
     8.1  Requesting a Floor . . . . . . . . . . . . . . . . . . . .  18
       8.1.1  Receiving Responses  . . . . . . . . . . . . . . . . .  19
     8.2  Cancelling a Floor Request . . . . . . . . . . . . . . . .  19
       8.2.1  Receiving Responses  . . . . . . . . . . . . . . . . .  20
     8.3  Releasing Floors . . . . . . . . . . . . . . . . . . . . .  20
       8.3.1  Receiving Responses  . . . . . . . . . . . . . . . . .  21
     8.4  Checking the Liveness of a Server  . . . . . . . . . . . .  21
       8.4.1  Receiving Responses  . . . . . . . . . . . . . . . . .  21
     8.5  Responding to a Ping Message . . . . . . . . . . . . . . .  22
   9.   Chair Operations . . . . . . . . . . . . . . . . . . . . . .  22
     9.1  Obtaining Information about Floor Requests . . . . . . . .  22
     9.2  Instructing the Floor Control Server . . . . . . . . . . .  22
   10.  Server Operations  . . . . . . . . . . . . . . . . . . . . .  23
     10.1   Reception of a FloorRequest Message  . . . . . . . . . .  23



Camarillo, et al.      Expires September 30, 2004               [Page 2]

Internet-Draft                    BFCP                        April 2004


     10.2   Checking the Liveness of a Client or Chair . . . . . . .  24
       10.2.1   Receiving a PingAck Message  . . . . . . . . . . . .  25
     10.3   Responding to a Ping Message . . . . . . . . . . . . . .  25
     10.4   Informing about the Status of a Floor  . . . . . . . . .  25
     10.5   Receiving a ChairAction Message  . . . . . . . . . . . .  25
     10.6   Error Message Generation . . . . . . . . . . . . . . . .  26
   11.  Security Considerations  . . . . . . . . . . . . . . . . . .  26
   12.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  26
     12.1   bfcp and bfcps URI Schemes Registration  . . . . . . . .  26
   13.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  27
   14.  References . . . . . . . . . . . . . . . . . . . . . . . . .  27
   14.1   Normative References . . . . . . . . . . . . . . . . . . .  27
   14.2   Informational References . . . . . . . . . . . . . . . . .  28
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  28
        Intellectual Property and Copyright Statements . . . . . . .  30




































Camarillo, et al.      Expires September 30, 2004               [Page 3]

Internet-Draft                    BFCP                        April 2004


1.  Introduction

   Conference applications may 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 [11] 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.

   BFCP provides a means for a floor control server to grant or deny
   requests to access a given resource from users. Nevertheless, BFCP
   does not allow floor control servers to keep a particular user or set
   of users from actually accessing the resource. Enforcing policy
   decisions is outside the scope of BFCP. In any case, one possible way
   to implement policy enforcement is to have the floor control server
   provide the conference policy server (e.g., using CPCP [12]) with
   policies that the conference policy server will apply to the
   conference.

   Floor control servers identify users using a 32-bit user ID. The way
   a conference server provides a user with its 32-bit user ID is out of
   the scope of this document.

   BFCP assumes that conference servers, after authenticating a user,
   provides this user with a token, in addition to the user's user ID.
   The user's client needs to include this token in its requests to
   prove that they belong to the same user as the conference server
   authenticated previously. The way a conference server provides a user
   with such a token in a secure fashion falls outside the scope of this
   document.

   Section 2 defines the terminology used throughout this document,
   Section 3 provides a non-normative overview of BFCP operation, and
   subsequent sections provide the normative specification of BFCP.

2.  Terminology

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

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



Camarillo, et al.      Expires September 30, 2004               [Page 4]

Internet-Draft                    BFCP                        April 2004


   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,
   who holds a floor, etc.  Requests to manipulate a floor are directed
   at the floor control server.

3.  Overview of Operation

   TBD: the Introduction and this section need more work.

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

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



Camarillo, et al.      Expires September 30, 2004               [Page 5]

Internet-Draft                    BFCP                        April 2004


     _________________________________________________________
       0          FloorRequest          C   ->  S
       1          FloorRelease          C   ->  S
       2          FloorRequestStatus    S   ->  C
       3          FloorStatus           S   ->  C ; S   ->  Ch
       4          ChairAction           Ch  ->  S
       5          Ping                  C  <->  S ; Ch <->  S
       6          PingAck               C  <->  S ; Ch <->  S
       7          Error                 S   ->  C ; S   ->  Ch

       S: Server  C: Client  Ch: Chair


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

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

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



Camarillo, et al.      Expires September 30, 2004               [Page 6]

Internet-Draft                    BFCP                        April 2004


4.2.1  FLOOR-ID

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


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

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

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

4.2.3  REQUEST-ID

   The following is the format of the contents of the REQUEST-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     |          Request ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

4.2.4  HUMAN-READABLE-INFO

   The following is the format of the contents of the



Camarillo, et al.      Expires September 30, 2004               [Page 7]

Internet-Draft                    BFCP                        April 2004


   HUMAN-READABLE-INFO 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 = 4   |M|    Length     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     /                             Text                              /
     /                                               +-+-+-+-+-+-+-+-+
     |                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Text: this field contains UTF-8 [10] 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.

4.2.5  TOKEN

   The following is the format of the contents of the TOKEN 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 = 5   |M|    Length     |             Token             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Token: this field contains a 16-bit token used to authenticate the
   user.

4.2.6  REQUEST-STATUS

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





Camarillo, et al.      Expires September 30, 2004               [Page 8]

Internet-Draft                    BFCP                        April 2004


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

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


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

   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.

4.2.7  ERROR-CODE

   The following is the format of the contents of the ERROR-CODE
   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 = 7   |M|    Length     |          Error Code           |



Camarillo, et al.      Expires September 30, 2004               [Page 9]

Internet-Draft                    BFCP                        April 2004


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                     Error Specific Details                    |
     /                                                               /
     /                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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


     Value        Meaning
     ______________________________
       0          Conference does not Exist
       1          Authentication Failed
       2          Unknown Mandatory TLV
       3          Floor Request does not Exist
       4          Unauthorized Operation
       5          User does not Exist
       6          Invalid Request-ID

   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



Camarillo, et al.      Expires September 30, 2004              [Page 10]

Internet-Draft                    BFCP                        April 2004


   aligned (i.e., no need of padding). Error Code 2 results in a TLV
   that may need 2 bytes of padding.

4.2.8  USER-DISPLAY-NAME

   The USER-DISPLAY-NAME attribute type is 8 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.

4.2.9  USER-URI

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

4.2.10  PRIORITY

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


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

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

5.1  FloorRequest

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


   FloorRequest =   (FIXED-HEADER)
                    (REQUEST-ID)
                  1*(FLOOR-ID)



Camarillo, et al.      Expires September 30, 2004              [Page 11]

Internet-Draft                    BFCP                        April 2004


                    (USER-ID)
                    (TOKEN)
                    [PRIORITY]
                    [USER-DISPLAY-NAME]
                    [USER-URI]
                    [HUMAN-READABLE-INFO]


5.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)
                    (REQUEST-ID)
                  1*(FLOOR-ID)
                    (USER-ID)
                    (TOKEN)


5.3  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 FloorRelease message:


   FloorRequestStatus =   (FIXED-HEADER)
                          (REQUEST-ID)
                        1*(FLOOR-ID)
                          (USER-ID)
                          (REQUEST-STATUS)


5.4  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)
                            (FLOOR-ID)
                         *( (REQUEST-ID)
                            (USER-ID)



Camarillo, et al.      Expires September 30, 2004              [Page 12]

Internet-Draft                    BFCP                        April 2004


                            [PRIORITY]
                            [USER-DISPLAY-NAME]
                            [USER-URI]
                            [HUMAN-READABLE-INFO]
                            (REQUEST-STATUS)      )


5.5  ChairAction

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


   ChairAction  =   (FIXED-HEADER)
                    (REQUEST-ID)
                    (USER-ID)
                    (TOKEN)
                    (FLOOR-ID)
                    (REQUEST-ID)
                    (USER-ID)
                    (REQUEST-STATUS)
                    [HUMAN-READABLE-INFO]


5.6  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)
                    (REQUEST-ID)
                    (USER-ID)
                    (TOKEN)


5.7  PingAck

   Clients and 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:


   PingAck      =   (FIXED-HEADER)
                    (REQUEST-ID)
                    (USER-ID)



Camarillo, et al.      Expires September 30, 2004              [Page 13]

Internet-Draft                    BFCP                        April 2004


                    [TOKEN]


5.8  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)
                          (REQUEST-ID)
                          (USER-ID)
                          (ERROR-CODE)
                          (HUMAN-READABLE-INFO)


6.  bfcp and bfcps URI Definitions

   The following is the ABNF [2] for the "bfcp" and "bfcps" URIs:


      bfcpURI           =  "bfcp://" server "/" conf-id [ uri-parameters ]
      bfcpsURI          =  "bfcps://" server "/" conf-id [ uri-parameters ]

      server            =  [ user "@" ] hostport
      user              =  user-id [ ":" token ]
      user-id           =  1*DIGIT
      token             =  1*DIGIT

      conf-id           =  1*DIGIT

      uri-parameters    =  *( "?" uri-parameter)
      uri-parameter     =  transport-param / other-param
      transport-param   =  "transport="
                           ( "tcp" / other-transport )
      other-transport   =  pvalue
      other-param       =  pname [ "=" pvalue ]
      pname             =  1*paramchar
      pvalue            =  1*paramchar
      paramchar         =  param-unreserved / unreserved / escaped
      param-unreserved  =  "[" / "]" / "/" / ":" / "&" / "+" / "$"
      unreserved        =  alphanum / mark
      alphanum          =  ALPHA / DIGIT
      mark              =  "-" / "_" / "." / "!" / "~" / "*" / "'"
                           / "(" / ")"
      escaped           =  "%" HEXDIG HEXDIG




Camarillo, et al.      Expires September 30, 2004              [Page 14]

Internet-Draft                    BFCP                        April 2004


   We import several definitions from RFC 2396 [4] and RFC 2732 [6], but
   we make them complatible with RFC 2234 [2]:


      hostport         =  host [ ":" port ]

      host             =  hostname / IPv4address / IPv6reference
      hostname         =  *( domainlabel "." ) toplabel [ "." ]
      domainlabel      =  alphanum
                          / alphanum *( alphanum / "-" ) alphanum
      toplabel         =  ALPHA / ALPHA *( alphanum / "-" ) alphanum
      IPv4address      =  1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
      IPv6reference    =  "[" IPv6address "]"
      IPv6address      =  hexpart [ ":" IPv4address ]
      hexpart          =  hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
      hexseq           =  hex4 *( ":" hex4)
      hex4             =  1*4HEXDIG

      port             =  1*DIGIT

   The following are examples of bfcp and bfcps URIs:


   bfcp://1234:472@server34.example.com/4321
   bfcp://5678:243@server45.example.com:20000/9876?transport=tcp
   bfcps://server57.example.com/5643


7.  Contacting a bfcp or bfcps URI

   A client contacting a bfcp or bfcps follows the rules described in
   the following sections.

7.1  Selecting a Transport Protocol

   XXX: Once we resolve Issue 3 in the tracker, we will edit this
   section.

   If the URI specifies a transport protocol in the transport parameter,
   that transport protocol SHOULD be used.

   Otherwise, if no transport protocol is specified, but the host part
   of the URI is a numeric IP address, the client SHOULD use TCP.
   Similarly, if no transport protocol is specified, the host part is
   not numeric, but an explicit port is provided, the client SHOULD use
   TCP.

   Otherwise, if no transport protocol or port is specified, and the



Camarillo, et al.      Expires September 30, 2004              [Page 15]

Internet-Draft                    BFCP                        April 2004


   host part of the URI is not a numeric IP address, the client SHOULD
   perform a NAPTR [9] query for the domain in the URI. The services
   relevant for the task of transport protocol selection are those with
   NAPTR service fields with values "BFCP+D2X" and "BFCPS+D2X", where X
   is a letter that corresponds to a transport protocol supported by the
   domain.  This specification defines D2T for TCP.

   These NAPTR records provide a mapping from a domain to the SRV [7]
   record for contacting a server with the specific transport protocol
   in the NAPTR services field.  The resource record will contain an
   empty regular expression and a replacement value, which is the SRV
   record for that particular transport protocol. If the server supports
   multiple transport protocols, there will be multiple NAPTR records,
   each with a different service value.

   A client resolving a BFCPS URI MUST discard any services that do not
   contain "BFCPS" as the protocol in the service field. On the other
   hand, a client resolving a BFCP URI SHOULD retain records with
   "BFCPS" as the protocol, if the client supports TLS.

   The client MUST discard any service fields that identify a resolution
   service whose value is not "D2X", for values of X that indicate
   transport protocols supported by the client.  The NAPTR processing as
   described in RFC 3403 [9] will result in the discovery of the most
   preferred transport protocol of the server that is supported by the
   client, as well as an SRV record for the server.

   If no NAPTR records are found, the client constructs SRV queries for
   those transport protocols it supports, and does a query for each.
   Queries are done using the service identifier "_bfcp" for bfcp URIs
   and "_bfcps" for bfcps URIs. If the client supports TLS and wishes to
   use it, it SHOULD also query using the service identifier "_bfcps",
   even when handling floor URIs. A particular transport is supported if
   the query is successful. The client MAY use any transport protocol it
   desires which is supported by the server.

   If no SRV records are found, the client SHOULD use TCP to contact the
   server.

7.2  Determining Port and IP Address

   Once the transport protocol has been determined, the next step is to
   determine the IP address and port.

   If the host part of the URI is a numeric IP address, the client uses
   that address. If the URI also contains a port, the client uses that
   port. If no port is specified, the client uses the default port for
   the particular transport protocol.



Camarillo, et al.      Expires September 30, 2004              [Page 16]

Internet-Draft                    BFCP                        April 2004


   If the host part of the URI was not a numeric IP address, but a port
   is present in the URI, the client performs an A or AAAA record lookup
   of the domain name.  The result will be a list of IP addresses, each
   of which can be contacted at the specific port from the URI and
   transport protocol determined previously. The client SHOULD try the
   first record.  If an attempt should fail, the next SHOULD be tried,
   and if that should fail, the next SHOULD be tried, and so on.

   If the host part of the URI was not a numeric IP address, and no port
   was present in the URI, the client performs an SRV query on the
   record returned from the NAPTR processing of Section 7.1, if such
   processing was performed. If it was not, because a transport was
   specified explicitly, the client performs an SRV query for that
   specific transport, using the service identifiers as described in
   Section 7.1. If the NAPTR processing was not done because no NAPTR
   records were found, but an SRV query for a supported transport
   protocol was successful, those SRV records are selected. Regardless
   of how the SRV records were determined, the procedures of RFC 2782
   [7], as described in the section titled "Usage rules" are followed.

   If no SRV records were found, the client performs an A or AAAA record
   lookup of the domain name. The result will be a list of IP addresses,
   each of which can be contacted using the transport protocol
   determined previously, at the default port for that transport.

7.3  Lower-Layer Security

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

   Servers and clients that implement TLS MUST support XXX: cypher and
   hash algorithm.

   If a client is contacting a BFCPS URI, the client MUST use TLS
   towards the server. If a client is contacting a BFCP URI, and the
   client wishes to use TLS, the client MAY use TLS towards the server.
   If the client is contacting a BFCP URI, and the client does not wish
   to use or does not support TLS, it SHOULD use a different security
   mechanism which SHOULD provide integrity and replay protection, and
   confidentiality.

7.4  Conference ID, User ID, and Token Values

   Once the client has determined the transport protocol to use, the IP
   address and port number of the server, and the security mechanism to
   use, the client SHOULD establish the transport and security



Camarillo, et al.      Expires September 30, 2004              [Page 17]

Internet-Draft                    BFCP                        April 2004


   connections needed to contact the server. At this point, the client
   is ready to send BFCP messages to the server.

   In order to do this, the client needs to fill a set of fields. In
   particular, the client needs to fill the Conference ID field in the
   FIXED-HEADER, and the User ID and Token fields in their respective
   TLVs.

   The conf-id of the BFCP or BFCPS URI contains the integer
   representation of the 32-bit Conference ID to be used in the
   FIXED-HEADER. If the conf-id contains an integer too large to be
   represented using 32 bits, the client MUST only use the least
   significant 32 bits of its representation.

   The values to be used in the USER-ID and TOKEN parameters may be
   obtained from the URI. If the URI does not contain these values, they
   are obtained by the client using a mechanism which is outside the
   scope of this document. Examples of such a mechanism are using the
   Conference Event Package [13] and using the SIP [8] Call-Info header
   field.

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

8.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 5.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 MUST set the Conference ID in the FIXED-HEADER of the
   FloorRequest to the Conference ID for the conference that the client
   obtained previously.

   The client MUST set the Request ID value in the REQUEST-ID TLV to a
   random number. The Request ID value is used by the client to match
   this floor request with the responses received from the floor control
   server. The Request ID value is also used by the server to match this
   floor request with eventual FloorRelease messages from the client
   cancelling the floor request. The client MUST NOT reuse the same
   Request ID value for new messages different than FloorRelease until
   the floor request is granted or denied or an Error message for this



Camarillo, et al.      Expires September 30, 2004              [Page 18]

Internet-Draft                    BFCP                        April 2004


   FloorRequest is received.

   If the client inserts more than one FLOOR-ID TLVs in the FloorRequest
   message, 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 USER-ID and the TOKEN TLVs in the FloorRequest message are used
   by the server to authenticate and authorize the request.

   The USER-DISPLAY-NAME and the USER-URI TLVs in the FloorRequest
   message, if present, provide extra information about the user
   requesting the floor.

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

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

8.1.1  Receiving Responses

   A message from the server is considered a response to the
   FloorRequest message by the client if the message from the server has
   the same Conference ID, Request ID, and User ID as the FloorRequest
   message.

   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.

   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.

8.2  Cancelling a Floor Request

   A client that wishes to cancel a pending floor request does so by
   sending a FloorRelease message to the floor control server. The ABNF
   in Section 5.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.



Camarillo, et al.      Expires September 30, 2004              [Page 19]

Internet-Draft                    BFCP                        April 2004


   The client MUST set the Conference ID in the FIXED-HEADER of the
   FloorRelease to the Conference ID for the conference that the client
   obtained previously.

      Note that the FloorRelease message is also used to release a floor
      or floors that were granted to the client. Using the same message
      for 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 MUST copy the REQUEST-ID, FLOOR-ID, USER-ID, and TOKEN
   TLVs from the FloorRequest message that the FloorRelease message is
   cancelling into the FloorRelease message.

8.2.1  Receiving Responses

   A message from the server is considered a response to the
   FloorRelease message by the client if the message from the server has
   the same Conference ID, Request ID, and User ID as the FloorRelease
   message.

   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 different from Cancelled, the
   FloorRelease message and the FloorRequestStatus crossed on the wire.
   The client does not need to resend the FloorRelease message, because
   the server will send a new FloorRequestStatus message with a Request
   Status value of Cancelled as soon as it receives the original
   FloorRelease message. The HUMAN-READABLE-INFO TLV, if present,
   provides extra information which the client MAY display to the user.

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

8.3  Releasing Floors

   A client that wishes to release one or more floors, which were
   granted to it before, does so by sending a FloorRelease message. The
   ABNF in Section 5.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 MUST set the Conference ID in the FIXED-HEADER of the
   FloorRelease to the Conference ID for the conference that the client
   obtained previously.

   The client MUST copy the REQUEST-ID, FLOOR-ID, USER-ID, and TOKEN



Camarillo, et al.      Expires September 30, 2004              [Page 20]

Internet-Draft                    BFCP                        April 2004


   TLVs from the FloorRequest message that resulted in the floor being
   granted into the FloorRelease message.

8.3.1  Receiving Responses

   A message from the server is considered a response to the
   FloorRelease message by the client if the message from the server has
   the same Conference ID, Request ID, and User ID as the FloorRelease
   message.

   If the response is a FloorRequestStatus message, the client obtains
   information about the status of the FloorRequest in a REQUEST-STATUS
   TLV. The server will send a FloorRequestStatus with a Request Status
   value of Released as soon as it receives the FloorRelease message.
   The HUMAN-READABLE-INFO TLV, if present, provides extra information
   which the client MAY display to the user.

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

8.4  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 5.6 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 MUST set the Conference ID in the FIXED-HEADER of the Ping
   to the Conference ID for the conference that the client obtained
   previously.

   The client MUST set the Request ID value of the REQUEST-ID TLV to a
   random number. The Request ID value is used by the client to match
   this ping request with the response received from the floor control
   server. The client MUST NOT reuse the same Request ID value for new
   messages until the client receives a PingAck or an Error message for
   this request.

   The server uses the values of the USER-ID and TOKEN TLVs in the Ping
   message to authenticate and authorize the message.

8.4.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, Request ID, and User ID as the Ping message.



Camarillo, et al.      Expires September 30, 2004              [Page 21]

Internet-Draft                    BFCP                        April 2004


   If the response is a PingAck message, the server is alive and the
   User ID and Token values sent by the client were acceptable.

   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.

8.5  Responding to a Ping Message

   The processing of a Ping message by a client involves generating a
   PingAck message. The PingAck message is constructed by copying the
   Conference ID, Request ID, and User ID values from the Ping message
   into the PingAck message. The PingAck message MUST also contain a
   TOKEN TLV.

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

9.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
   receive it in FloorStatus messages from the floor control server.

9.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 5.5
   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 client MUST set the Conference ID in the FIXED-HEADER of the
   ChairAction to the Conference ID for the conference that the client
   obtained previously.

   The client MUST set the Request ID value of the REQUEST-ID TLV to a
   random number. The Request ID value is used by the chair to match
   this ChairAction message with the responses received from the floor
   control server. The chair MUST NOT reuse the same Request ID value
   for new messages until the floor server has performed the
   instructions sent in the ChairAction message or until an Error
   response is received.



Camarillo, et al.      Expires September 30, 2004              [Page 22]

Internet-Draft                    BFCP                        April 2004


   The server uses the values of the USER-ID and TOKEN TLVs to
   authenticate and authorize the request.

   The chair MUST identify the floor the instructions in the message
   apply to using a FLOOR-ID TLV. Additionally, the chair MUST identify
   the floor request the instructions in the message apply to using a
   REQUEST-ID and a USER-ID TLVs.

   The chair MUST provide the new status of 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).

   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.

10.  Server Operations

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

   On reception of a message from a client, the floor control server
   MUST check whether or not the values of the Conference ID, User ID,
   and Token identify a valid user. If they do not, the floor server
   SHOULD send an Error message, as described in Section 10.6, with
   Error code 1 (Authentication Failed).

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

10.1  Reception of a FloorRequest Message

   The processing of a FloorRequest message by a server involves
   generating one or more FloorRequestStatus messages. 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, it SHOULD use a Request Status value of Pending.




Camarillo, et al.      Expires September 30, 2004              [Page 23]

Internet-Draft                    BFCP                        April 2004


   At any time, when the status of the floor request changes, the floor
   control server SHOULD send a FloorRequest message with the
   appropriate Request Status.

   On reception of a FloorRelease message, the server SHOULD send a
   FloorRequestStatus message with a Request Status value of Released,
   if the floor had been previously granted, or of Cancelled, if it had
   not.

   The server constructs the FloorRequestStatus messages by copying the
   Conference ID, Request ID, and User ID values from the FloorRequest
   message into the response message. The server MAY add a
   HUMAN-READABLE-INFO TLV to provide extra information to the user
   about its decision.

   The floor control server MAY use the PRIORITY TLV, if present in the
   FloorRequest, to give higher or lower priority to the floor request.

10.2  Checking the Liveness of a Client or Chair

   A server that wishes to check the liveness of a client does so by
   sending a Ping message to the client or chair. Such a Ping message
   makes the client return a PingAck message, which contains the
   client's or chair's User ID and Token. So, the server can use Ping
   messages to re-authenticate the client (e.g., a new token is sent to
   the client or chair out-of-band and the Ping message makes the client
   show the server that the client or chair received it).

   The ABNF in Section 5.6 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 server MUST set the Conference ID in the FIXED-HEADER of the Ping
   to the Conference ID for the conference that the client or chair is
   part of.

   The server MUST set the Request ID valie of the REQUEST-ID TLV to a
   random number. The Request ID value is used by the server to match
   this ping request with the response received from the client or
   chair. The server MUST NOT reuse the same Request ID value for new
   messages until the server receives a PingAck message for this
   request.

   The server MUST set the User ID value of the USER-ID TLV to the User
   ID of the destination client or chair.






Camarillo, et al.      Expires September 30, 2004              [Page 24]

Internet-Draft                    BFCP                        April 2004


10.2.1  Receiving a PingAck Message

   A PingAck message from the client is considered a response to the
   Ping message by the server if the PingAck message has the same
   Conference ID, Request ID, and User ID as the Ping message.

   The PingAck message sent by the client in response to the Ping
   message sent by the server will contain the client's User ID and
   Token. The server authenticates this message as any other message,
   which may involve returning an Error message if the authentication is
   not succesful.

10.3  Responding to a Ping Message

   The processing of a Ping message by a server involves generating a
   PingAck message. The PingAck message is constructed by copying the
   Conference ID, Request ID, and User ID values from the Ping message
   into the PingAck message.

10.4  Informing about the Status of a Floor

   Floor control servers send information to clients and chairs about
   the status of a floor by sending FloorStatus messages.

   The server MUST set the Conference ID in the FIXED-HEADER of the
   FloorStatus to the Conference ID for the conference that the client
   or chair is part of.

   The chair MUST identify the floor the FloorStatus message applies to
   using a FLOOR-ID TLV.

   The server MAY provide information about a number of floor requests
   in a single FloorStatus message. For each floor request, the server
   MUST include in the FloorStatus the request's REQUEST-ID, USER-ID,
   and REQUEST-STATUS, and MAY include its USER-DISPLAY-NAME, USER-URI,
   HUMAN-READABLE-INFO, and requested PRIORITY.

10.5  Receiving 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. If the new Status 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).




Camarillo, et al.      Expires September 30, 2004              [Page 25]

Internet-Draft                    BFCP                        April 2004


   If the floor control server cannot find a floor request that matches
   the request the operation in the ChairAction message applies to, the
   floor control server generates an Error message, as described in
   Section 10.6, with an Error code with a value of 3 (Floor Request
   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 10.6, with an Error code with a value of 4
   (Unauthorized Operation).

10.6  Error Message Generation

   Error messages are always sent in response to a previous message from
   the client. Servers construct Error messages by copying the
   Conference ID, Request ID, and User ID values from the client's
   message into the Error message.

   The ABNF in Section 5.8 describes the TLVs that a Error message can
   contain. In addition, the ABNF specifies which of these TLVs are
   mandatory, and which ones are optional.

11.  Security Considerations

   TBD.

12.  IANA Considerations

   TBD

12.1  bfcp and bfcps URI Schemes Registration

   This section registers the bfcp and bfcps URI schemes following the
   template given in RFC 2717 [5].

   URI scheme names: "bfcp" and "bfcps"

   URI scheme syntax: specified in Section 6 of RFC XXXX (substitute
   XXXX with the number of this RFC).

   Character encoding considerations: The "bfcp" and "bfcps" URIs
   support the UTF-8 encoding scheme.

   Intended use: common within floor control protocols.

   Applications and/or protocols which use these URI scheme: BFCP, which
   is specified in this document.




Camarillo, et al.      Expires September 30, 2004              [Page 26]

Internet-Draft                    BFCP                        April 2004


   Interoperability considerations: none known.

   Security considerations: the "bfcps" URI scheme indicates a
   requirement to use TLS to contact the floor control server.

   Relevant publications: RFC XXXX (substitute XXXX with the number of
   this RFC).

   Contact information: the IETF XCON Working group. In case the WG does
   no exist anymore, any person appointed by the IETF Transport Area
   Director(s).

   Registered-by: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>

   Change control: extensions, new parameters and new values to these
   URIs have to be documented in an RFC. The IETF XCON Working Group or,
   in case the WG does no exist anymore, any person appointed by the
   IETF Transport Area Director(s), will provide expert review and
   advise to the change control process.

13.  Acknowledgments

   The XCON WG chairs, Adam Roach and Alan Johnston, provided useful
   ideas for this document.

14.  References

14.1  Normative References

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

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

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

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

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

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




Camarillo, et al.      Expires September 30, 2004              [Page 27]

Internet-Draft                    BFCP                        April 2004


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

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

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

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

14.2  Informational References

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

   [12]  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.

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


Authors' Addresses

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com









Camarillo, et al.      Expires September 30, 2004              [Page 28]

Internet-Draft                    BFCP                        April 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 September 30, 2004              [Page 29]

Internet-Draft                    BFCP                        April 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 September 30, 2004              [Page 30]


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