draft-ietf-xcon-bfcp-02.txt   draft-ietf-xcon-bfcp-03.txt 
XCON Working Group G. Camarillo XCON Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: April 25, 2005 J. Ott Expires: July 1, 2005 J. Ott
Universitaet Bremen Universitaet Bremen
K. Drage K. Drage
Lucent Technologies Lucent Technologies
October 25, 2004 December 31, 2004
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-02.txt draft-ietf-xcon-bfcp-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2005. This Internet-Draft will expire on July 1, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
Abstract Abstract
Floor control is a means to manage joint or exclusive access to Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment. shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as Thereby, floor control complements other functions -- such as
skipping to change at page 2, line 19 skipping to change at page 2, line 19
servers. servers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Obtaining Information to Contact a Floor Control Server . 8 3.2 Obtaining Information to Contact a Floor Control Server . 8
3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 8 3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 8
3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 9 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 8
3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 9 3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 9
4. Overview of Operation . . . . . . . . . . . . . . . . . . . 10 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 9
4.1 Floor Participant to Floor Control Server Interface . . . 10 4.1 Floor Participant to Floor Control Server Interface . . . 10
4.2 Floor Chair to Floor Control Server Interface . . . . . . 13 4.2 Floor Chair to Floor Control Server Interface . . . . . . 13
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 14 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 14 5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 14
5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 16 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 15
5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17 5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17
5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 18 5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 18
5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18 5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18
5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 18 5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 18
5.2.7 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.7 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20 5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20
5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 21 5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 21
5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 23 5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 23
skipping to change at page 3, line 8 skipping to change at page 3, line 8
5.3.5 FloorInfoWanted . . . . . . . . . . . . . . . . . . . 26 5.3.5 FloorInfoWanted . . . . . . . . . . . . . . . . . . . 26
5.3.6 FloorInfo . . . . . . . . . . . . . . . . . . . . . . 27 5.3.6 FloorInfo . . . . . . . . . . . . . . . . . . . . . . 27
5.3.7 ChairAction . . . . . . . . . . . . . . . . . . . . . 27 5.3.7 ChairAction . . . . . . . . . . . . . . . . . . . . . 27
5.3.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . 28 5.3.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . 28
5.3.9 Hello . . . . . . . . . . . . . . . . . . . . . . . . 28 5.3.9 Hello . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.10 HelloAck . . . . . . . . . . . . . . . . . . . . . . 28 5.3.10 HelloAck . . . . . . . . . . . . . . . . . . . . . . 28
5.3.11 Error . . . . . . . . . . . . . . . . . . . . . . . 29 5.3.11 Error . . . . . . . . . . . . . . . . . . . . . . . 29
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 29 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 30 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 30
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 30 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 30
8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 30 8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 31
8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 30 8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 31
9. Authentication and Authorization . . . . . . . . . . . . . . 31 9. Authentication and Authorization . . . . . . . . . . . . . . 31
9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 31
9.2 Floor Control Server Behavior . . . . . . . . . . . . . . 32 9.2 Floor Control Server Behavior . . . . . . . . . . . . . . 32
10. Floor Participant Operations . . . . . . . . . . . . . . . . 32 10. Floor Participant Operations . . . . . . . . . . . . . . . . 33
10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 33 10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 33
10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 33 10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 33
10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 34 10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 34
10.2 Cancelling a Floor Request and Releasing a Floor . . . . 34 10.2 Cancelling a Floor Request and Releasing a Floor . . . . 35
10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 34 10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 35
10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 35 10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 36
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 35 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 36
11.1 Sending a ChairAction Message . . . . . . . . . . . . . 36 11.1 Sending a ChairAction Message . . . . . . . . . . . . . 36
11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 37 11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 37
12. General Client Operations . . . . . . . . . . . . . . . . . 37 12. General Client Operations . . . . . . . . . . . . . . . . . 38
12.1 Requesting Information about Floors . . . . . . . . . . 37 12.1 Requesting Information about Floors . . . . . . . . . . 38
12.1.1 Sending a FloorInfoWanted Message . . . . . . . . . 37 12.1.1 Sending a FloorInfoWanted Message . . . . . . . . . 38
12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 38 12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 38
12.2 Requesting Information about Floor Requests . . . . . . 38 12.2 Requesting Information about Floor Requests . . . . . . 39
12.2.1 Sending a FloorRequestInfoWanted Message . . . . . . 39 12.2.1 Sending a FloorRequestInfoWanted Message . . . . . . 40
12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 40 12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 40
12.3 Obtaining the Capabilities of a Floor Control Server . . 40 12.3 Obtaining the Capabilities of a Floor Control Server . . 41
12.3.1 Sending a Hello Message . . . . . . . . . . . . . . 40 12.3.1 Sending a Hello Message . . . . . . . . . . . . . . 41
12.3.2 Receiving Responses . . . . . . . . . . . . . . . . 40 12.3.2 Receiving Responses . . . . . . . . . . . . . . . . 41
13. Floor Control Server Operations . . . . . . . . . . . . . . 41 13. Floor Control Server Operations . . . . . . . . . . . . . . 41
13.1 Reception of a FloorRequest Message . . . . . . . . . . 41 13.1 Reception of a FloorRequest Message . . . . . . . . . . 42
13.1.1 Generating the First FloorRequestInfo Message . . . 42 13.1.1 Generating the First FloorRequestInfo Message . . . 42
13.1.2 Generation of Subsequent FloorRequestInfo Messages . 42 13.1.2 Generation of Subsequent FloorRequestInfo Messages . 43
13.2 Reception of a FloorRequestInfoWanted Message . . . . . 43 13.2 Reception of a FloorRequestInfoWanted Message . . . . . 44
13.2.1 Information on a Single Floor Request . . . . . . . 44 13.2.1 Information on a Single Floor Request . . . . . . . 44
13.2.2 Information on the Floor Requests Associated to a 13.2.2 Information on the Floor Requests Associated to a
Participant . . . . . . . . . . . . . . . . . . . . 44 Participant . . . . . . . . . . . . . . . . . . . . 45
13.3 Reception of a FloorRelease Message . . . . . . . . . . 45 13.3 Reception of a FloorRelease Message . . . . . . . . . . 45
13.4 Reception of a FloorInfoWanted Message . . . . . . . . . 45 13.4 Reception of a FloorInfoWanted Message . . . . . . . . . 46
13.4.1 Generation of the First FloorInfo Message . . . . . 46 13.4.1 Generation of the First FloorInfo Message . . . . . 47
13.4.2 Generation of Subsequent FloorInfo Messages . . . . 47 13.4.2 Generation of Subsequent FloorInfo Messages . . . . 47
13.5 Reception of a ChairAction Message . . . . . . . . . . . 47 13.5 Reception of a ChairAction Message . . . . . . . . . . . 48
13.6 Reception of a Hello Message . . . . . . . . . . . . . . 48 13.6 Reception of a Hello Message . . . . . . . . . . . . . . 49
13.7 Error Message Generation . . . . . . . . . . . . . . . . 48 13.7 Error Message Generation . . . . . . . . . . . . . . . . 49
14. Security Considerations . . . . . . . . . . . . . . . . . . 49 14. Security Considerations . . . . . . . . . . . . . . . . . . 49
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 51
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 49 15.1 Attribute Subregistry . . . . . . . . . . . . . . . . . 51
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 15.2 Primitive Subregistry . . . . . . . . . . . . . . . . . 51
17.1 Normative References . . . . . . . . . . . . . . . . . . . 49 15.3 Request Status Subregistry . . . . . . . . . . . . . . . 52
17.2 Informational References . . . . . . . . . . . . . . . . . 50 15.4 Error Code Subregistry . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . 52 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
17.1 Normative References . . . . . . . . . . . . . . . . . . . 54
17.2 Informational References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 57
1. Introduction 1. Introduction
Within a conference, some applications need to manage the access to a Within a conference, some applications need to manage the access to a
set of shared resources, such as the right to send media over a set of shared resources, such as the right to send media over a
particular media stream. Floor control enables such applications to particular media stream. Floor control enables such applications to
provide users with coordinated (shared or exclusive) access to these provide users with coordinated (shared or exclusive) access to these
resources. resources.
The Requirements for Floor Control Protocol [9] list a set of The Requirements for Floor Control Protocol [11] list a set of
requirements that need to be met by floor control protocols. The requirements that need to be met by floor control protocols. The
Binary Floor Control Protocol (BFCP), which is specified in this Binary Floor Control Protocol (BFCP), which is specified in this
document, meets these requirements. document, meets these requirements.
In addition, BFCP has been designed so that it can be used in
low-bandwidth environments. The binary encoding used by BFCP
achieves a small message size (when message signatures are not used)
that keeps the time it takes to transmit delay-sensitive BFCP
messages at minimum. Delay-sensitive BFCP messages include
FloorRequest, FloorRelease, FloorRequestInfo, and ChairAction. It is
expected that future extensions to these messages do not increase the
size of these messages in a significant way.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
defines the terminology used throughout this document and Section 3 defines the terminology used throughout this document and Section 3
discusses the scope of BFCP (i.e., which tasks fall within the scope discusses the scope of BFCP (i.e., which tasks fall within the scope
of BFCP and which ones are performed using different mechanisms). of BFCP and which ones are performed using different mechanisms).
Section 4 provides a non-normative overview of BFCP operation and Section 4 provides a non-normative overview of BFCP operation and
subsequent sections provide the normative specification of BFCP. subsequent sections provide the normative specification of BFCP.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [2] and indicate requirement levels for described in BCP 14, RFC 2119 [2] and indicate requirement levels for
compliant implementations. compliant implementations.
Media Participant: An entity that has access to the media resources Media Participant: An entity that has access to the media resources
of a conference (e.g., it can receive a media stream). In of a conference (e.g., it can receive a media stream). In
floor-controlled conferences, a given media participant is typically floor-controlled conferences, a given media participant is typically
co-located with a floor participant, but does not need to. co-located with a floor participant, but does not need to.
Third-party floor requests consist of having a floor participant Third-party floor requests consist of having a floor participant
request a floor for a media participant when they are not co-located. request a floor for a media participant when they are not colocated.
The protocol between a floor participant and a media participant
(that are not colocated) is outside the scope of this document.
Client: a floor participant or a floor chair that communicate with a Client: a floor participant or a floor chair that communicate with a
floor control server using BFCP. floor control server using BFCP.
Conference Policy: The complete set of rules for a particular Conference Policy: The complete set of rules for a particular
conference manipulated by the conference policy server. It includes conference. It includes the membership policy, the media policy, and
the membership policy and the media policy. There is an instance of policies related to floors and the use of floor control protocols.
conference policy for each conference. 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 Floor: A permission to temporarily access or manipulate a specific
shared resource or set of resources. shared resource or set of resources.
Floor Chair: A logical entity that manages one floor (grants, denies, Floor Chair: A logical entity that manages one floor (grants, denies,
or revokes a floor). An entity that assumes the logical role of a or revokes a floor). An entity that assumes the logical role of a
floor chair for a given transaction may assume a different role floor chair for a given transaction may assume a different role
(e.g., floor participant) for a different transaction. The roles of (e.g., floor participant) for a different transaction. The roles of
floor chair and floor participant are defined on a floor chair and floor participant are defined on a
transaction-by-transaction basis. transaction-by-transaction basis. BFCP transactions are defined in
Section 8.
Floor Control: A mechanism that enables applications or users to gain Floor Control: A mechanism that enables applications or users to gain
safe and mutually exclusive or non-exclusive input access to the safe and mutually exclusive or non-exclusive input access to the
shared object or resource. shared object or resource.
Floor Control Server: A logical entity that maintains the state of Floor Control Server: A logical entity that maintains the state of
the floor(s) including which floors exists, who the floor chairs are, the floor(s) including which floors exists, who the floor chairs are,
who holds a floor, etc. Requests to manipulate a floor are directed who holds a floor, etc. Requests to manipulate a floor are directed
at the floor control server. The floor control server of a at the floor control server. The floor control server of a
conference may perform other logical roles (e.g., floor participant) conference may perform other logical roles (e.g., floor participant)
in another conference. in another conference.
Floor Participant: A logical entity that requests floors, and Floor Participant: A logical entity that requests floors, and
possibly information about them, from a floor control server. An possibly information about them, from a floor control server. An
entity that assumes the logical role of a floor participant for a entity that assumes the logical role of a floor participant for a
given transaction may assume a different role (e.g., a floor chair) given transaction may assume a different role (e.g., a floor chair)
for a different transaction. The roles of floor participant and for a different transaction. The roles of floor participant and
floor chair are defined on a transaction-by-transaction basis. In floor chair are defined on a transaction-by-transaction basis. BFCP
floor-controlled conferences, a given floor participant is typically transactions are defined in Section 8. In floor-controlled
co-located with a media participant, but does not need to. conferences, a given floor participant is typically co-located with a
Third-party floor requests consist of having a floor participant media participant, but does not need to. Third-party floor requests
request a floor for a media participant when they are not co-located. consist of having a floor participant request a floor for a media
participant when they are not co-located.
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
conference participants receive media from which other participants,
and the ways in which that media is combined for each conference
participant. In the case of audio, these rules can include the
relative volumes at which each conference 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.
Participant: An entity that acts as a floor participant, as a media Participant: An entity that acts as a floor participant, as a media
participant, or as both. participant, or as both.
3. Scope 3. Scope
As stated earlier, the BFCP is a protocol to coordinate access to As stated earlier, BFCP is a protocol to coordinate access to shared
shared resources in a conference following the requirements defined resources in a conference following the requirements defined in [11].
in [9]. Floor control complements other functions defined in the Floor control complements other functions defined in the conferencing
conferencing framework [14], such as conference policy and media framework [12]. In particular, it is the conference policy that
policy. In particular, it is the conference policy that defines defines which media streams and applications are floor-controlled,
which media streams and applications are floor-controlled, who is/are who is/are the respective floor chair(s), and how access to the floor
the respective floor chair(s), and how access to the floor is is managed. Furthermore, it is up to the media policy to define
managed. Furthermore, it is up to the media policy to define which which (if any) impact on media stream handling (e.g. switching or
(if any) impact on media stream handling (e.g. switching or mixing) mixing) assignment of a floor to a media participant has.
assignment of a floor to a media participant has.
The floor control protocol BFCP defined in this document only The floor control protocol BFCP defined in this document only
specifies a means to arbitrate access to floors. The rules and specifies a means to arbitrate access to floors. The rules and
constraints for floor arbitration and the results of floor constraints for floor arbitration and the results of floor
assignments are outside the scope of this document and defined by the assignments are outside the scope of this document and defined by
conference and media policy, respectively. other protocols [13].
Figure 1 shows the tasks that BFCP can perform. Figure 1 shows the tasks that BFCP can perform.
+---------+ +---------+
| Floor | | Floor |
| Chair | | Chair |
| | | |
+---------+ +---------+
^ | ^ |
| | | |
skipping to change at page 8, line 14 skipping to change at page 8, line 12
Even though tasks that do not belong to the previous list are outside 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 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 control and are essential to create floors and to establish BFCP
connections between different entities. In the following connections between different entities. In the following
subsections, we discuss some of these tasks and mechanisms to perform subsections, we discuss some of these tasks and mechanisms to perform
them. them.
3.1 Floor Creation 3.1 Floor Creation
The conference policy for a particular conference contains the floors The association of a given floor with a resource or a set of
of the conference and the resource or resources associated with each resources (e.g., media streams) is out of the scope of BFCP as
floor. For example, a conference may have two floors: one described in [13]. The conference policy for a particular conference
controlling who can talk at a particular time and another controlling contains the floors of the conference and the resource or resources
who can write on a shared whiteboard. associated with each floor. For example, a conference may have two
floors: one controlling who can talk at a particular time and another
According to the definitions in Section 2, the conference policy is controlling who can write on a shared whiteboard.
manipulated using a Conference Policy Control Protocol (CPCP), such
as the one defined in [10]. 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 Floor creation and termination are also outside the scope of BFCP and
changes on the conference policy (e.g., when a new floor is created). are aspects of the conference policy as well. Consequently, the
The floor control may use a mechanism such as the one defined in [13] floor control server needs to stay up to date on changes on the
to keep itself up to date. conference policy (e.g., when a new floor is created).
3.2 Obtaining Information to Contact a Floor Control Server 3.2 Obtaining Information to Contact a Floor Control Server
A client needs a set of data in order to establish a BFCP connection A client needs a set of data in order to establish a BFCP connection
to a floor control server. These data include the transport address to a floor control server. These data include the transport address
of the server, the conference identifier, and the user identifier. of the server, the conference identifier, and the user identifier.
Clients can obtain this information in different ways. Two Clients can obtain this information in different ways. One is to use
possibilities are using CPCP and using an offer/answer [8] exchange. an offer/answer [10] exchange. How to use an SDP [8] offer/answer
How to use an SDP [6] offer/answer [8] exchange to obtain this [10] exchange to obtain this information is described in [14].
information is described in [15].
3.3 Generating a Shared Secret 3.3 Generating a Shared Secret
Authentication in BFCP is based on a shared secret between the client Authentication in BFCP is based on a shared secret between the client
and the floor control server. So, there is a need for a mechanism to and the floor control server. So, there is a need for a mechanism to
generate such a shared secret. generate such a shared secret. However, such mechanism is outside
the scope of BFCP.
When the floor participant or the floor chair obtains the information
needed to contact the BFCP floor control server over a secure channel
(e.g., an offer/answer [8] exchange using SIP [7] protected using S/
MIME), they can get the shared secret using the same channel.
If there is no secure channel available, a different mechanism needs
to be used. For example, MIKEY [12] allows an offerer and an
answerer to perform a Diffie-Hellman key exchange.
Shared secrets can also be generated and exchanged using out-of-band Shared secrets can also be generated and exchanged using out-of-band
means. means. For example, when the floor participant or the floor chair
obtains the information needed to contact the BFCP floor control
server over a secure channel (e.g., an offer/answer [10] exchange
using SIP [9] protected using S/MIME), they can get the shared secret
using the same channel.
3.4 Obtaining Floor-Resource Associations 3.4 Obtaining Floor-Resource Associations
Floors are associated with resources. For example, a floor that Floors are associated with resources. For example, a floor that
controls who talks at a given time has a particular audio stream as controls who talks at a given time has a particular audio stream as
its associated resource. Associations between floors and resources its associated resource. Associations between floors and resources
are part of the conference policy, which is manipulated using CPCP. are part of the conference policy.
Floor participants and floor chairs need to know which resources are Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information using associated with which floors. They can obtain this information using
different mechanisms, such as CPCP or an offer/answer [8] exchange. different mechanisms, such as an offer/answer [10] exchange. How to
How to use an offer/answer exchange to obtain these associations is use an offer/answer exchange to obtain these associations is
described in [15]. described in [14].
Note that floor participants perform offer/answer exchanges with Note that floor participants perform offer/answer exchanges with
the SIP focus of the conference. So, the SIP focus needs to the SIP focus of the conference. So, the SIP focus needs to
obtain information about associations between floors and resources obtain information about associations between floors and resources
using a mechanism such as CPCP in order to be able to provide this in order to be able to provide this information to a floor
information to a floor participant in an offer/answer exchange. participant in an offer/answer exchange.
3.5 Policy Enforcement 3.5 Policy Enforcement
A participant whose floor request is granted has the right to use (in A participant whose floor request is granted has the right to use (in
a certain way) the resource or resources associated with the floor a certain way) the resource or resources associated with the floor
that was requested. For example, the participant may have the right that was requested. For example, the participant may have the right
to send media over a particular audio stream. to send media over a particular audio stream.
Nevertheless, holding a floor does not imply that others will not be 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 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 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 Section 2, the conference policy determines which media participants
determines which media participants can actually use the resources in can actually use the resources in the conference.
the conference.
So, if the policy of a conference is to enforce floor control So, if the policy of a conference is to enforce floor control
decisions, every change in the status of any floor needs to be decisions, every change in the status of any floor needs to be
reflected in the media policy of the conference. For example, the reflected in the conference policy of the conference. For example,
mixer only accepts media from the user who holds the floor. the mixer only accepts media from the user who holds the floor.
A way to reflect the status of the floors in the media policy is to
have the floor control server manipulate the media policy using CPCP.
Nevertheless, there are other ways to enforce floor control policies,
such as having a floor control chair manipulate the media policy
(using CPCP) only if there are misbehaving users trying to use a
resource without holding its associated floor.
4. Overview of Operation 4. Overview of Operation
This section provides a non-normative description of BFCP operations. This section provides a non-normative description of BFCP operations.
Section 4.1 describes the interface between floor participants and Section 4.1 describes the interface between floor participants and
floor control servers and Section 4.2 describes the interface between floor control servers and Section 4.2 describes the interface between
floor chairs and floor control servers floor chairs and floor control servers
BFCP messages, which use a TLV (Type-Length-Value) binary encoding, BFCP messages, which use a TLV (Type-Length-Value) binary encoding,
consist of a common header followed by a set of TLVs. The common consist of a common header followed by a set of TLVs. The common
skipping to change at page 19, line 18 skipping to change at page 19, line 18
|0 0 0 0 1 0 1|M| Length | | |0 0 0 0 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: HUMAN-READABLE-INFO format Figure 12: HUMAN-READABLE-INFO format
Text: this field contains UTF-8 [5] encoded text. Text: this field contains UTF-8 [7] encoded text.
In some situations, the contents of the Text field may be generated In some situations, the contents of the Text field may be generated
by an automaton. If such automaton has information about the by an automaton. If such automaton has information about the
preferred language of the receiver of a particular preferred language of the receiver of a particular
HUMAN-READABLE-INFO TLV, it MAY use this language to generate the HUMAN-READABLE-INFO TLV, it MAY use this language to generate the
Text field. Text field.
Padding: one, two, or three bytes of padding added so that the Padding: one, two, or three bytes of padding added so that the
contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned. 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 Padding bits SHOULD be set to zero by the sender and MUST be ignored
skipping to change at page 29, line 36 skipping to change at page 29, line 36
Figure 30: Error format Figure 30: Error format
6. Transport 6. Transport
BFCP entities exchange BFCP messages using TCP connections. TCP BFCP entities exchange BFCP messages using TCP connections. TCP
provides an in-order reliable delivery of a stream of bytes. provides an in-order reliable delivery of a stream of bytes.
Consequently, message framing is implemented in the application Consequently, message framing is implemented in the application
layer. BFCP implements application-layer framing using TLVs. layer. BFCP implements application-layer framing using TLVs.
A client MUST NOT use more than one TCP connection to communicate
with a given floor control server within a conference. Nevertheless,
if the same physical box handles different clients (e.g., a floor
chair and a floor participant), which are identified by different
User IDs, a separate connection per client is allowed.
If a BFCP entity (a client or a floor control server) receives data
from TCP that cannot be parsed the entity MUST close the TCP
connection using a RESET call (send a TCP RST bit) and the connection
SHOULD be reestablished. Similarly, if a TCP connection cannot
deliver a BFCP message and times out, the TCP connection SHOULD be
reestablished.
The way connection reestablishment is handled depends on how the
client obtains information to contact the floor control server (e.g.,
using an offer/answer exchange [14]). Once the TCP connection is
reestablished, the client MAY resend those message it did not get a
response for from the floor control server.
If a floor control server detects that the TCP connection towards one If a floor control server detects that the TCP connection towards one
of the floor participants is lost, it is up to the local policy of of the floor participants is lost, it is up to the local policy of
the floor control server what to do with the pending floor requests the floor control server what to do with the pending floor requests
of the floor participant. The floor control server MAY cancel all of the floor participant. In any case, it is RECOMMENDED that the
the floor participant's floor requests or it MAY keep them while the floor control server keeps the floor requests (i.e., does not cancel
TCP connection is re-established. Connection re-establishment is them) while the TCP connection is reestablished.
handled in different ways depending on how the client obtains
information to contact the floor control server (as described in If a client wishes to end its BFCP connection with a floor control
Section 3.2, two possibilities are CPCP and an offer/answer server, the client closes (i.e., a graceful close) the TCP connection
exchange). towards the floor control server. If a floor control server wishes
to end its BFCP connection with a client (e.g., the focus of the
conference informs the floor control server that the client has been
kicked out from the conference), the floor control server closes
(i.e., a graceful close) the TCP connection towards the client.
7. Lower-Layer Security 7. Lower-Layer Security
BFCP relies on lower-layer security mechanisms to provide replay and BFCP relies on lower-layer security mechanisms to provide replay and
integrity protection, and confidentiality. BFCP floor control integrity protection, and confidentiality. BFCP floor control
servers MUST support TLS [4], and BFCP clients (which include both servers MUST support TLS [4], and BFCP clients (which include both
floor participants and floor chairs) SHOULD support TLS. Any BFCP floor participants and floor chairs) SHOULD support TLS. Any BFCP
entity MAY support other security mechanisms. entity MAY support other security mechanisms.
BFCP entities that implement TLS MUST support, at a minimum, the TLS BFCP entities that implement TLS MUST support, at a minimum, the TLS
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite . TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].
8. Protocol Transactions 8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated In BFCP, there are two types of transactions: client-initiated
transactions and server-initiated transactions (notifications). transactions and server-initiated transactions (notifications).
Client-initiated transactions consist of a request from a client to a Client-initiated transactions consist of a request from a client to a
floor control server and a response from the floor control server to floor control server and a response from the floor control server to
the client. The request carries a TRANSACTION-ID TLV which the floor the client. The request carries a TRANSACTION-ID TLV which the floor
control server copies into the response. Clients use Transaction ID control server copies into the response. Clients use Transaction ID
values to match responses with previously-issued requests. values to match responses with previously-issued requests.
skipping to change at page 31, line 30 skipping to change at page 31, line 50
control server's certificate when the TLS connection is established control server's certificate when the TLS connection is established
between them. between them.
To achieve client authentication, a client needs to prove to the To achieve client authentication, a client needs to prove to the
floor control server that the client can produce a DIGEST TLV for a floor control server that the client can produce a DIGEST TLV for a
message using their shared secret and that the message is fresh (to message using their shared secret and that the message is fresh (to
avoid replay attacks). Clients prove the freshness of a message by avoid replay attacks). Clients prove the freshness of a message by
including a NONCE TLV in the message. The NONCE TLV is the second to including a NONCE TLV in the message. The NONCE TLV is the second to
last TLV in the message (the last one is the DIGEST TLV). last TLV in the message (the last one is the DIGEST TLV).
The nonce in the NONCE TLV is provided by the floor control server The nonce to be places in the NONCE TLV by the client is typically
using an out-of-band mechanism (e.g., using an offer/answer exchange provided by the floor control server in an Error response --
as described in [15]), or in an Error response -- typically with typically with Error Code 7 (DIGEST TLV Required) or 6 (Invalid
Error Code 7 (DIGEST TLV Required) or 6 (Invalid Nonce). Nonce). Additionally, as an optimization, the floor control server
can provide a client with a NONCE to be used in the first message
generated by the client using an out-of-band mechanism (e.g., using
an offer/answer exchange as described in [14]). This way, the client
does not need to generate an initial BFCP message only to have it
rejected by the floor control server with an Error response
containing a nonce.
A client that obtains a nonce out-of-band SHOULD add a NONCE TLV and A client that obtains a nonce out-of-band SHOULD add a NONCE TLV and
a DIGEST TLV to the first message it sends to the floor control a DIGEST TLV to the first message it sends to the floor control
server. Furthermore, if a client generates a message without this server. Furthermore, if any client generates a message without a
TLV and receives an Error response with Error Code 7 (DIGEST TLV DIGEST TLV and receives an Error response with Error Code 7 (DIGEST
Required), the client SHOULD re-send the message with a DIGEST TLV TLV Required), the client SHOULD re-send the message with a DIGEST
and a NONCE TLV with the nonce received in the Error response. TLV and a NONCE TLV with the nonce received in the Error response.
If after sending a message with a DIGEST TLV, a client receives an If after sending a message with a DIGEST TLV, a client receives an
Error response with Error Code 6 (Invalid Nonce), the client SHOULD Error response with Error Code 6 (Invalid Nonce), the client SHOULD
re-send the message using the new nonce received in the Error re-send the message using the new nonce received in the Error
response. If the Error Code is 1 (Authentication Failed) instead, response. If the Error Code is 1 (Authentication Failed) instead,
the client MUST NOT send further messages to the floor control server the client MUST NOT send further messages to the floor control server
until it has obtained a different (hopefully valid) shared secret until it has obtained a different (hopefully valid) shared secret
than the one used in the original message. than the one used in the original message.
If a client receives a nonce in a message from the floor control If a client receives a nonce in a message from the floor control
skipping to change at page 43, line 14 skipping to change at page 43, line 41
messages. messages.
When the status of the floor request changes, the floor control floor When the status of the floor request changes, the floor control floor
control server SHOULD send new FloorRequestInfo messages with the control server SHOULD send new FloorRequestInfo messages with the
appropriate Request Status. These FloorRequestInfo messages MUST appropriate Request Status. These FloorRequestInfo messages MUST
contain a FLOOR-REQUEST-ID TLV equal to the one sent in the first contain a FLOOR-REQUEST-ID TLV equal to the one sent in the first
FloorRequestInfo message, but MUST NOT contain any TRANSACTION-ID FloorRequestInfo message, but MUST NOT contain any TRANSACTION-ID
TLV. (The Floor Request ID identifies the floor request the TLV. (The Floor Request ID identifies the floor request the
FloorRequestInfo applies to.) FloorRequestInfo applies to.)
The FIXED-HEADER and the rest of the TLVs (expect for the The FIXED-HEADER and the rest of the TLVs (except for the
HUMAN-READABLE-INFO TLV) are the same as in the first HUMAN-READABLE-INFO TLV) are the same as in the first
FloorRequestInfo message. FloorRequestInfo message.
The rate at which the floor control server sends FloorRequestInfo The rate at which the floor control server sends FloorRequestInfo
messages is a matter of local policy. A floor control server may messages is a matter of local policy. A floor control server may
choose to send a new FloorRequestInfo message every time the floor choose to send a new FloorRequestInfo message every time the floor
request moves in the floor request queue while another may choose request moves in the floor request queue while another may choose
to only send a new FloorRequestInfo message when the floor request to only send a new FloorRequestInfo message when the floor request
is Granted or Denied. is Granted or Denied.
skipping to change at page 44, line 17 skipping to change at page 44, line 45
The floor control server copies the Conference ID, the The floor control server copies the Conference ID, the
TRANSACTION-ID, and the USER-ID TLVs from the FloorRequestInfoWanted TRANSACTION-ID, and the USER-ID TLVs from the FloorRequestInfoWanted
message into the FloorRequestInfo message, as described in Section message into the FloorRequestInfo message, as described in Section
8.2. 8.2.
13.2.1 Information on a Single Floor Request 13.2.1 Information on a Single Floor Request
If the FloorRequestInfoWanted message carries a FLOOR-REQUEST-ID, the If the FloorRequestInfoWanted message carries a FLOOR-REQUEST-ID, the
sender of the message is requesting information about the floor sender of the message is requesting information about the floor
request identified by the FLOOR-REQUEST-ID TLV. The floor control request identified by the FLOOR-REQUEST-ID TLV. The floor control
servre copies the FLOOR-REQUEST-ID TLV from the server copies the FLOOR-REQUEST-ID TLV from the
FloorRequestInfoWanted message into the FloorRequestInfo message. FloorRequestInfoWanted message into the FloorRequestInfo message.
The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo
message identifying the floors being requested (i.e., the floors message identifying the floors being requested (i.e., the floors
associated with the floor request identified by the FLOOR-REQUEST-ID associated with the floor request identified by the FLOOR-REQUEST-ID
TLV). TLV).
The floor control server may also add a PRIORITY TLV with the The floor control server may also add a PRIORITY TLV with the
Priority value requested for the floor request and a Priority value requested for the floor request and a
HUMAN-READABLE-INFO TLV with extra information about the floor HUMAN-READABLE-INFO TLV with extra information about the floor
skipping to change at page 46, line 17 skipping to change at page 46, line 45
response following the procedures described in Section 13.7 response following the procedures described in Section 13.7
A floor control server receiving a FloorInfoWanted message from a A floor control server receiving a FloorInfoWanted message from a
client SHOULD keep this client informed about the status of the client SHOULD keep this client informed about the status of the
floors identified by FLOOR-ID TLVs in the FloorInfoWanted message. floors identified by FLOOR-ID TLVs in the FloorInfoWanted message.
Floor Control Servers keep clients informed by using FloorInfo Floor Control Servers keep clients informed by using FloorInfo
messages. messages.
An individual FloorInfo message carries information about a single An individual FloorInfo message carries information about a single
floor. So, when a FloorInfoWanted message requests information about floor. So, when a FloorInfoWanted message requests information about
more than one floors, the floor control server needs to send separate more than one floor, the floor control server needs to send separate
FloorInfo messages for different floors. FloorInfo messages for different floors.
The information FloorInfoWanted messages carry may depend on the user The information FloorInfoWanted messages carry may depend on the user
requesting the information. For example, a chair may be able to requesting the information. For example, a chair may be able to
receive information about pending requests while a regular user may receive information about pending requests while a regular user may
not be authorized to do so. not be authorized to do so.
13.4.1 Generation of the First FloorInfo Message 13.4.1 Generation of the First FloorInfo Message
The successful processing of a FloorInfoWanted message by a floor The successful processing of a FloorInfoWanted message by a floor
skipping to change at page 48, line 25 skipping to change at page 48, line 51
responsible for one of the floors instructs the floor control server responsible for one of the floors instructs the floor control server
to grant the floor, the floor control server will not grant it until to grant the floor, the floor control server will not grant it until
the chairs responsible for the other floors agree to grant them as the chairs responsible for the other floors agree to grant them as
well. well.
So, the floor control server is ultimately responsible to keep a So, the floor control server is ultimately responsible to keep a
coherent floor state using instructions from floor chairs as input to coherent floor state using instructions from floor chairs as input to
this state. this state.
If the new Status in the ChairAction message is Accepted and all the If the new Status in the ChairAction message is Accepted and all the
bits of the Queue Position field are zero, the floor participant is bits of the Queue Position field are zero, the floor chair is
requesting the floor control server to assign a queue position (e.g., requesting the floor control server to assign a queue position (e.g.,
the last in the queue) to the floor request based on the local policy the last in the queue) to the floor request based on the local policy
of the floor control server. (Of course, such as request only of the floor control server. (Of course, such a request only applies
applies in case the floor control server implements a queue.) in case the floor control server implements a queue.)
13.6 Reception of a Hello Message 13.6 Reception of a Hello Message
On reception of a Hello message, the floor control server follows the On reception of a Hello message, the floor control server follows the
rules in Section 9.2 which relate to client authentication. If while rules in Section 9.2 which relate to client authentication. If while
processing the Hello message, the floor control server encounters an processing the Hello message, the floor control server encounters an
error, it SHOULD generate an Error response following the procedures error, it SHOULD generate an Error response following the procedures
described in Section 13.7 described in Section 13.7
The successful processing of a Hello message by a floor control The successful processing of a Hello message by a floor control
skipping to change at page 49, line 19 skipping to change at page 49, line 45
TRANSACTION-ID, and the USER-ID TLVs from the message from the client TRANSACTION-ID, and the USER-ID TLVs from the message from the client
into the Error message, as described in Section 8.2. into the Error message, as described in Section 8.2.
The floor control server adds an ERROR-CODE TLV to the Error message. The floor control server adds an ERROR-CODE TLV to the Error message.
The ERROR-CODE TLV contains an Error Code from Table 4. The ERROR-CODE TLV contains an Error Code from Table 4.
Additionally, the floor control server may add a HUMAN-READABLE-INFO Additionally, the floor control server may add a HUMAN-READABLE-INFO
TLV with extra information about the error. TLV with extra information about the error.
14. Security Considerations 14. Security Considerations
TBD. BFCP uses message signatures to provide client authentication and TLS
to provide floor control server authentication, replay and integrity
protection, and confidentiality. It is RECOMMENDED that TLS with
non-null encryption is always used and that the first message from a
client over a given TLS connection is signed using the DIGEST TLV.
In any case, clients and floor control servers MAY use other security
mechanisms as long as they provide similar security properties.
The remainder of this Section analyzes some of the threats against
BFCP and how they are addressed.
An attacker may attempt to impersonate a client (a floor participant
or a floor chair) in order to generate forged floor requests or to
grant or deny existing floor requests. Client impersonation is
avoided by having clients sign their messages. A nonce is included
in the signature to ensure the freshness of the message. If the
client is using a TLS connection to communicate with the floor
control server, it is enough that the client signs its first message
over the TLS connection. The floor control server assumes that
attackers cannot hickjack the TLS connection and, therefore, that
subsequent messages over the TLS connection come from the client that
was initially authenticated.
An attacker may attempt to impersonate a floor control server. A
successful attacker would be able to make clients think that they
hold a particular floor so that they would try to access a resource
(e.g., sending media) without having legitimate rights to access it.
Floor control server impersonation is avoided by having floor control
servers present their server certificates at TLS connection
establishment time.
Attackers may attempt to modify messages exchanged by a client and a
floor control server. The integrity protection provided by TLS
connections prevents this attack.
An attacker may attempt to fetch a valid message sent by a client to
a floor control server and replay it at a later point. If the
attacker attempts to replay it over the TLS connection between the
client and the floor control server, TLS mechanisms discard it at the
receiver side. Still, if the message was signed, the attacker may
attempt to establish a new TLS connection with the floor control
server and replay the message over the new connection. Using TLS
confidentiality prevents this attack because the attacker cannot
access the contents of the message in the first place. Additionally,
if the attacker attempts to replay the encrypted message over the new
connection, TLS mechanisms would discard it at the receiver side.
Therefore, it is strongly RECOMMENDED that TLS is used with a
non-null encryption algorithm.
Attackers may attempt to pick messages from the network to get access
to confidential information between the floor control server and a
client (e.g., why a floor request was denied). TLS confidentiality
prevents this attack.
15. IANA Considerations 15. IANA Considerations
TBD This document instructs the IANA to create a new registry for BFCP
parameters called "Binary Floor Control Protocol (BFCP) Parameters".
This new registry has a number of subregistries, which are described
in the following Sections
15.1 Attribute Subregistry
This Section establishes the Attribute subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [5], the
registration policy for BFCP attributes shall be "Specification
Required". For the purposes of this subregistry, the BFCP attributes
for which IANA registration is requested MUST be defined by a
standards-track RFC. Such RFC MUST specify the attribute's type,
name, format, and semantics.
For each BFCP attribute, the IANA registers its type, its name, and
the reference to the RFC where the attribute is defined. The
following table contains the initial values of this subregistry.
+------+---------------------+------------+
| Type | Attribute | Reference |
+------+---------------------+------------+
| 0 | FLOOR-ID | [RFC XXXX] |
| 1 | USER-ID | [RFC XXXX] |
| 2 | BENEFICIARY-ID | [RFC XXXX] |
| 3 | TRANSACTION-ID | [RFC XXXX] |
| 4 | FLOOR-REQUEST-ID | [RFC XXXX] |
| 5 | HUMAN-READABLE-INFO | [RFC XXXX] |
| 6 | DIGEST | [RFC XXXX] |
| 7 | REQUEST-STATUS | [RFC XXXX] |
| 8 | ERROR-CODE | [RFC XXXX] |
| 9 | USER-DISPLAY-NAME | [RFC XXXX] |
| 10 | USER-URI | [RFC XXXX] |
| 11 | PRIORITY | [RFC XXXX] |
| 12 | NONCE | [RFC XXXX] |
| 13 | SUPPORTED-TLVS | [RFC XXXX] |
+------+---------------------+------------+
Table 5: Initial values of the BFCP Attribute subregistry
15.2 Primitive Subregistry
This Section establishes the Primitive subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [5], the
registration policy for BFCP primitives shall be "Specification
Required". For the purposes of this subregistry, the BFCP primitives
for which IANA registration is requested MUST be defined by a
standards-track RFC. Such RFC MUST specify the primitive's value,
name, format, and semantics.
For each BFCP primitive, the IANA registers its value, its name, and
the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry.
+-------+------------------------+------------+
| Value | Primitive | Reference |
+-------+------------------------+------------+
| 0 | FloorRequest | [RFC XXXX] |
| 1 | FloorRelease | [RFC XXXX] |
| 2 | FloorRequestInfoWanted | [RFC XXXX] |
| 3 | FloorRequestInfo | [RFC XXXX] |
| 4 | FloorInfoWanted | [RFC XXXX] |
| 5 | FloorInfo | [RFC XXXX] |
| 6 | ChairAction | [RFC XXXX] |
| 7 | ChairActionAck | [RFC XXXX] |
| 8 | Hello | [RFC XXXX] |
| 9 | HelloAck | [RFC XXXX] |
| 10 | Error | [RFC XXXX] |
+-------+------------------------+------------+
Table 6: Initial values of the BFCP primitive subregistry
15.3 Request Status Subregistry
This Section establishes the Request Status subregistry under the
BFCP Parameters registry. As per the terminology in RFC 2434 [5],
the registration policy for BFCP request status shall be
"Specification Required". For the purposes of this subregistry, the
BFCP request status for which IANA registration is requested MUST be
defined by a standards-track RFC. Such RFC MUST specify the value
and the semantics of the request status.
For each BFCP request status, the IANA registers its value, its
meaning, and the reference to the RFC where the request status is
defined. The following table contains the initial values of this
subregistry.
+-------+-----------+------------+
| Value | Status | Reference |
+-------+-----------+------------+
| 0 | Pending | [RFC XXXX] |
| 1 | Accepted | [RFC XXXX] |
| 2 | Granted | [RFC XXXX] |
| 3 | Denied | [RFC XXXX] |
| 4 | Cancelled | [RFC XXXX] |
| 5 | Released | [RFC XXXX] |
| 6 | Revoked | [RFC XXXX] |
+-------+-----------+------------+
Table 7: Initial values of the Request Status subregistry
15.4 Error Code Subregistry
This Section establishes the Error Code subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [5], the
registration policy for BFCP error codes shall be "Specification
Required". For the purposes of this subregistry, the BFCP error
codes for which IANA registration is requested MUST be defined by a
standards-track RFC. Such RFC MUST specify the value and the
semantics of the error code, and any Error Specific Details that
apply to it.
For each BFCP primitive, the IANA registers its value, its meaning,
and the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry.
+----------------------+----------------------+---------------------+
| Value | Meaning | Reference |
+----------------------+----------------------+---------------------+
| 0 | Conference does not | [RFC XXXX] |
| | Exist | |
| 1 | Authentication | [RFC XXXX] |
| | Failed | |
| 2 | Unknown Mandatory | [RFC XXXX] |
| | TLV | |
| 3 | Floor Request ID | [RFC XXXX] |
| | Does Not Exist | |
| 4 | Unauthorized | [RFC XXXX] |
| | Operation | |
| 5 | User does not Exist | [RFC XXXX] |
| 6 | Invalid Nonce | [RFC XXXX] |
| 7 | DIGEST TLV Required | [RFC XXXX] |
| 8 | Invalid Floor ID | [RFC XXXX] |
| 9 | You have Already | [RFC XXXX] |
| | Reached the Maximum | |
| | Number of Ongoing | |
| | Floor Requests for | |
| | this Floor | |
+----------------------+----------------------+---------------------+
Table 8: Initial Values of the Error Code subregistry
16. Acknowledgments 16. Acknowledgments
The XCON WG chairs, Adam Roach and Alan Johnston, provided useful The XCON WG chairs, Adam Roach and Alan Johnston, provided useful
ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat,
Jonathan Rosenberg, and Miguel A. Garcia-Martin provided useful Jonathan Rosenberg, and Miguel A. Garcia-Martin provided useful
comments. comments.
17. References 17. References
skipping to change at page 49, line 48 skipping to change at page 55, line 6
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003. 63, RFC 3629, November 2003.
17.2 Informational References 17.2 Informational References
[6] Handley, M. and V. Jacobson, "SDP: Session Description [8] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[9] Schulzrinne, H., "Requirements for Floor Control Protocol", [11] Schulzrinne, H., "Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-01 (work in progress), July draft-ietf-xcon-floor-control-req-02 (work in progress),
2004. October 2004.
[10] 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.
[11] Rosenberg, J. and H. Schulzrinne, "A Session Initiation
Protocol (SIP) Event Package for Conference State",
draft-ietf-sipping-conference-package-05 (work in progress),
July 2004.
[12] Arkko, J., "MIKEY: Multimedia Internet KEYing",
draft-ietf-msec-mikey-08 (work in progress), December 2003.
[13] Rosenberg, J., "An Extensible Markup Language (XML) Document
Format for Indicating Changes in XML Configuration Access
Protocol (XCAP) Resources", draft-ietf-simple-xcap-package-02
(work in progress), July 2004.
[14] Rosenberg, J., "A Framework for Conferencing with the Session [12] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-02 (work in draft-ietf-sipping-conferencing-framework-03 (work in
progress), June 2004. progress), October 2004.
[15] Camarillo, G., "Session Description Protocol (SDP) Format for [13] Barnes, M. and C. Boulton, "A Framework for Centralized
Conferencing", draft-barnes-xcon-framework-00 (work in
progress), October 2004.
[14] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", Binary Floor Control Protocol (BFCP) Streams",
draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), April draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), April
2005. 2005.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/