draft-ietf-xcon-bfcp-04.txt   draft-ietf-xcon-bfcp-05.txt 
XCON Working Group G. Camarillo XCON Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Expires: November 5, 2005 J. Ott Expires: January 14, 2006 J. Ott
Helsinki University of Technology Helsinki University of Technology
K. Drage K. Drage
Lucent Technologies Lucent Technologies
May 4, 2005 July 13, 2005
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-04.txt draft-ietf-xcon-bfcp-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 November 5, 2005. This Internet-Draft will expire on January 14, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 24 skipping to change at page 2, line 24
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . 8 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 8
3.5 Privileges of Floor Control . . . . . . . . . . . . . . . 9 3.5 Privileges of Floor Control . . . . . . . . . . . . . . . 9
4. Overview of Operation . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 15 5.1 COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 15
5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 16 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 16
5.2.1 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17 5.2.1 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 18
5.2.2 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.2 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.3 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18 5.2.3 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18
5.2.4 NONCE . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.4 NONCE . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.5 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 19 5.2.5 PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 19 5.2.6 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20
5.2.7 PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.7 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20 5.2.8 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 22
5.2.9 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.9 ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 24
5.2.10 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . 23 5.2.10 PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . 25
5.2.11 ERROR-INFO . . . . . . . . . . . . . . . . . . . . . 25 5.2.11 STATUS-INFO . . . . . . . . . . . . . . . . . . . . 26
5.2.12 PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . 25 5.2.12 SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . 26
5.2.13 STATUS-INFO . . . . . . . . . . . . . . . . . . . . 26 5.2.13 SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . 27
5.2.14 SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . 27 5.2.14 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 28
5.2.15 SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . 27 5.2.15 USER-URI . . . . . . . . . . . . . . . . . . . . . . 28
5.2.16 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 28 5.2.16 BENEFICIARY-INFORMATION . . . . . . . . . . . . . . 29
5.2.17 USER-URI . . . . . . . . . . . . . . . . . . . . . . 29 5.2.17 FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . 30
5.2.18 BENEFICIARY-INFORMATION . . . . . . . . . . . . . . 29 5.2.18 REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . 30
5.2.19 FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . 30
5.2.20 REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . 31
5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 31 5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 31
5.3.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . 31 5.3.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . 31
5.3.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . 32 5.3.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . 32
5.3.3 FloorRequestInfoWanted . . . . . . . . . . . . . . . . 32 5.3.3 FloorRequestQuery . . . . . . . . . . . . . . . . . . 32
5.3.4 FloorRequestInfo . . . . . . . . . . . . . . . . . . . 33 5.3.4 FloorRequestStatus . . . . . . . . . . . . . . . . . . 33
5.3.5 UserInfoWanted . . . . . . . . . . . . . . . . . . . . 33 5.3.5 UserQuery . . . . . . . . . . . . . . . . . . . . . . 33
5.3.6 UserInfo . . . . . . . . . . . . . . . . . . . . . . . 34 5.3.6 UserStatus . . . . . . . . . . . . . . . . . . . . . . 33
5.3.7 FloorInfoWanted . . . . . . . . . . . . . . . . . . . 34 5.3.7 FloorQuery . . . . . . . . . . . . . . . . . . . . . . 34
5.3.8 FloorInfo . . . . . . . . . . . . . . . . . . . . . . 34 5.3.8 FloorStatus . . . . . . . . . . . . . . . . . . . . . 34
5.3.9 ChairAction . . . . . . . . . . . . . . . . . . . . . 35 5.3.9 ChairAction . . . . . . . . . . . . . . . . . . . . . 34
5.3.10 ChairActionAck . . . . . . . . . . . . . . . . . . . 35 5.3.10 ChairActionAck . . . . . . . . . . . . . . . . . . . 35
5.3.11 Hello . . . . . . . . . . . . . . . . . . . . . . . 36 5.3.11 Hello . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.12 HelloAck . . . . . . . . . . . . . . . . . . . . . . 36 5.3.12 HelloAck . . . . . . . . . . . . . . . . . . . . . . 35
5.3.13 Error . . . . . . . . . . . . . . . . . . . . . . . 36 5.3.13 Error . . . . . . . . . . . . . . . . . . . . . . . 36
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 37 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 36
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 38 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 37
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 38 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 37
8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 38 8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 38
8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 38 8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 38
9. Authentication and Authorization . . . . . . . . . . . . . . 39 9. Authentication and Authorization . . . . . . . . . . . . . . 38
9.1 TLS-based Mutual Authentication . . . . . . . . . . . . . 39 9.1 TLS-based Mutual Authentication . . . . . . . . . . . . . 38
9.2 Digest-based Client Authentication . . . . . . . . . . . . 39 9.2 Digest-based Client Authentication . . . . . . . . . . . . 39
9.2.1 Client Behavior . . . . . . . . . . . . . . . . . . . 40 9.2.1 Client Behavior . . . . . . . . . . . . . . . . . . . 39
9.2.2 Floor Control Server Behavior . . . . . . . . . . . . 41 9.2.2 Floor Control Server Behavior . . . . . . . . . . . . 41
10. Floor Participant Operations . . . . . . . . . . . . . . . . 42 10. Floor Participant Operations . . . . . . . . . . . . . . . . 42
10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 42 10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 42
10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 43 10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 42
10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 43 10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 43
10.2 Cancelling a Floor Request and Releasing a Floor . . . . 44 10.2 Cancelling a Floor Request and Releasing a Floor . . . . 44
10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 45 10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 44
10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 45 10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 45
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 46 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 45
11.1 Sending a ChairAction Message . . . . . . . . . . . . . 46 11.1 Sending a ChairAction Message . . . . . . . . . . . . . 45
11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 47 11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 46
12. General Client Operations . . . . . . . . . . . . . . . . . 47 12. General Client Operations . . . . . . . . . . . . . . . . . 47
12.1 Requesting Information about Floors . . . . . . . . . . 47 12.1 Requesting Information about Floors . . . . . . . . . . 47
12.1.1 Sending a FloorInfoWanted Message . . . . . . . . . 48 12.1.1 Sending a FloorQuery Message . . . . . . . . . . . . 47
12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 48 12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 47
12.2 Requesting Information about Floor Requests . . . . . . 49 12.2 Requesting Information about Floor Requests . . . . . . 48
12.2.1 Sending a FloorRequestInfoWanted Message . . . . . . 49 12.2.1 Sending a FloorRequestQuery Message . . . . . . . . 49
12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 50 12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 49
12.3 Requesting Information about a User . . . . . . . . . . 50 12.3 Requesting Information about a User . . . . . . . . . . 49
12.3.1 Sending a UserInfoWanted Message . . . . . . . . . . 50 12.3.1 Sending a UserQuery Message . . . . . . . . . . . . 50
12.3.2 Receiving a Response . . . . . . . . . . . . . . . . 51 12.3.2 Receiving a Response . . . . . . . . . . . . . . . . 50
12.4 Obtaining the Capabilities of a Floor Control Server . . 51 12.4 Obtaining the Capabilities of a Floor Control Server . . 50
12.4.1 Sending a Hello Message . . . . . . . . . . . . . . 51 12.4.1 Sending a Hello Message . . . . . . . . . . . . . . 51
12.4.2 Receiving Responses . . . . . . . . . . . . . . . . 51 12.4.2 Receiving Responses . . . . . . . . . . . . . . . . 51
13. Floor Control Server Operations . . . . . . . . . . . . . . 52 13. Floor Control Server Operations . . . . . . . . . . . . . . 51
13.1 Reception of a FloorRequest Message . . . . . . . . . . 52 13.1 Reception of a FloorRequest Message . . . . . . . . . . 52
13.1.1 Generating the First FloorRequestInfo Message . . . 53 13.1.1 Generating the First FloorRequestStatus Message . . 52
13.1.2 Generation of Subsequent FloorRequestInfo Messages . 54 13.1.2 Generation of Subsequent FloorRequestStatus
13.2 Reception of a FloorRequestInfoWanted Message . . . . . 55 Messages . . . . . . . . . . . . . . . . . . . . . . 53
13.3 Reception of a UserInfoWanted Message . . . . . . . . . 56 13.2 Reception of a FloorRequestQuery Message . . . . . . . . 54
13.3 Reception of a UserQuery Message . . . . . . . . . . . . 55
13.4 Reception of a FloorRelease Message . . . . . . . . . . 57 13.4 Reception of a FloorRelease Message . . . . . . . . . . 57
13.5 Reception of a FloorInfoWanted Message . . . . . . . . . 59 13.5 Reception of a FloorQuery Message . . . . . . . . . . . 58
13.5.1 Generation of the First FloorInfo Message . . . . . 59 13.5.1 Generation of the First FloorStatus Message . . . . 58
13.5.2 Generation of Subsequent FloorInfo Messages . . . . 60 13.5.2 Generation of Subsequent FloorStatus Messages . . . 60
13.6 Reception of a ChairAction Message . . . . . . . . . . . 61 13.6 Reception of a ChairAction Message . . . . . . . . . . . 60
13.7 Reception of a Hello Message . . . . . . . . . . . . . . 62 13.7 Reception of a Hello Message . . . . . . . . . . . . . . 61
13.8 Error Message Generation . . . . . . . . . . . . . . . . 62 13.8 Error Message Generation . . . . . . . . . . . . . . . . 61
14. Security Considerations . . . . . . . . . . . . . . . . . . 62 14. Security Considerations . . . . . . . . . . . . . . . . . . 62
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 64 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 63
15.1 Attribute Subregistry . . . . . . . . . . . . . . . . . 64 15.1 Attribute Subregistry . . . . . . . . . . . . . . . . . 63
15.2 Primitive Subregistry . . . . . . . . . . . . . . . . . 65 15.2 Primitive Subregistry . . . . . . . . . . . . . . . . . 64
15.3 Request Status Subregistry . . . . . . . . . . . . . . . 65 15.3 Request Status Subregistry . . . . . . . . . . . . . . . 65
15.4 Error Code Subregistry . . . . . . . . . . . . . . . . . 66 15.4 Error Code Subregistry . . . . . . . . . . . . . . . . . 66
15.5 Digest Algorithm Subregistry . . . . . . . . . . . . . . 67 15.5 Digest Algorithm Subregistry . . . . . . . . . . . . . . 67
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 67 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 67
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 67
17.1 Normative References . . . . . . . . . . . . . . . . . . 68 17.1 Normative References . . . . . . . . . . . . . . . . . . 67
17.2 Informational References . . . . . . . . . . . . . . . . 68 17.2 Informational References . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 68
Intellectual Property and Copyright Statements . . . . . . . 70 Intellectual Property and Copyright Statements . . . . . . . 70
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 [10] list a set of The Requirements for Floor Control Protocol [10] 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- In addition, BFCP has been designed so that it can be used in low-
bandwidth environments. The binary encoding used by BFCP achieves a bandwidth environments. The binary encoding used by BFCP achieves a
small message size (when message signatures are not used) that keeps small message size (when message signatures are not used) that keeps
the time it takes to transmit delay-sensitive BFCP messages at the time it takes to transmit delay-sensitive BFCP messages at
minimum. Delay-sensitive BFCP messages include FloorRequest, minimum. Delay-sensitive BFCP messages include FloorRequest,
FloorRelease, FloorRequestInfo, and ChairAction. It is expected that FloorRelease, FloorRequestStatus, and ChairAction. It is expected
future extensions to these messages do not increase the size of these that future extensions to these messages do not increase the size of
messages in a significant way. 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, Section 3 defines the terminology used throughout this document, 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
skipping to change at page 8, line 12 skipping to change at page 8, line 12
described in [12]. Floor creation and termination are also outside described in [12]. Floor creation and termination are also outside
the scope of BFCP; these aspects are handled using the conference the scope of BFCP; these aspects are handled using the conference
control protocol for manipulating the conference object. control protocol for manipulating the conference object.
Consequently, the floor control server needs to stay up to date on Consequently, the floor control server needs to stay up to date on
changes to the conference object (e.g., when a new floor is created). changes to the conference object (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 a user identifier.
Clients can obtain this information in different ways. One is to use Clients can obtain this information in different ways. One is to use
an offer/answer [9] exchange, which is described in [13]. Other an offer/answer [9] exchange, which is described in [13]. Other
mechanisms are also described in the XCON framework (and other mechanisms are also described in the XCON framework (and other
related documents). related documents).
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
skipping to change at page 9, line 33 skipping to change at page 9, line 33
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 attributes. The consist of a common header followed by a set of attributes. The
common header contains, among other information, a 32-bit conference common header contains, among other information, a 32-bit conference
identifier. Floor participants, media participants, and floor chairs identifier. Floor participants, media participants, and floor chairs
are identified by a 16-bit user identifier, which is carried in an are identified by 16-bit user identifiers.
attribute.
Participant authentication in BFCP is based on shared secrets. The Participant authentication in BFCP is based on shared secrets. The
floor control server of a conference shares a secret with each of the floor control server of a conference shares a secret with each of the
participants in the conference and can request them to sign their participants in the conference and can request them to sign their
messages using that shared secret. messages using that shared secret.
BFCP supports nested attributes (i.e., attributes that contain BFCP supports nested attributes (i.e., attributes that contain
attributes). These are referred to as grouped attributes. attributes). These are referred to as grouped attributes.
There are two types of transactions in BFCP: client-initiated There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions. Client-initiated transactions and server-initiated transactions. Client-initiated
transactions consist of a message from a client to the floor control transactions consist of a message from a client to the floor control
server and a response from the floor control server to the client. server and a response from the floor control server to the client.
Both messages can be related because they carry the same Both messages can be related because they carry the same Transaction
TRANSACTION-ID attribute. Server-initiated transactions consist of a ID value in their common headers. Server-initiated transactions
single message, which has no TRANSACTION-ID attribute, from the floor consist of a single message, whose Transaction ID is 0, from the
control server to a client. floor control server to a client.
4.1 Floor Participant to Floor Control Server Interface 4.1 Floor Participant to Floor Control Server Interface
Floor participants request a floor by sending a FloorRequest message Floor participants request a floor by sending a FloorRequest message
to the floor control server. BFCP supports third-party floor to the floor control server. BFCP supports third-party floor
requests. That is, the floor participant sending the floor request requests. That is, the floor participant sending the floor request
need not be co-located with the media participant that will get the need not be co-located with the media participant that will get the
floor once the floor request is granted. FloorRequest messages carry floor once the floor request is granted. FloorRequest messages carry
the identity of the requester in a USER-ID attribute, and the the identity of the requester in the User ID field of the common
identity of the beneficiary of the floor, in third party floor header, and the identity of the beneficiary of the floor (in third
requests, in a BENEFICIARY-ID attribute. party floor requests) in a BENEFICIARY-ID attribute.
Third party floor requests can be sent, for example, by floor Third party floor requests can be sent, for example, by floor
participants that have a BFCP connection to the floor control participants that have a BFCP connection to the floor control
server but that are not media participants (i.e., they do not server but that are not media participants (i.e., they do not
handle any media). handle any media).
FloorRequest messages identify the floor or floors being requested by FloorRequest messages identify the floor or floors being requested by
carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a
FloorRequest message carries more than one floor identifier, the FloorRequest message carries more than one floor identifier, the
floor control server treats all the floor requests as an atomic floor control server treats all the floor requests as an atomic
package. That is, the floor control server either grants or denies package. That is, the floor control server either grants or denies
all the floors in the FloorRequest message. all the floors in the FloorRequest message.
Floor control servers respond to FloorRequest messages with Floor control servers respond to FloorRequest messages with
FloorRequestInfo messages, which provide information about the status FloorRequestStatus messages, which provide information about the
of the floor request. The first FloorRequestInfo message is the status of the floor request. The first FloorRequestStatus message is
response to the FloorRequest message from the client, and therefore the response to the FloorRequest message from the client, and
carries the same TRANSACTION-ID attribute as the FloorRequest. therefore has the same Transaction ID as the FloorRequest.
Additionally, the first FloorRequestInfo message carries the Floor Additionally, the first FloorRequestStatus message carries the Floor
Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent
FloorRequestInfo messages related to the same floor request will FloorRequestStatus messages related to the same floor request will
carry the same Floor Request ID. This way, the floor participant can carry the same Floor Request ID. This way, the floor participant can
associate them with the appropriate floor request. associate them with the appropriate floor request.
Messages from the floor participant related to a particular floor Messages from the floor participant related to a particular floor
request also use the same Floor Request ID as the first request also use the same Floor Request ID as the first
FloorRequestInfo Message from the floor control server. FloorRequestStatus Message from the floor control server.
Figure 2 shows how a floor participant requests a floor, obtains it, Figure 2 shows how a floor participant requests a floor, obtains it,
and, at a later time, releases it. This figure illustrates the use, and, at a later time, releases it. This figure illustrates the use,
among other attributes, of the TRANSACTION-ID and the among other things, of the Transaction ID and the FLOOR-REQUEST-ID
FLOOR-REQUEST-ID attributes. attribute.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorRequest | |(1) FloorRequest |
|USER-ID: 234 | |Transaction ID: 123 |
|TRANSACTION-ID: 123 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorRequestInfo | |(2) FloorRequestStatus |
|USER-ID: 234 | |Transaction ID: 123 |
|TRANSACTION-ID: 123 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| REQUEST-STATUS: Pending | | REQUEST-STATUS: Pending |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(3) FloorRequestInfo | |(3) FloorRequestStatus |
|USER-ID: 234 | |Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| REQUEST-STATUS: Accepted (1st in Queue) | | REQUEST-STATUS: Accepted (1st in Queue) |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(4) FloorRequestInfo | |(4) FloorRequestStatus |
|USER-ID: 234 | |Transaction ID: 0 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(5) FloorRelease | |(5) FloorRelease |
|USER-ID: 234 | |Transaction ID: 154 |
|TRANSACTION-ID: 154 | |User ID: 234 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(6) FloorRequestInfo | |(6) FloorRequestStatus |
|USER-ID: 234 | |Transaction ID: 154 |
|TRANSACTION-ID: 154 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| REQUEST-STATUS: Released | | REQUEST-STATUS: Released |
|<----------------------------------------------| |<----------------------------------------------|
Figure 2: Requesting and releasing a floor Figure 2: Requesting and releasing a floor
Figure 3 shows how a floor participant requests to be informed on the Figure 3 shows how a floor participant requests to be informed on the
status of a floor. The first FloorInfo message from the floor status of a floor. The first FloorStatus message from the floor
control server is the response to the FloorInfoWanted message, and as control server is the response to the FloorQuery message, and as
such, carries the same TRANSACTION-ID attribute as the such, has the same Transaction ID as the FloorQuery message.
FloorInfoWanted message.
Subsequent FloorInfo messages consist of server-initiated Subsequent FloorStatus messages consist of server-initiated
transactions, and therefore carry no TRANSACTION-ID attribute. transactions, and therefore their Transaction ID is 0. FloorStatus
FloorInfo message (2) indicates that there are currently two floor message (2) indicates that there are currently two floor requests for
requests for the floor whose Floor ID is 543. FloorInfo message (3) the floor whose Floor ID is 543. FloorStatus message (3) indicates
indicates that the floor requests with Floor Request ID 764 has been that the floor requests with Floor Request ID 764 has been granted,
granted, while the floor request with Floor Request ID 635 is the while the floor request with Floor Request ID 635 is the first in the
first in the queue. FloorInfo message (4) indicates that the floor queue. FloorStatus message (4) indicates that the floor request with
request with Floor Request ID 635 has been granted. Floor Request ID 635 has been granted.
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorInfoWanted | |(1) FloorQuery |
|USER-ID: 234 | |Transaction ID: 257 |
|TRANSACTION-ID: 257 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorInfo | |(2) FloorStatus |
|USER-ID: 234 | |Transaction ID: 257 |
|TRANSACTION-ID: 257 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 | | Floor Request ID: 764 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
| REQUEST-STATUS: Accepted (1st in Queue) | | REQUEST-STATUS: Accepted (1st in Queue) |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
| REQUEST-STATUS: Accepted (2nd in Queue) | | REQUEST-STATUS: Accepted (2nd in Queue) |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(3) FloorInfo | |(3) FloorStatus |
|USER-ID: 234 | |Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 | | Floor Request ID: 764 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
| REQUEST-STATUS: Accepted (1st in Queue) | | REQUEST-STATUS: Accepted (1st in Queue) |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(4) FloorInfo | |(4) FloorStatus |
|USER-ID: 234 | |Transaction ID: 0 |
|User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| FLOOR-ID: 543 | | FLOOR-ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
| REQUEST-STATUS: Granted | | REQUEST-STATUS: Granted |
|<----------------------------------------------| |<----------------------------------------------|
Figure 3: Obtaining status information about a floor Figure 3: Obtaining status information about a floor
FloorInfo messages contain information about the floor requests they FloorStatus messages contain information about the floor requests
carry. For example, FloorInfo message (4) indicates that the floor they carry. For example, FloorStatus message (4) indicates that the
request with Floor Request ID 635 has as the beneficiary (i.e., the floor request with Floor Request ID 635 has as the beneficiary (i.e.,
participant that holds the floor when a particular floor request is the participant that holds the floor when a particular floor request
granted) the participant whose User ID is 154. The floor request is granted) the participant whose User ID is 154. The floor request
applies only to the floor whose Floor ID is 543. That is, this is applies only to the floor whose Floor ID is 543. That is, this is
not a multi-floor floor request. not a multi-floor floor request.
A multi-floor floor request applies to more than one floor (e.g., A multi-floor floor request applies to more than one floor (e.g.,
a participant wants to be able to speak and write on the a participant wants to be able to speak and write on the
whiteboard at the same time). The floor control server treats a whiteboard at the same time). The floor control server treats a
multi-floor floor request as an atomic package. That is, the multi-floor floor request as an atomic package. That is, the
floor control server either grants the request for all floors or floor control server either grants the request for all floors or
denies the request for all the floors. denies the request for all the floors.
skipping to change at page 14, line 28 skipping to change at page 14, line 29
server needs to revoke the floor from its current holder before server needs to revoke the floor from its current holder before
granting it to the new participant. granting it to the new participant.
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.
Floor Chair Floor Control Floor Chair Floor Control
Server Server
|(1) ChairAction | |(1) ChairAction |
|USER-ID: 357 | |Transaction ID: 769 |
|TRANSACTION-ID: 769 | |User ID: 357 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|FLOOR-REQUEST-ID: 635 | |FLOOR-REQUEST-ID: 635 |
|REQUEST-STATUS: Granted | |REQUEST-STATUS: Granted |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) ChairActionAck | |(2) ChairActionAck |
|USER-ID: 357 | |Transaction ID: 769 |
|TRANSACTION-ID: 769 | |User ID: 357 |
|<----------------------------------------------| |<----------------------------------------------|
Figure 4: Chair instructing the floor control server Figure 4: Chair instructing the floor control server
5. Packet Format 5. Packet Format
BFCP packets consist of an 8-byte fixed header followed by BFCP packets consist of a 12-byte common header followed by
attributes. All the protocol values MUST be sent in network byte attributes. All the protocol values MUST be sent in network byte
order. order.
5.1 FIXED-HEADER Format 5.1 COMMON-HEADER Format
The following is the FIXED-HEADER format. The following is format of the common header.
0 1 2 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 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 | | Ver |Reserved | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID | | Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: FIXED-HEADER format Figure 5: COMMON-HEADER format
Ver: the 3-bit version field MUST be set to 1 to indicate this Ver: the 3-bit version field MUST be set to 1 to indicate this
version of BFCP. version of BFCP.
Reserved: at this point, the 5 bits in the reserved field SHOULD be 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 set to zero by the sender of the message and MUST be ignored by the
receiver. receiver.
Primitive: this 8-bit field identifies the main purpose of the Primitive: this 8-bit field identifies the main purpose of the
message. The following primitive values are defined: message. The following primitive values are defined:
+-------+------------------------+-----------------------+ +-------+--------------------+-----------------------+
| Value | Primitive | Direction | | Value | Primitive | Direction |
+-------+------------------------+-----------------------+ +-------+--------------------+-----------------------+
| 1 | FloorRequest | P -> S | | 1 | FloorRequest | P -> S |
| 2 | FloorRelease | P -> S | | 2 | FloorRelease | P -> S |
| 3 | FloorRequestInfoWanted | P -> S ; Ch -> S | | 3 | FloorRequestQuery | P -> S ; Ch -> S |
| 4 | FloorRequestInfo | P <- S ; Ch <- S | | 4 | FloorRequestStatus | P <- S ; Ch <- S |
| 5 | UserInfoWanted | P -> S ; Ch -> S | | 5 | UserQuery | P -> S ; Ch -> S |
| 6 | UserInfo | P <- S ; Ch <- S | | 6 | UserStatus | P <- S ; Ch <- S |
| 7 | FloorInfoWanted | P -> S ; Ch -> S | | 7 | FloorQuery | P -> S ; Ch -> S |
| 8 | FloorInfo | P <- S ; Ch <- S | | 8 | FloorStatus | P <- S ; Ch <- S |
| 9 | ChairAction | Ch -> S | | 9 | ChairAction | Ch -> S |
| 10 | ChairActionAck | Ch <- S | | 10 | ChairActionAck | Ch <- S |
| 11 | Hello | P -> S ; Ch -> S | | 11 | Hello | P -> S ; Ch -> S |
| 12 | HelloAck | P <- S ; Ch <- S | | 12 | HelloAck | P <- S ; Ch <- S |
| 13 | Error | P <- S ; Ch <- S | | 13 | Error | P <- S ; Ch <- S |
+-------+------------------------+-----------------------+ +-------+--------------------+-----------------------+
S: Floor Control Server S: Floor Control Server
P: Floor Participant P: Floor Participant
Ch: Floor Chair Ch: Floor Chair
Table 1: BFCP primitives Table 1: BFCP primitives
Payload Length: this 16-bit field contains length of the message in Payload Length: this 16-bit field contains length of the message in
4-byte units excluding the fixed header. 4-byte units excluding the common header.
Conference ID: this 32-bit field identifies the conference the Conference ID: this 32-bit field identifies the conference the
message belongs to. message belongs to.
Transaction ID: this field contains a 16-bit value that allows users
to match a given message with its response. The value of the
Transaction ID in server-initiated transactions is 0 (see Section 8).
User ID: this field contains a 16-bit value that uniquely identifies
a participant within a conference.
The identity used by a participant in BFCP, which is carried in
the User ID field, is generally mapped to the identity used by the
same participant in the session establishment protocol (e.g., in
SIP). The way this mapping is performed is outside the scope of
this specification.
5.2 Attribute Format 5.2 Attribute Format
BFCP attributes are encoded in TLV (Type-Length-Value) format. BFCP attributes are encoded in TLV (Type-Length-Value) format.
Attributes are 32-bit aligned. Attributes are 32-bit aligned.
0 1 2 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 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 | | | Type |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
skipping to change at page 17, line 12 skipping to change at page 17, line 29
The following attribute types are defined: The following attribute types are defined:
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| Type | Attribute | Format | | Type | Attribute | Format |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| 1 | BENEFICIARY-ID | Unsigned16 | | 1 | BENEFICIARY-ID | Unsigned16 |
| 2 | FLOOR-ID | Unsigned16 | | 2 | FLOOR-ID | Unsigned16 |
| 3 | FLOOR-REQUEST-ID | Unsigned16 | | 3 | FLOOR-REQUEST-ID | Unsigned16 |
| 4 | NONCE | Unsigned16 | | 4 | NONCE | Unsigned16 |
| 5 | TRANSACTION-ID | Unsigned16 | | 5 | PRIORITY | OctetString16 |
| 6 | USER-ID | Unsigned16 | | 6 | REQUEST-STATUS | OctetString16 |
| 7 | PRIORITY | OctetString16 | | 7 | DIGEST | OctetString |
| 8 | REQUEST-STATUS | OctetString16 | | 8 | ERROR-CODE | OctetString |
| 9 | DIGEST | OctetString | | 9 | ERROR-INFO | OctetString |
| 10 | ERROR-CODE | OctetString | | 10 | PARTICIPANT-PROVIDED-INFO | OctetString |
| 11 | ERROR-INFO | OctetString | | 11 | STATUS-INFO | OctetString |
| 12 | PARTICIPANT-PROVIDED-INFO | OctetString | | 12 | SUPPORTED-ATTRIBUTES | OctetString |
| 13 | STATUS-INFO | OctetString | | 13 | SUPPORTED-PRIMITIVES | OctetString |
| 14 | SUPPORTED-ATTRIBUTES | OctetString | | 14 | USER-DISPLAY-NAME | OctetString |
| 15 | SUPPORTED-PRIMITIVES | OctetString | | 15 | USER-URI | OctetString |
| 16 | USER-DISPLAY-NAME | OctetString | | 16 | BENEFICIARY-INFORMATION | Grouped |
| 17 | USER-URI | OctetString | | 17 | FLOOR-REQUEST-INFORMATION | Grouped |
| 18 | BENEFICIARY-INFORMATION | Grouped | | 18 | REQUESTED-BY-INFORMATION | Grouped |
| 19 | FLOOR-REQUEST-INFORMATION | Grouped |
| 20 | REQUESTED-BY-INFORMATION | Grouped |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
Table 2: BFCP attributes Table 2: BFCP attributes
M: the 'M' bit, known as the Mandatory bit, indicates whether support M: the 'M' bit, known as the Mandatory bit, indicates whether support
of the attribute is required. If an unrecognized attribute with the of the attribute is required. If an unrecognized attribute with the
'M' bit set is received, the message is rejected. 'M' bit set is received, the message is rejected.
Length: this 8-bit field contains the length of the attribute in Length: this 8-bit field contains the length of the attribute in
bytes, excluding any padding defined for specific attributes. The bytes, excluding any padding defined for specific attributes. The
skipping to change at page 18, line 16 skipping to change at page 18, line 27
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: BENEFICIARY-ID format Figure 7: BENEFICIARY-ID format
Beneficiary ID: this field contains a 16-bit value that uniquely Beneficiary ID: this field contains a 16-bit value that uniquely
identifies a user within a conference. identifies a user within a conference.
Note that although the formats of the BENEFICIARY-ID attribute and of Note that although the formats of the Beneficiary ID and of the User
the USER-ID attribute (see Figure 12) are similar, their semantics ID field in the common header are similar, their semantics are
are different. The BENEFICIARY-ID attribute is used in third-party different. The Beneficiary ID is used in third-party floor requests
floor requests and to request information about a particular and to request information about a particular participant.
participant.
5.2.2 FLOOR-ID 5.2.2 FLOOR-ID
The following is the format of the FLOOR-ID attribute. The following is the format of the FLOOR-ID attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 49 skipping to change at page 19, line 13
The following is the format of the FLOOR-REQUEST-ID attribute. The following is the format of the FLOOR-REQUEST-ID attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FLOOR-REQUEST-ID format Figure 9: FLOOR-REQUEST-ID format
Floor Request ID: this field contains a 16-bit value that indentifies Floor Request ID: this field contains a 16-bit value that identifies
a floor request at the floor control server. a floor request at the floor control server.
5.2.4 NONCE 5.2.4 NONCE
The following is the format of the NONCE attribute. The following is the format of the NONCE attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0| Nonce Value | |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0| Nonce Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: NONCE format Figure 10: NONCE format
Nonce Value: this 16-bit field contains a nonce. Nonce Value: this 16-bit field contains a nonce.
5.2.5 TRANSACTION-ID 5.2.5 PRIORITY
The following is the format of the TRANSACTION-ID attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TRANSACTION-ID format
Transaction ID: this field contains a 16-bit value that allows users
to match a given message with its response.
5.2.6 USER-ID
The following is the format of the USER-ID attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0|M|0 0 0 0 0 1 0 0| User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: USER-ID format
User ID: this field contains a 16-bit value that uniquely identifies
a participant within a conference.
The identify used by a participant in BFCP, which is carried in the
User ID field, is generally mapped to the identity used by the same
participant in the session establishment protocol (e.g., in SIP).
The way this mapping is performed is outside the scope of this
specification.
5.2.7 PRIORITY
The following is the format of the PRIORITY attribute. The following is the format of the PRIORITY attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1|M|0 0 0 0 0 1 0 0|Prio | Reserved | |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: PRIORITY format Figure 11: PRIORITY format
Prio: this field contains a 3-bit priority value as shown in Table 3. Prio: this field contains a 3-bit priority value as shown in Table 3.
Senders SHOULD NOT use values higher than 4 in this field. Receivers Senders SHOULD NOT use values higher than 4 in this field. Receivers
MUST treat values higher than 4 as if the value received had been 4 MUST treat values higher than 4 as if the value received had been 4
(Highest). The default priority value when the PRIORITY attribute is (Highest). The default priority value when the PRIORITY attribute is
missing is 2 (Normal). missing is 2 (Normal).
+-------+----------+ +-------+----------+
| Value | Priority | | Value | Priority |
+-------+----------+ +-------+----------+
skipping to change at page 20, line 43 skipping to change at page 20, line 21
| 3 | High | | 3 | High |
| 4 | Highest | | 4 | Highest |
+-------+----------+ +-------+----------+
Table 3: Priority values Table 3: Priority values
Reserved: at this point, the 13 bits in the reserved field SHOULD be Reserved: at this point, the 13 bits in the reserved field SHOULD be
set to zero by the sender of the message and MUST be ignored by the set to zero by the sender of the message and MUST be ignored by the
receiver. receiver.
5.2.8 REQUEST-STATUS 5.2.6 REQUEST-STATUS
The following is the format of the REQUEST-STATUS attribute. The following is the format of the REQUEST-STATUS attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | |0 0 0 0 1 1 0|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: REQUEST-STATUS format Figure 12: REQUEST-STATUS format
Request Status: this 8-bit field contains the status of the request, Request Status: this 8-bit field contains the status of the request,
as described in the following table. as described in the following table.
+-------+-----------+ +-------+-----------+
| Value | Status | | Value | Status |
+-------+-----------+ +-------+-----------+
| 1 | Pending | | 1 | Pending |
| 2 | Accepted | | 2 | Accepted |
| 3 | Granted | | 3 | Granted |
skipping to change at page 21, line 42 skipping to change at page 21, line 14
server. If the Request Status value is different from Accepted, 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 implement a floor request queue, or the
floor control server does not want to provide the client with this floor control server does not want to provide the client with this
information, all the bits of this field SHOULD be set to zero. 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 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 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 has not done it yet. Once the floor control chair accepts the floor
request, the floor request is moved to the Accepted state. request, the floor request is moved to the Accepted state.
5.2.9 DIGEST 5.2.7 DIGEST
The following is the format of the DIGEST attribute. The following is the format of the DIGEST attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 1|M|0 0 0 1 1 0 0 0| Algorithm | | |0 0 0 0 1 1 1|M|0 0 0 1 1 0 0 0| Algorithm | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| | | |
+ Digest + + Digest +
| | | |
+ + + +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: DIGEST format Figure 13: DIGEST format
Algorithm: this 8-bit field contains the identifier of the algorithm Algorithm: this 8-bit field contains the identifier of the algorithm
used to calculate the keyed digest. The following are the algorithm used to calculate the keyed digest. The following are the algorithm
identifiers defined: identifiers defined:
+------------+-----------+---------------+--------------+ +------------+-----------+---------------+--------------+
| Identifier | Algorithm | Digest Length | Reference | | Identifier | Algorithm | Digest Length | Reference |
+------------+-----------+---------------+--------------+ +------------+-----------+---------------+--------------+
| 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] | | 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] |
+------------+-----------+---------------+--------------+ +------------+-----------+---------------+--------------+
skipping to change at page 22, line 34 skipping to change at page 22, line 4
used to calculate the keyed digest. The following are the algorithm used to calculate the keyed digest. The following are the algorithm
identifiers defined: identifiers defined:
+------------+-----------+---------------+--------------+ +------------+-----------+---------------+--------------+
| Identifier | Algorithm | Digest Length | Reference | | Identifier | Algorithm | Digest Length | Reference |
+------------+-----------+---------------+--------------+ +------------+-----------+---------------+--------------+
| 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] | | 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] |
+------------+-----------+---------------+--------------+ +------------+-----------+---------------+--------------+
Table 5: Digest algorithms Table 5: Digest algorithms
The text used as input to the digest algorithm is the BFCP The text used as input to the digest algorithm is the BFCP
message, including the FIXED-HEADER, up to and including the message, including the common header, up to and including the
attribute preceding the DIGEST attribute. Depending on the attribute preceding the DIGEST attribute. Depending on the
algorithm, this text may need to be padded with zeroes. When algorithm, this text may need to be padded with zeroes. When
HMAC-SHA1 is used, the input text needs to be padded so as to be a HMAC-SHA1 is used, the input text needs to be padded so as to be a
multiple of 64 bytes. multiple of 64 bytes.
The key used as input to the keyed digest is the secret shared The key used as input to the keyed digest is the secret shared
between the server and the user identified by the USER-ID between the server and the user identified by the User ID in the
attribute in the message. common header of the message.
Digest: this field contains a keyed digest of the BFCP message. Its Digest: this field contains a keyed digest of the BFCP message. Its
calculation is described in Section 9. calculation is described in Section 9.
Padding: padding added so that the contents of the DIGEST attribute Padding: padding added so that the contents of the DIGEST attribute
is 32-bit aligned. The Padding bits SHOULD be set to zero by the is 32-bit aligned. The Padding bits SHOULD be set to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
5.2.10 ERROR-CODE 5.2.8 ERROR-CODE
The following is the format of the ERROR-CODE attribute. The following is the format of the ERROR-CODE attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0|M| Length | Error Code | | |0 0 0 1 0 0 0|M| Length | Error Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Error Specific Details | | Error Specific Details |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: ERROR-CODE format Figure 14: ERROR-CODE format
Error Code: this 8-bit field contains an error code from the Error Code: this 8-bit field contains an error code from the
following table. following table.
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Value | Meaning | | Value | Meaning |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| 1 | Conference does not Exist | | 1 | Conference does not Exist |
| 2 | User does not Exist | | 2 | User does not Exist |
| 3 | DIGEST Attribute Required | | 3 | DIGEST Attribute Required |
skipping to change at page 23, line 48 skipping to change at page 23, line 27
| 10 | Floor Request ID Does Not Exist | | 10 | Floor Request ID Does Not Exist |
| 11 | You have Already Reached the | | 11 | You have Already Reached the |
| | Maximum Number of Ongoing Floor | | | Maximum Number of Ongoing Floor |
| | Requests for this Floor | | | Requests for this Floor |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
Table 6: Error Code meaning Table 6: Error Code meaning
Error Specific Details: Present only for certain Error Codes. In Error Specific Details: Present only for certain Error Codes. In
this document, only for Error Code 3 (DIGEST Attribute Needed) and this document, only for Error Code 3 (DIGEST Attribute Needed) and
Error Code 7 (Unknown Mandatory Attribute). See Section 5.2.10.1 and Error Code 7 (Unknown Mandatory Attribute). See Section 5.2.8.1 and
Section 5.2.10.2 for their respective definitions. Section 5.2.8.2 for their respective definitions.
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 ERROR-CODE attribute is 32-bit aligned. If the contents of the ERROR-CODE attribute is 32-bit aligned. If the
attribute is already 32-bit aligned, no padding is needed. attribute is already 32-bit aligned, no padding is needed.
The Padding bits SHOULD be set to zero by the sender and MUST be The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver. ignored by the receiver.
5.2.10.1 Error Specific Details for Error Code 3 5.2.8.1 Error Specific Details for Error Code 3
The following is the format of the Error Specific Details field for The following is the format of the Error Specific Details field for
Error Code 3. Error Code 3.
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm ID | Algorithm ID | Algorithm ID | Algorithm ID | | Algorithm ID | Algorithm ID | Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Algorithm ID | Algorithm ID | | | Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm ID | Algorithm ID | | Algorithm ID | Algorithm ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Digest algorithms format Figure 15: Digest algorithms format
Algorithm ID: these 8-bit fields contain the identifiers of the Algorithm ID: these 8-bit fields contain the identifiers of the
digest algorithms supported by the floor control server in order of digest algorithms supported by the floor control server in order of
preference (i.e., the first algorithm is the most preferred). preference (i.e., the first algorithm is the most preferred).
5.2.10.2 Error Specific Details for Error Code 7 5.2.8.2 Error Specific Details for Error Code 7
The following is the format of the Error Specific Details field for The following is the format of the Error Specific Details field for
Error Code 7. Error Code 7.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown Type|R| Unknown Type|R| | | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Unknown attributes format
Figure 16: Unknown attributes format
Unknown Type: these 7-bit fields contain the Types of the attributes Unknown Type: these 7-bit fields contain the Types of the attributes
(which were present in the message that triggered the Error message) (which were present in the message that triggered the Error message)
that were unknown to the receiver that were unknown to the receiver
R: at this point, this bit is reserved. It SHOULD be set to zero by R: at this point, this bit is reserved. It SHOULD be set to zero by
the sender of the message and MUST be ignored by the receiver. the sender of the message and MUST be ignored by the receiver.
5.2.11 ERROR-INFO 5.2.9 ERROR-INFO
The following is the format of the ERROR-INFO attribute. The following is the format of the ERROR-INFO attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 1|M| Length | | |0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: ERROR-INFO format Figure 17: ERROR-INFO format
Text: this field contains UTF-8 [7] 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 ERROR-INFO preferred language of the receiver of a particular ERROR-INFO
attribute, it MAY use this language to generate the Text field. attribute, it MAY use this language to generate the 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 ERROR-INFO attribute is 32-bit aligned. The Padding contents of the ERROR-INFO attribute is 32-bit aligned. The Padding
bits SHOULD be set to zero by the sender and MUST be ignored by the bits SHOULD be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is receiver. If the attribute is already 32-bit aligned, no padding is
needed. needed.
5.2.12 PARTICIPANT-PROVIDED-INFO 5.2.10 PARTICIPANT-PROVIDED-INFO
The following is the format of the PARTICIPANT-PROVIDED-INFO The following is the format of the PARTICIPANT-PROVIDED-INFO
attribute. attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0|M| Length | | |0 0 0 1 0 1 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: PARTICIPANT-PROVIDED-INFO format Figure 18: PARTICIPANT-PROVIDED-INFO format
Text: this field contains UTF-8 [7] encoded text. Text: this field contains UTF-8 [7] encoded text.
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 PARTICIPANT-PROVIDED-INFO attribute is 32-bit contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit
aligned. The Padding bits SHOULD be set to zero by the sender and aligned. The Padding bits SHOULD be set to zero by the sender and
MUST be ignored by the receiver. If the attribute is already 32-bit MUST be ignored by the receiver. If the attribute is already 32-bit
aligned, no padding is needed. aligned, no padding is needed.
5.2.13 STATUS-INFO 5.2.11 STATUS-INFO
The following is the format of the STATUS-INFO attribute. The following is the format of the STATUS-INFO attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 1|M| Length | | |0 0 0 1 0 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: STATUS-INFO format Figure 19: STATUS-INFO format
Text: this field contains UTF-8 [7] 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 STATUS-INFO preferred language of the receiver of a particular STATUS-INFO
attribute, it MAY use this language to generate the Text field. attribute, it MAY use this language to generate the 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 STATUS-INFO attribute is 32-bit aligned. The Padding contents of the STATUS-INFO attribute is 32-bit aligned. The Padding
bits SHOULD be set to zero by the sender and MUST be ignored by the bits SHOULD be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is receiver. If the attribute is already 32-bit aligned, no padding is
needed. needed.
5.2.14 SUPPORTED-ATTRIBUTES 5.2.12 SUPPORTED-ATTRIBUTES
The following is the format of the SUPPORTED-ATTRIBUTES attribute. The following is the format of the SUPPORTED-ATTRIBUTES attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 0|M| Length | Supported Attribute | |0 0 0 1 1 0 0|M| Length | Supported Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Attribute | Supported Attribute | | Supported Attribute | Supported Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: SUPPORTED-ATTRIBUTES format Figure 20: SUPPORTED-ATTRIBUTES format
Supported Attribute: these fields contain the Types of the attributes Supported Attribute: these fields contain the Types of the attributes
that are supported by the floor control server. that are supported by the floor control server.
Padding: two bytes of padding added so that the contents of the Padding: two bytes of padding added so that the contents of the
SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute
is already 32-bit aligned, no padding is needed. is already 32-bit aligned, no padding is needed.
The Padding bits SHOULD be set to zero by the sender and MUST be The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver. ignored by the receiver.
5.2.15 SUPPORTED-PRIMITIVES 5.2.13 SUPPORTED-PRIMITIVES
The following is the format of the SUPPORTED-PRIMITIVES attribute. The following is the format of the SUPPORTED-PRIMITIVES attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1|M| Length | Primitive | Primitive | |0 0 0 1 1 0 1|M| Length | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primitive | Primitive | Primitive | Primitive | | Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: SUPPORTED-PRIMITIVES format Figure 21: SUPPORTED-PRIMITIVES format
Primitive: these fields contain the types of the BFCP messages that Primitive: these fields contain the types of the BFCP messages that
are supported by the floor control server. See Table 1 for the list are supported by the floor control server. See Table 1 for the list
of BFCP primitives. of BFCP primitives.
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 SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If
the attribute is already 32-bit aligned, no padding is needed. the attribute is already 32-bit aligned, no padding is needed.
The Padding bits SHOULD be set to zero by the sender and MUST be The Padding bits SHOULD be set to zero by the sender and MUST be
ignored by the receiver. ignored by the receiver.
5.2.16 USER-DISPLAY-NAME 5.2.14 USER-DISPLAY-NAME
The following is the format of the USER-DISPLAY-NAME attribute. The following is the format of the USER-DISPLAY-NAME attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0|M| Length | | |0 0 0 1 1 1 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: USER-DISPLAY-NAME format Figure 22: USER-DISPLAY-NAME format
Text: this field contains the UTF-8 encoded name of the user. Text: this field contains the UTF-8 encoded name of the user.
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 USER-DISPLAY-NAME attribute is 32-bit aligned. The contents of the USER-DISPLAY-NAME attribute 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
by the receiver. If the attribute is already 32-bit aligned, no by the receiver. If the attribute is already 32-bit aligned, no
padding is needed. padding is needed.
5.2.17 USER-URI 5.2.15 USER-URI
The following is the format of the USER-URI attribute. The following is the format of the USER-URI attribute.
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M| Length | | |0 0 0 1 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: USER-URI format Figure 23: USER-URI format
Text: this field contains the UTF-8 encoded URI of the user. Text: this field contains the UTF-8 encoded URI of the user.
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 USER-URI attribute is 32-bit aligned. The Padding contents of the USER-URI attribute is 32-bit aligned. The Padding
bits SHOULD be set to zero by the sender and MUST be ignored by the bits SHOULD be set to zero by the sender and MUST be ignored by the
receiver. If the attribute is already 32-bit aligned, no padding is receiver. If the attribute is already 32-bit aligned, no padding is
needed. needed.
5.2.18 BENEFICIARY-INFORMATION 5.2.16 BENEFICIARY-INFORMATION
The BENEFICIARY-INFORMATION attribute is a grouped attribute that The BENEFICIARY-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as BENEFICIARY- consists of a header, which is referred to as BENEFICIARY-
INFORMATION-HEADER, followed by a sequence of attributes. The INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the BENEFICIARY-INFORMATION-HEADER: following is the format of the BENEFICIARY-INFORMATION-HEADER:
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 0|M| Length | Beneficiary ID | |0 0 1 0 0 0 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: BENEFICIARY-INFORMATION-HEADER format Figure 24: BENEFICIARY-INFORMATION-HEADER format
Beneficiary ID: this field contains a 16-bit value that uniquely Beneficiary ID: this field contains a 16-bit value that uniquely
identifies a user within a conference. identifies a user within a conference.
The following is the ABNF (Augmented Backus-Naur Form) [3] of the The following is the ABNF (Augmented Backus-Naur Form) [3] of the
BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE
refers to extension attributes that may be defined in the future.) refers to extension attributes that may be defined in the future.)
BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER)
[USER-DISPLAY-NAME] [USER-DISPLAY-NAME]
[USER-URI] [USER-URI]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 27: BENEFICIARY-INFORMATION format Figure 25: BENEFICIARY-INFORMATION format
5.2.19 FLOOR-REQUEST-INFORMATION 5.2.17 FLOOR-REQUEST-INFORMATION
The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST- consists of a header, which is referred to as FLOOR-REQUEST-
INFORMATION-HEADER, followed by a sequence of attributes. The INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 1|M| Length | Floor Request ID | |0 0 1 0 0 0 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: FLOOR-REQUEST-INFORMATION-HEADER format Figure 26: FLOOR-REQUEST-INFORMATION-HEADER format
Floor Request ID: this field contains a 16-bit value that indentifies Floor Request ID: this field contains a 16-bit value that identifies
a floor request at the floor control server. a floor request at the floor control server.
The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER)
(REQUEST-STATUS) (REQUEST-STATUS)
1*(FLOOR-ID) 1*(FLOOR-ID)
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION] [REQUESTED-BY-INFORMATION]
[PRIORITY] [PRIORITY]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
[STATUS-INFO] [STATUS-INFO]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 29: FLOOR-REQUEST-INFORMATION format Figure 27: FLOOR-REQUEST-INFORMATION format
5.2.20 REQUESTED-BY-INFORMATION 5.2.18 REQUESTED-BY-INFORMATION
The REQUESTED-BY-INFORMATION attribute is a grouped attribute that The REQUESTED-BY-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as REQUESTED-BY- consists of a header, which is referred to as REQUESTED-BY-
INFORMATION-HEADER, followed by a sequence of attributes. The INFORMATION-HEADER, followed by a sequence of attributes. The
following is the format of the REQUESTED-BY-INFORMATION-HEADER: following is the format of the REQUESTED-BY-INFORMATION-HEADER:
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 1 0 0|M| Length | Requested-by ID | |0 0 1 0 0 1 0|M| Length | Requested-by ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: REQUESTED-BY-INFORMATION-HEADER format Figure 28: REQUESTED-BY-INFORMATION-HEADER format
Requested-by ID: this field contains a 16-bit value that uniquely Requested-by ID: this field contains a 16-bit value that uniquely
identifies a user within a conference. identifies a user within a conference.
The following is the ABNF of the REQUESTED-BY-INFORMATION grouped The following is the ABNF of the REQUESTED-BY-INFORMATION grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.) may be defined in the future.)
REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER)
[USER-DISPLAY-NAME] [USER-DISPLAY-NAME]
[USER-URI] [USER-URI]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 31: REQUESTED-BY-INFORMATION format Figure 29: REQUESTED-BY-INFORMATION format
5.3 Message Format 5.3 Message Format
This section contains the normative ABNF (Augmented Backus-Naur Form) This section contains the normative ABNF (Augmented Backus-Naur Form)
[3] of the BFCP messages. Extension attributes that may be defined [3] of the BFCP messages. Extension attributes that may be defined
in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.
5.3.1 FloorRequest 5.3.1 FloorRequest
Floor participants request a floor by sending a FloorRequest message Floor participants request a floor by sending a FloorRequest message
to the floor control server. The following is the format of the to the floor control server. The following is the format of the
FloorRequest message: FloorRequest message:
FloorRequest = (FIXED-HEADER) FloorRequest = (COMMON-HEADER)
(USER-ID)
(TRANSACTION-ID)
*(FLOOR-ID) *(FLOOR-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
[PRIORITY] [PRIORITY]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 32: FloorRequest format Figure 30: FloorRequest format
5.3.2 FloorRelease 5.3.2 FloorRelease
Floor participants release a floor by sending a FloorRelease message Floor participants release a floor by sending a FloorRelease message
to the floor control server. Floor participants also use the to the floor control server. Floor participants also use the
FloorRelease message to cancel pending floor requests. The following FloorRelease message to cancel pending floor requests. The following
is the format of the FloorRelease message: is the format of the FloorRelease message:
FloorRelease = (FIXED-HEADER) FloorRelease = (COMMON-HEADER)
(USER-ID)
(TRANSACTION-ID)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 33: FloorRelease format Figure 31: FloorRelease format
5.3.3 FloorRequestInfoWanted 5.3.3 FloorRequestQuery
Floor participants and floor chairs request information about a floor Floor participants and floor chairs request information about a floor
request by sending a FloorRequestInfoWanted message to the floor request by sending a FloorRequestQuery message to the floor control
control server. The following is the format of the server. The following is the format of the FloorRequestQuery
FloorRequestInfoWanted message: message:
FloorRequestInfoWanted = (FIXED-HEADER) FloorRequestQuery = (COMMON-HEADER)
(USER-ID)
(TRANSACTION-ID)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 34: FloorRequestInfoWanted format Figure 32: FloorRequestQuery format
5.3.4 FloorRequestInfo 5.3.4 FloorRequestStatus
The floor control server informs floor participants and floor chairs The floor control server informs floor participants and floor chairs
about the status of their floor requests by sending them about the status of their floor requests by sending them
FloorRequestInfo messages. The following is the format of the FloorRequestStatus messages. The following is the format of the
FloorRequestInfo message: FloorRequestStatus message:
FloorRequestInfo = (FIXED-HEADER) FloorRequestStatus = (COMMON-HEADER)
(USER-ID)
[TRANSACTION-ID]
(FLOOR-REQUEST-INFORMATION) (FLOOR-REQUEST-INFORMATION)
[NONCE] [NONCE]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 35: FloorRequestInfo format Figure 33: FloorRequestStatus format
5.3.5 UserInfoWanted 5.3.5 UserQuery
Floor participants and floor chairs request information about a Floor participants and floor chairs request information about a
participant and the floor requests related to this participant by participant and the floor requests related to this participant by
sending a UserInfoWanted message to the floor control server. The sending a UserQuery message to the floor control server. The
following is the format of the UserInfoWanted message: following is the format of the UserQuery message:
UserInfoWanted = (FIXED-HEADER) UserQuery = (COMMON-HEADER)
(TRANSACTION-ID)
(USER-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 36: UserInfoWanted format Figure 34: UserQuery format
5.3.6 UserInfo 5.3.6 UserStatus
The floor control server provide information about participants and The floor control server provide information about participants and
their related floor requests to floor participants and floor chairs their related floor requests to floor participants and floor chairs
by sending them UserInfo messages. The following is the format of by sending them UserStatus messages. The following is the format of
the UserInfo message: the UserStatus message:
UserInfo = (FIXED-HEADER) UserStatus = (COMMON-HEADER)
(TRANSACTION-ID)
(USER-ID)
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
1*(FLOOR-REQUEST-INFORMATION) 1*(FLOOR-REQUEST-INFORMATION)
[NONCE] [NONCE]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 37: UserInfo format Figure 35: UserStatus format
5.3.7 FloorInfoWanted 5.3.7 FloorQuery
Floor participants and floor chairs request information about a floor Floor participants and floor chairs request information about a floor
or floors by sending a FloorInfoWanted message to the floor control or floors by sending a FloorQuery message to the floor control
server. The following is the format of the FloorRequest message: server. The following is the format of the FloorRequest message:
FloorInfoWanted = (FIXED-HEADER) FloorQuery = (COMMON-HEADER)
(USER-ID)
(TRANSACTION-ID)
*(FLOOR-ID) *(FLOOR-ID)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 38: FloorInfoWanted format Figure 36: FloorQuery format
5.3.8 FloorInfo 5.3.8 FloorStatus
The floor control server informs floor participants and floor chairs The floor control server informs floor participants and floor chairs
about the status (e.g., the current holder) of a floor by sending about the status (e.g., the current holder) of a floor by sending
them FloorInfo messages. The following is the format of the them FloorStatus messages. The following is the format of the
FloorInfo message: FloorStatus message:
FloorInfo = (FIXED-HEADER) FloorStatus = (COMMON-HEADER)
(USER-ID)
[TRANSACTION-ID]
(FLOOR-ID) (FLOOR-ID)
*[FLOOR-REQUEST-INFORMATION] *[FLOOR-REQUEST-INFORMATION]
[NONCE] [NONCE]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 39: FloorInfo format Figure 37: FloorStatus format
5.3.9 ChairAction 5.3.9 ChairAction
Floor chairs send instructions to floor control servers by sending Floor chairs send instructions to floor control servers by sending
ChairAction messages. The following is the format of the ChairAction ChairAction messages. The following is the format of the ChairAction
message: message:
ChairAction = (FIXED-HEADER) ChairAction = (COMMON-HEADER)
(USER-ID)
(TRANSACTION-ID)
1*(FLOOR-ID) 1*(FLOOR-ID)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
(REQUEST-STATUS) (REQUEST-STATUS)
[STATUS-INFO] [STATUS-INFO]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 40: ChairAction format Figure 38: ChairAction format
5.3.10 ChairActionAck 5.3.10 ChairActionAck
Floor control servers confirm that they have accepted a ChairAction Floor control servers confirm that they have accepted a ChairAction
message by sending a ChairActionAck message. The following is the message by sending a ChairActionAck message. The following is the
format of the ChairActionAck message: format of the ChairActionAck message:
ChairActionAck = (FIXED-HEADER) ChairActionAck = (COMMON-HEADER)
(USER-ID)
(TRANSACTION-ID)
[NONCE] [NONCE]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 41: ChairActionAck format Figure 39: ChairActionAck format
5.3.11 Hello 5.3.11 Hello
Floor participants and floor chairs check the liveness of floor Floor participants and floor chairs check the liveness of floor
control servers by sending a Hello message. The following is the control servers by sending a Hello message. The following is the
format of the Hello message: format of the Hello message:
Hello = (FIXED-HEADER) Hello = (COMMON-HEADER)
(TRANSACTION-ID)
(USER-ID)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
[NONCE] [NONCE]
[DIGEST] [DIGEST]
Figure 42: Hello format Figure 40: Hello format
5.3.12 HelloAck 5.3.12 HelloAck
Floor control servers confirm that they are alive on reception of a Floor control servers confirm that they are alive on reception of a
Hello message by sending a HelloAck message. The following is the Hello message by sending a HelloAck message. The following is the
format of the HelloAck message: format of the HelloAck message:
HelloAck = (FIXED-HEADER) HelloAck = (COMMON-HEADER)
(TRANSACTION-ID)
(USER-ID)
(SUPPORTED-PRIMITIVES) (SUPPORTED-PRIMITIVES)
(SUPPORTED-ATTRIBUTES) (SUPPORTED-ATTRIBUTES)
[NONCE] [NONCE]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 43: HelloAck format Figure 41: HelloAck format
5.3.13 Error 5.3.13 Error
Floor control servers inform floor participants and floor chairs Floor control servers inform floor participants and floor chairs
about errors processing requests by sending them Error messages. The about errors processing requests by sending them Error messages. The
following is the format of the Error message: following is the format of the Error message:
Error = (FIXED-HEADER) Error = (COMMON-HEADER)
(TRANSACTION-ID)
(USER-ID)
(ERROR-CODE) (ERROR-CODE)
[NONCE] [NONCE]
[ERROR-INFO] [ERROR-INFO]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 44: Error format Figure 42: 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 TLV-encoded layer. BFCP implements application-layer framing using TLV-encoded
attributes. attributes.
A client MUST NOT use more than one TCP connection to communicate A client MUST NOT use more than one TCP connection to communicate
skipping to change at page 38, line 27 skipping to change at page 37, line 41
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 [6]. 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 attribute which the the client. The request carries a Transaction ID in its common
floor control server copies into the response. Clients use header which the floor control server copies into the response.
Transaction ID values to match responses with previously-issued Clients use Transaction ID values to match responses with previously-
requests. issued requests.
Server-initiated transactions consist of a single message from a Server-initiated transactions consist of a single message from a
floor control server to a client. Since they do not trigger any floor control server to a client. Since they do not trigger any
response, server-initiated transactions do not have Transaction IDs response, their Transaction ID is set to 0.
associated with them.
8.1 Client Behavior 8.1 Client Behavior
A client starting a client-initiated transaction MUST set the A client starting a client-initiated transaction MUST set the
Conference ID in the FIXED-HEADER of the message to the Conference ID Conference ID in the common header of the message to the Conference
for the conference that the client obtained previously. ID for the conference that the client obtained previously.
The client MUST set the Transaction ID value in the TRANSACTION-ID The client MUST set the Transaction ID value in the common header to
attribute to a number which MUST NOT be reused in another message a number which is different to 0 and which MUST NOT be reused in
from the client until a response from the server is received for the another message from the client until a response from the server is
transaction. The client uses the Transaction ID value to match this received for the transaction. The client uses the Transaction ID
message with the response from the floor control server. value to match this message with the response from the floor control
server.
8.2 Server Behavior 8.2 Server Behavior
A floor control server sending a response within a client-initiated A floor control server sending a response within a client-initiated
transaction MUST copy the Conference ID, the TRANSACTION-ID transaction MUST copy the Conference ID, the Transaction ID, and the
attribute, and the USER-ID attribute from the request received from User ID from the request received from the client into the response.
the client into the response. Server-initiated transactions MUST NOT Server-initiated transactions MUST contain a Transaction ID equal to
contain a TRANSACTION-ID attribute. 0.
9. Authentication and Authorization 9. Authentication and Authorization
BFCP clients SHOULD authenticate the floor control server before BFCP clients SHOULD authenticate the floor control server before
sending any BFCP message to it. Similarly, floor control servers sending any BFCP message to it. Similarly, floor control servers
SHOULD authenticate a client before accepting any BFCP message from SHOULD authenticate a client before accepting any BFCP message from
it. it.
BFCP supports TLS-based mutual authentication between clients and BFCP supports TLS-based mutual authentication between clients and
floor control servers, as specified in Section 9.1. This is the floor control servers, as specified in Section 9.1. This is the
skipping to change at page 40, line 12 skipping to change at page 39, line 27
client and the floor control server. This channel is used to client and the floor control server. This channel is used to
generate a shared secret between them. generate a shared secret between them.
The implementation of such an encrypted and integrity-protected The implementation of such an encrypted and integrity-protected
channel using SIP and the offer/answer model is described in [13]. channel using SIP and the offer/answer model is described in [13].
Digest-based client authentication in BFCP is based on the DIGEST Digest-based client authentication in BFCP is based on the DIGEST
attribute. This attribute contains an algorithm identifier and a attribute. This attribute contains an algorithm identifier and a
keyed digest of the of the BFCP message using that algorithm. The keyed digest of the of the BFCP message using that algorithm. The
text used as input to the digest algorithm is the BFCP message, text used as input to the digest algorithm is the BFCP message,
including the FIXED-HEADER, up to and including the attribute including the common header, up to and including the attribute
preceding the DIGEST attribute. Depending on the algorithm, this preceding the DIGEST attribute. Depending on the algorithm, this
text may need to be padded with zeroes. Section 5.2.9 lists the text may need to be padded with zeroes. Section 5.2.7 lists the
algorithms specified in BFCP. algorithms specified in BFCP.
The key used as input to the keyed digest is the secret shared The key used as input to the keyed digest is the secret shared
between the server and the user identified by the USER-ID attribute between the server and the user identified by the User ID in the
in the message. common header of the message.
Section 9.2.1 and Section 9.2.2 discuss how to achieve client Section 9.2.1 and Section 9.2.2 discuss how to achieve client
authentication using the DIGEST attribute. authentication using the DIGEST attribute.
9.2.1 Client Behavior 9.2.1 Client Behavior
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 attribute floor control server that the client can produce a DIGEST attribute
for a message using their shared secret and that the message is fresh for a message using their shared secret and that the message is fresh
(to avoid replay attacks). Clients prove the freshness of a message (to avoid replay attacks). Clients prove the freshness of a message
skipping to change at page 42, line 16 skipping to change at page 41, line 34
whether the NONCE attribute carries a nonce which was generated by whether the NONCE attribute carries a nonce which was generated by
the floor control server for this client and which still has not the floor control server for this client and which still has not
expired. If the nonce is not valid, authentication is considered to expired. If the nonce is not valid, authentication is considered to
have failed, in which case the floor control server SHOULD return an have failed, in which case the floor control server SHOULD return an
Error message with Error Code 4 (Invalid Nonce) with a new nonce in a Error message with Error Code 4 (Invalid Nonce) with a new nonce in a
NONCE attribute. NONCE attribute.
If the nonce is valid, the floor control server calculates the keyed If the nonce is valid, the floor control server calculates the keyed
digest of the message using the algorithm identified by the DIGEST digest of the message using the algorithm identified by the DIGEST
attribute. The key used as input to the keyed digest is the secret attribute. The key used as input to the keyed digest is the secret
shared between the server and the user identified by the USER-ID shared between the server and the user identified by the User ID in
attribute in the message. If the resulting value is the same as the the common header of the message. If the resulting value is the same
one in the DIGEST attribute, authentication is considered successful. as the one in the DIGEST attribute, authentication is considered
successful.
If the resulting value is different than the one in the DIGEST If the resulting value is different than the one in the DIGEST
attribute, authentication is considered to have failed, in which case attribute, authentication is considered to have failed, in which case
the server SHOULD return an Error message, as described in the server SHOULD return an Error message, as described in
Section 13.8, with Error Code 5 (Authentication Failed). Messages Section 13.8, with Error Code 5 (Authentication Failed). Messages
from a client that cannot be authenticated MUST NOT be processed from a client that cannot be authenticated MUST NOT be processed
further. further.
Floor control servers MAY include a NONCE attribute in their Floor control servers MAY include a NONCE attribute in their
responses to provide the nonce to be used in the next message by the responses to provide the nonce to be used in the next message by the
skipping to change at page 43, line 13 skipping to change at page 42, line 32
A floor participant that wishes to request one or more floors does so A floor participant that wishes to request one or more floors does so
by sending a FloorRequest message to the floor control server. by sending a FloorRequest message to the floor control server.
10.1.1 Sending a FloorRequest Message 10.1.1 Sending a FloorRequest Message
The ABNF in Section 5.3.1 describes the attributes that a The ABNF in Section 5.3.1 describes the attributes that a
FloorRequest message can contain. In addition, the ABNF specifies FloorRequest message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones normatively which of these attributes are mandatory, and which ones
are optional. are optional.
The floor participant sets the Conference ID in the FIXED-HEADER and The floor participant sets the Conference ID and the Transaction ID
the TRANSACTION-ID attribute following the rules given in in the common header following the rules given in Section 8.1.
Section 8.1. Additionally, the floor participant follows the rules Additionally, the floor participant follows the rules in Section 9
in Section 9 which relate to the authentication of the message. which relate to the authentication of the message.
The floor participant must insert a USER-ID attribute, which will be The floor participant sets the User ID in the common header to the
used by the floor control server to authenticate and authorize the floor participant's identifier. This User ID will be used by the
request. If the sender of the FloorRequest message (identified by floor control server to authenticate and authorize the request. If
the USER-ID attribute) is not the participant that would eventually the sender of the FloorRequest message (identified by the User ID) is
get the floor (i.e., a third party floor request), the sender SHOULD not the participant that would eventually get the floor (i.e., a
add a BENEFICIARY-ID attribute to the message identifying the third party floor request), the sender SHOULD add a BENEFICIARY-ID
beneficiary of the floor. attribute to the message identifying the beneficiary of the floor.
Note that the name space for both the User ID and the Beneficiary Note that the name space for both the User ID and the Beneficiary
ID is the same. That is, a given participant is identified by a ID is the same. That is, a given participant is identified by a
single 16-bit value that can be used in several attributes: single 16-bit value that can be used in the User ID in the common
USER-ID, BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED- header and in several attributes: BENEFICIARY-ID, BENEFICIARY-
BY-INFORMATION. INFORMATION, and REQUESTED-BY-INFORMATION.
The floor participant must insert at least one FLOOR-ID attribute in The floor participant must insert at least one FLOOR-ID attribute in
the FloorRequest message. If the client inserts more than one the FloorRequest message. If the client inserts more than one
FLOOR-ID attributes, the floor control server will treat all the FLOOR-ID attributes, the floor control server will treat all the
floor requests as an atomic package. That is, the floor control floor requests as an atomic package. That is, the floor control
server will either grant or deny all the floors in the FloorRequest server will either grant or deny all the floors in the FloorRequest
message. message.
The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute
to state the reason why the floor or floors are being requested. The to state the reason why the floor or floors are being requested. The
skipping to change at page 44, line 7 skipping to change at page 43, line 26
request with a certain priority using a PRIORITY attribute. request with a certain priority using a PRIORITY attribute.
10.1.2 Receiving a Response 10.1.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the FloorRequest message if the message from the floor response to the FloorRequest message if the message from the floor
control server has the same Conference ID, Transaction ID, and User control server has the same Conference ID, Transaction ID, and User
ID as the FloorRequest message, as described in Section 8.1. ID as the FloorRequest message, as described in Section 8.1.
The successful processing of a FloorRequest message at the floor The successful processing of a FloorRequest message at the floor
control server involves generating one or several FloorRequestInfo control server involves generating one or several FloorRequestStatus
messages. The floor participant obtains a Floor Request ID in the messages. The floor participant obtains a Floor Request ID in the
Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in
the first FloorRequestInfo message from the floor control server. the first FloorRequestStatus message from the floor control server.
Subsequent FloorRequestInfo messages from the floor control server Subsequent FloorRequestStatus messages from the floor control server
regarding the same floor request will carry the same Floor Request ID regarding the same floor request will carry the same Floor Request ID
in a FLOOR-REQUEST-INFORMATION attribute as the initial in a FLOOR-REQUEST-INFORMATION attribute as the initial
FloorRequestInfo message. This way, the floor participant can FloorRequestStatus message. This way, the floor participant can
associate subsequent incoming FloorRequestInfo messages with the associate subsequent incoming FloorRequestStatus messages with the
ongoing floor request. ongoing floor request.
The floor participant obtains information about the status of the The floor participant obtains information about the status of the
floor request in the FLOOR-REQUEST-INFORMATION attribute of each of floor request in the FLOOR-REQUEST-INFORMATION attribute of each of
the FloorRequestInfo messages received from the floor control server. the FloorRequestStatus messages received from the floor control
This attribute is a grouped attribute and, as such, it includes a server. This attribute is a grouped attribute and, as such, it
number of attributes that provide information about the floor includes a number of attributes that provide information about the
request. floor request.
The REQUEST-STATUS attribute. If the Request Status value is The REQUEST-STATUS attribute. If the Request Status value is
Granted, all the floors that were requested in the FloorRequest Granted, all the floors that were requested in the FloorRequest
message have been granted. If the Request Status value is Denied, message have been granted. If the Request Status value is Denied,
all the floors that were requested in the FloorRequest message have all the floors that were requested in the FloorRequest message have
been denied. A floor request is considered to be ongoing while it is been denied. A floor request is considered to be ongoing while it is
in the Pending, Accepted, or Granted states. in the Pending, Accepted, or Granted states.
The STATUS-INFO attribute, if present, provides extra information The STATUS-INFO attribute, if present, provides extra information
which the floor participant MAY display to the user. which the floor participant MAY display to the user.
The BENEFICIARY-INFORMATION attribute identifies the beneficiary of The BENEFICIARY-INFORMATION attribute identifies the beneficiary of
the floor request in third-party floor requests. The REQUESTED-BY- the floor request in third-party floor requests. The REQUESTED-BY-
INFORMATION attribute may be not be present in FloorRequestInfo INFORMATION attribute may be not be present in FloorRequestStatus
messages received by the floor participant that requested the floor messages received by the floor participant that requested the floor
because this floor participant is already identified by the USER-ID because this floor participant is already identified by the User ID
attribute. in the common header.
The PRIORITY attribute, when present, contains the priority that was The PRIORITY attribute, when present, contains the priority that was
requested by the generator of the FloorRequest message. requested by the generator of the FloorRequest message.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is not process the FloorRequest message for some reason, which is
described in the Error message. described in the Error message.
10.2 Cancelling a Floor Request and Releasing a Floor 10.2 Cancelling a Floor Request and Releasing a Floor
skipping to change at page 45, line 15 skipping to change at page 44, line 34
server. The FloorRelease message is also used by floor participants server. The FloorRelease message is also used by floor participants
that hold a floor and would like to release it. that hold a floor and would like to release it.
10.2.1 Sending a FloorRelease Message 10.2.1 Sending a FloorRelease Message
The ABNF in Section 5.3.2 describes the attributes that a The ABNF in Section 5.3.2 describes the attributes that a
FloorRelease message can contain. In addition, the ABNF specifies FloorRelease message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones normatively which of these attributes are mandatory, and which ones
are optional. are optional.
The floor participant sets the Conference ID in the FIXED-HEADER and The floor participant sets the Conference ID and the Transaction ID
the TRANSACTION-ID attribute following the rules given in in the common header following the rules given in Section 8.1.
Section 8.1. Additionally, the floor participant follows the rules Additionally, the floor participant follows the rules in Section 9
in Section 9 which relate to the authentication of the message. The which relate to the authentication of the message. The floor
floor participant must insert a USER-ID attribute, which will be used participant sets the User ID in the common header to the floor
by the floor control server to authenticate and authorize the participant's identifier. This User ID will be used by the floor
request. control server to authenticate and authorize the request.
Note that the FloorRelease message is used to release a floor or Note that the FloorRelease message is used to release a floor or
floors that were granted and to cancel ongoing floor requests floors that were granted and to cancel ongoing floor requests
(from the protocol perspective both are ongoing floor requests). (from the protocol perspective both are ongoing floor requests).
Using the same message in both situations helps resolve the race Using the same message in both situations helps resolve the race
condition that occurs when the FloorRelease message and the condition that occurs when the FloorRelease message and the
FloorGrant message cross each other on the wire. FloorGrant message cross each other on the wire.
The floor participant uses the FLOOR-REQUEST-ID that was received in The floor participant uses the FLOOR-REQUEST-ID that was received in
the response to the FloorRequest message that the FloorRelease the response to the FloorRequest message that the FloorRelease
skipping to change at page 45, line 46 skipping to change at page 45, line 17
floors are released as an atomic operation as well (i.e., all are floors are released as an atomic operation as well (i.e., all are
released at the same time). released at the same time).
10.2.2 Receiving a Response 10.2.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the FloorRelease message if the message from the floor response to the FloorRelease message if the message from the floor
control server has the same Conference ID, Transaction ID, and User control server has the same Conference ID, Transaction ID, and User
ID as the FloorRequest message, as described in Section 8.1. ID as the FloorRequest message, as described in Section 8.1.
If the response is a FloorRequestInfo message, the Request Status If the response is a FloorRequestStatus message, the Request Status
value in the REQUEST-STATUS attribute (within the FLOOR-REQUEST- value in the REQUEST-STATUS attribute (within the FLOOR-REQUEST-
INFORMATION grouped attribute) will be Cancelled or Released. INFORMATION grouped attribute) will be Cancelled or Released.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is not process the FloorRequest message for some reason, which is
described in the Error message. described in the Error message.
It is possible that the FloorRelease message crosses on the wire with It is possible that the FloorRelease message crosses on the wire with
a FloorRequestInfo message from the server with a Request Status a FloorRequestStatus message from the server with a Request Status
different from Cancelled or Released. In any case, such a different from Cancelled or Released. In any case, such a
FloorRequestInfo message will not be a response to the FloorRelease FloorRequestStatus message will not be a response to the FloorRelease
message, because its Transaction ID will not match that of the message, because its Transaction ID will not match that of the
FloorRelease. FloorRelease.
11. Chair Operations 11. Chair Operations
This section specifies how floor chairs can instruct the floor This section specifies how floor chairs can instruct the floor
control server to grant or revoke a floor using the protocol elements control server to grant or revoke a floor using the protocol elements
described in earlier sections. described in earlier sections.
Floor chairs that wish to send instructions to a floor control server Floor chairs that wish to send instructions to a floor control server
do so by sending a ChairAction message. do so by sending a ChairAction message.
11.1 Sending a ChairAction Message 11.1 Sending a ChairAction Message
The ABNF in Section 5.3.9 describes the attributes that a ChairAction The ABNF in Section 5.3.9 describes the attributes that a ChairAction
message can contain. In addition, the ABNF specifies normatively message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional. which of these attributes are mandatory, and which ones are optional.
The floor chair sets the Conference ID in the FIXED-HEADER and the The floor chair sets the Conference ID and the Transaction ID in the
TRANSACTION-ID attribute following the rules given in Section 8.1. common header following the rules given in Section 8.1.
Additionally, the floor chair follows the rules in Section 9 which Additionally, the floor chair follows the rules in Section 9 which
relate to the authentication of the message. The floor chair must relate to the authentication of the message. The floor participant
insert a USER-ID attribute, which will be used by the floor control sets the User ID in the common header to the floor participant's
server to authenticate and authorize the request. identifier. This User ID will be used by the floor control server to
authenticate and authorize the request.
The ChairAction message contains instructions that apply to one or The ChairAction message contains instructions that apply to one or
more floors within a particular floor request. The floor or floors more floors within a particular floor request. The floor or floors
are identified by FLOOR-ID attributes and the floor request is are identified by FLOOR-ID attributes and the floor request is
identified by a FLOOR-REQUEST-ID attribute, which are carried in the identified by a FLOOR-REQUEST-ID attribute, which are carried in the
ChairAction message. ChairAction message.
For example, if a floor request consists of two floors that depend For example, if a floor request consists of two floors that depend
on different floor chairs, each floor chair will grant its floor on different floor chairs, each floor chair will grant its floor
within the floor request. Once both chairs have granted their within the floor request. Once both chairs have granted their
skipping to change at page 48, line 6 skipping to change at page 47, line 25
floor chairs. They can be performed by both. floor chairs. They can be performed by both.
12.1 Requesting Information about Floors 12.1 Requesting Information about Floors
A client can obtain information about the status of a floor or floors A client can obtain information about the status of a floor or floors
in different ways, which include using BFCP and using out-of-band in different ways, which include using BFCP and using out-of-band
mechanisms. Clients using BFCP to obtain such information use the mechanisms. Clients using BFCP to obtain such information use the
procedures described in this section. procedures described in this section.
Clients request information about the status of one or several floors Clients request information about the status of one or several floors
by sending a FloorInfoWanted message to the floor control server. by sending a FloorQuery message to the floor control server.
12.1.1 Sending a FloorInfoWanted Message 12.1.1 Sending a FloorQuery Message
The ABNF in Section 5.3.7 describes the attributes that a The ABNF in Section 5.3.7 describes the attributes that a FloorQuery
FloorInfoWanted message can contain. In addition, the ABNF specifies message can contain. In addition, the ABNF specifies normatively
normatively which of these attributes are mandatory, and which ones which of these attributes are mandatory, and which ones are optional.
are optional.
The client sets the Conference ID in the FIXED-HEADER and the The client sets the Conference ID and the Transaction ID in the
TRANSACTION-ID attribute following the rules given in Section 8.1. common header following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9 which relate Additionally, the client follows the rules in Section 9 which relate
to the authentication and the protection of the integrity of the to the authentication and the protection of the integrity of the
message. The client must insert a USER-ID attribute, which will be message. The client sets the User ID in the common header to the
used by the floor control server to authenticate and authorize the client's identifier. This User ID will be used by the floor control
request. server to authenticate and authorize the request.
The client inserts in the message all the Floor IDs it wants to The client inserts in the message all the Floor IDs it wants to
receive information about. The floor control server will send receive information about. The floor control server will send
periodic information about all these floors. If the client does not periodic information about all these floors. If the client does not
want to receive information about a particular floor any longer, it want to receive information about a particular floor any longer, it
sends a new FloorInfoWanted message removing the FLOOR-ID of this sends a new FloorQuery message removing the FLOOR-ID of this floor.
floor. If the client does not want to receive information about any If the client does not want to receive information about any floor
floor any longer, it sends a FloorInfoWanted message with no FLOOR-ID any longer, it sends a FloorQuery message with no FLOOR-ID attribute.
attribute.
12.1.2 Receiving a Response 12.1.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the FloorInfoWanted message if the message from the floor response to the FloorQuery message if the message from the floor
control server has the same Conference ID, Transaction ID, and User control server has the same Conference ID, Transaction ID, and User
ID as the FloorRequest message, as described in Section 8.1. ID as the FloorRequest message, as described in Section 8.1.
On reception of the FloorInfoWanted message, the floor control server On reception of the FloorQuery message, the floor control server will
will respond with a FloorInfo message or with an Error message. If respond with a FloorStatus message or with an Error message. If the
the response is a FloorInfo message, it will contain information response is a FloorStatus message, it will contain information about
about one of the floors the client requested information about. If one of the floors the client requested information about. If the
the client did not include any FLOOR-ID attribute in its client did not include any FLOOR-ID attribute in its FloorQuery
FloorInfoWanted message (i.e., the client does not want to receive message (i.e., the client does not want to receive information about
information about any floor any longer), the FloorInfo message from any floor any longer), the FloorStatus message from the floor control
the floor control server will not include any FLOOR-ID attribute server will not include any FLOOR-ID attribute either.
either.
FloorInfo messages which carry information about a floor contain a FloorStatus messages which carry information about a floor contain a
FLOOR-ID attribute that identifies the floor. After this attribute, FLOOR-ID attribute that identifies the floor. After this attribute,
FloorInfo messages contain information about existing (one or more) FloorStatus messages contain information about existing (one or more)
floor request that relate to that floor. The information about each floor request that relate to that floor. The information about each
particular floor request is encoded in a FLOOR-REQUEST-INFORMATION particular floor request is encoded in a FLOOR-REQUEST-INFORMATION
attribute. This grouped attribute carries a Floor Request ID that attribute. This grouped attribute carries a Floor Request ID that
identifies the floor request followed by a set of attributes that identifies the floor request followed by a set of attributes that
provide information about the floor request. provide information about the floor request.
After the first FloorInfo, the floor control server will continue After the first FloorStatus, the floor control server will continue
sending FloorInfo messages periodically informing the client about sending FloorStatus messages periodically informing the client about
changes on the floors the client requested information about. changes on the floors the client requested information about.
12.2 Requesting Information about Floor Requests 12.2 Requesting Information about Floor Requests
A client can obtain information about the status of one or several A client can obtain information about the status of one or several
floor requests in different ways, which include using BFCP and using floor requests in different ways, which include using BFCP and using
out-of-band mechanisms. Clients using BFCP to obtain such out-of-band mechanisms. Clients using BFCP to obtain such
information use the procedures described in this section. information use the procedures described in this section.
Clients request information about the current status of a floor Clients request information about the current status of a floor
requests by sending a FloorRequestInfoWanted message to the floor requests by sending a FloorRequestQuery message to the floor control
control server. server.
Requesting information about a particular floor request is useful in Requesting information about a particular floor request is useful in
a number of situations. For example, on reception of a FloorRequest a number of situations. For example, on reception of a FloorRequest
message, a floor control server may choose to return FloorRequestInfo message, a floor control server may choose to return
messages only when the floor request changes its state (e.g., from FloorRequestStatus messages only when the floor request changes its
Accepted to Granted), but not when the floor request advances in its state (e.g., from Accepted to Granted), but not when the floor
queue. In this situation, if the user requests it, the floor request advances in its queue. In this situation, if the user
participant can use a FloorRequestInfoWanted message to poll the requests it, the floor participant can use a FloorRequestQuery
floor control server for the status of the floor request. message to poll the floor control server for the status of the floor
request.
12.2.1 Sending a FloorRequestInfoWanted Message 12.2.1 Sending a FloorRequestQuery Message
The ABNF in Section 5.3.3 describes the attributes that a The ABNF in Section 5.3.3 describes the attributes that a
FloorRequestInfoWanted message can contain. In addition, the ABNF FloorRequestQuery message can contain. In addition, the ABNF
specifies normatively which of these attributes are mandatory, and specifies normatively which of these attributes are mandatory, and
which ones are optional. which ones are optional.
The client sets the Conference ID in the FIXED-HEADER and the The client sets the Conference ID and the Transaction ID in the
TRANSACTION-ID attribute following the rules given in Section 8.1. common header following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9 which relate Additionally, the client follows the rules in Section 9 which relate
to the authentication of the message. The client must insert a to the authentication of the message. The client sets the User ID in
USER-ID attribute, which will be used by the floor control server to the common header to the client's identifier. This User ID will be
authenticate and authorize the request. used by the floor control server to authenticate and authorize the
request.
The client must insert a FLOOR-REQUEST-ID attribute that identifies The client must insert a FLOOR-REQUEST-ID attribute that identifies
the floor request at the floor control server. the floor request at the floor control server.
12.2.2 Receiving a Response 12.2.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the FloorRequestInfoWanted message if the message from response to the FloorRequestQuery message if the message from the
the floor control server has the same Conference ID, Transaction ID,a floor control server has the same Conference ID, Transaction ID,a nd
nd User ID as the FloorRequestInfoWanted message, as described in User ID as the FloorRequestQuery message, as described in
Section 8.1. Section 8.1.
If the response is a FloorRequestInfo message, the client obtains If the response is a FloorRequestStatus message, the client obtains
information about the status of the FloorRequest the client requested information about the status of the FloorRequest the client requested
information about in a FLOOR-REQUEST-INFORMATION attribute. information about in a FLOOR-REQUEST-INFORMATION attribute.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the FloorRequestInfoWanted message for some reason, which not process the FloorRequestQuery message for some reason, which is
is described in the Error message. described in the Error message.
12.3 Requesting Information about a User 12.3 Requesting Information about a User
A client can obtain information about a participant and the floor A client can obtain information about a participant and the floor
requests related to this participant in different ways, which include requests related to this participant in different ways, which include
using BFCP and using out-of-band mechanisms. Clients using BFCP to using BFCP and using out-of-band mechanisms. Clients using BFCP to
obtain such information use the procedures described in this section. obtain such information use the procedures described in this section.
Clients request information about a participant and the floor Clients request information about a participant and the floor
requests related to this participant by sending a UserInfoWanted requests related to this participant by sending a UserQuery message
message to the floor control server. to the floor control server.
This functionality may be useful for floor chairs or floor This functionality may be useful for floor chairs or floor
participants interested in the display name and the URI of a participants interested in the display name and the URI of a
particular floor participant. In addition, a floor participant may particular floor participant. In addition, a floor participant may
find it useful to request information about itself. For example, a find it useful to request information about itself. For example, a
floor participant, after experiencing connectivity problems (e.g., floor participant, after experiencing connectivity problems (e.g.,
its TCP connection with the floor control server was down for a while its TCP connection with the floor control server was down for a while
and eventually was re-established), may need to request information and eventually was re-established), may need to request information
about all the still existing floor requests associated to itself. about all the still existing floor requests associated to itself.
12.3.1 Sending a UserInfoWanted Message 12.3.1 Sending a UserQuery Message
The ABNF in Section 5.3.5 describes the attributes that a The ABNF in Section 5.3.5 describes the attributes that a UserQuery
UserInfoWanted message can contain. In addition, the ABNF specifies message can contain. In addition, the ABNF specifies normatively
normatively which of these attributes are mandatory, and which ones which of these attributes are mandatory, and which ones are optional.
are optional.
The client sets the Conference ID in the FIXED-HEADER and the The client sets the Conference ID and the Transaction ID in the
TRANSACTION-ID attribute following the rules given in Section 8.1. common header following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9 which relate Additionally, the client follows the rules in Section 9 which relate
to the authentication of the message. The client must insert a to the authentication of the message. The client sets the User ID in
USER-ID attribute, which will be used by the floor control server to the common header to the client's identifier. This User ID will be
authenticate and authorize the request. used by the floor control server to authenticate and authorize the
request.
If the floor participant the client is requesting information about If the floor participant the client is requesting information about
is not the client issuing the UserInfoWanted message (which is is not the client issuing the UserQuery message (which is identified
identified by the USER-ID attribute in the message) the client MUST by the User ID in the common header of the message) the client MUST
insert a BENEFICIARY-ID attribute. insert a BENEFICIARY-ID attribute.
12.3.2 Receiving a Response 12.3.2 Receiving a Response
A message from the floor control server is considered to be a A message from the floor control server is considered to be a
response to the UserInfoWanted message if the message from the floor response to the UserQuery message if the message from the floor
control server has the same Conference ID, Transaction ID, and User control server has the same Conference ID, Transaction ID, and User
ID as the UserInfoWanted message, as described in Section 8.1. ID as the UserQuery message, as described in Section 8.1.
If the response is a UserInfo message, the client obtains information If the response is a UserStatus message, the client obtains
about the floor participant in a BENEFICIARY-INFORMATION grouped information about the floor participant in a BENEFICIARY-INFORMATION
attribute and about the status of the floor requests associated with grouped attribute and about the status of the floor requests
the floor participant in FLOOR-REQUEST-INFORMATION attributes. associated with the floor participant in FLOOR-REQUEST-INFORMATION
attributes.
If the response is an Error message, the floor control server could If the response is an Error message, the floor control server could
not process the UserInfoWanted message for some reason, which is not process the UserQuery message for some reason, which is described
described in the Error message. in the Error message.
12.4 Obtaining the Capabilities of a Floor Control Server 12.4 Obtaining the Capabilities of a Floor Control Server
A client that wishes to obtain the capabilities of a floor control A client that wishes to obtain the capabilities of a floor control
server does so by sending a Hello message to the floor control server does so by sending a Hello message to the floor control
server. server.
12.4.1 Sending a Hello Message 12.4.1 Sending a Hello Message
The ABNF in Section 5.3.11 describes the attributes that a Hello The ABNF in Section 5.3.11 describes the attributes that a Hello
message can contain. In addition, the ABNF specifies normatively message can contain. In addition, the ABNF specifies normatively
which of these attributes are mandatory, and which ones are optional. which of these attributes are mandatory, and which ones are optional.
The client sets the Conference ID in the FIXED-HEADER and the The client sets the Conference ID and the Transaction ID in the
TRANSACTION-ID attribute following the rules given in Section 8.1. common header following the rules given in Section 8.1.
Additionally, the client follows the rules in Section 9 which relate Additionally, the client follows the rules in Section 9 which relate
to the authentication and the protection of the integrity of the to the authentication and the protection of the integrity of the
message. The client must insert a USER-ID attribute, which will be message. The client sets the User ID in the common header to the
used by the floor control server to authenticate and authorize the client's identifier. This User ID will be used by the floor control
request. server to authenticate and authorize the request.
12.4.2 Receiving Responses 12.4.2 Receiving Responses
A message from the floor control server is considered a response to A message from the floor control server is considered a response to
the Hello message by the client if the message from the floor control the Hello message by the client if the message from the floor control
server has the same Conference ID, Transaction ID, and User ID as the server has the same Conference ID, Transaction ID, and User ID as the
Hello message, as described in Section 8.1. Hello message, as described in Section 8.1.
If the response is a HelloAck message, the floor control server could If the response is a HelloAck message, the floor control server could
process successfully the Hello message. The SUPPORTED-ATTRIBUTES process successfully the Hello message. The SUPPORTED-ATTRIBUTES
skipping to change at page 53, line 7 skipping to change at page 52, line 26
BFCP allows floor participants to have several ongoing floor BFCP allows floor participants to have several ongoing floor
requests for the same floor (e.g., the same floor participant can requests for the same floor (e.g., the same floor participant can
occupy more than one position in a queue at the same time). A occupy more than one position in a queue at the same time). A
floor control server that only supports a certain number of floor control server that only supports a certain number of
ongoing floor requests per floor participant (e.g., one) can use ongoing floor requests per floor participant (e.g., one) can use
Error Code 11 (You have Already Reached the Maximum Number of Error Code 11 (You have Already Reached the Maximum Number of
Ongoing Floor Requests for this Floor) to inform the floor Ongoing Floor Requests for this Floor) to inform the floor
participant. participant.
13.1.1 Generating the First FloorRequestInfo Message 13.1.1 Generating the First FloorRequestStatus Message
The successful processing of a FloorRequest message by a floor The successful processing of a FloorRequest message by a floor
control server involves generating one or several FloorRequestInfo control server involves generating one or several FloorRequestStatus
messages, the first of which SHOULD be generated as soon as possible. messages, the first of which SHOULD be generated as soon as possible.
If the floor control server cannot accept, grant, or deny the floor If the floor control server cannot accept, grant, or deny the floor
request right away (e.g., a decision from a chair is needed), it request right away (e.g., a decision from a chair is needed), it
SHOULD use a Request Status value of Pending in the REQUEST-STATUS SHOULD use a Request Status value of Pending in the REQUEST-STATUS
attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of
the first FloorRequestInfo message it generates. the first FloorRequestStatus message it generates.
The policy a floor control server follows to grant or deny floors The policy a floor control server follows to grant or deny floors
is outside the scope of this document. A given floor control is outside the scope of this document. A given floor control
server may perform these decisions automatically while another may server may perform these decisions automatically while another may
contact a human acting as a chair everytime a decision needs to be contact a human acting as a chair everytime a decision needs to be
made. made.
The floor control server MUST copy the Conference ID, the The floor control server MUST copy the Conference ID, the Transaction
TRANSACTION-ID, and the USER-ID attributes from the FloorRequest into ID, and the User ID from the FloorRequest into the
the FloorRequestInfo, as described in Section 8.2. Additionally, the FloorRequestStatus, as described in Section 8.2. Additionally, the
floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
attribute to the FloorRequestInfo. The attributes contained in this attribute to the FloorRequestStatus. The attributes contained in
grouped attribute carry information about the floor request. this grouped attribute carry information about the floor request.
The floor control server MUST assign an identitifier that is unique The floor control server MUST assign an identitifier that is unique
within the conference to this floor request, and MUST insert it in within the conference to this floor request, and MUST insert it in
the Floor Request ID field of the FLOOR-REQUEST-INFORMATION the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
attribute. This indentifier will be used by the floor participant attribute. This identifier will be used by the floor participant (or
(or by a chair or chairs) to refer to this specific floor request in by a chair or chairs) to refer to this specific floor request in the
the future. future.
The floor control server MUST copy the FLOOR-ID attributes from the The floor control server MUST copy the FLOOR-ID attributes from the
FloorRequest into the FLOOR-REQUEST-INFORMATION attribute. These FloorRequest into the FLOOR-REQUEST-INFORMATION attribute. These
FLOOR-ID attributes identify the floors being requested (i.e., the FLOOR-ID attributes identify the floors being requested (i.e., the
floors associated with this particular floor request). floors associated with this particular floor request).
The floor control server SHOULD copy (if present) the contents of the The floor control server SHOULD copy (if present) the contents of the
BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-
INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped
attribute. Additionally, the floor control server MAY provide the attribute. Additionally, the floor control server MAY provide the
skipping to change at page 54, line 21 skipping to change at page 53, line 40
participant and the rights the participant has according to the participant and the rights the participant has according to the
policy of the conference. For example, a participant that is only policy of the conference. For example, a participant that is only
allowed to use the Normal priority may request Highest priority for a allowed to use the Normal priority may request Highest priority for a
floor request. In that case, the floor control server would ignore floor request. In that case, the floor control server would ignore
the priority requested by the participant. the priority requested by the participant.
The floor control server MAY copy (if present) the PARTICIPANT- The floor control server MAY copy (if present) the PARTICIPANT-
PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-
INFO grouped attribute. INFO grouped attribute.
13.1.2 Generation of Subsequent FloorRequestInfo Messages 13.1.2 Generation of Subsequent FloorRequestStatus Messages
A floor request is considered to be ongoing as long as it is not in A floor request is considered to be ongoing as long as it is not in
the Cancelled, Released, or Revoked states. If the REQUEST-STATUS the Cancelled, Released, or Revoked states. If the REQUEST-STATUS
attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of
the first FloorRequestInfo message generated by the floor control the first FloorRequestStatus message generated by the floor control
server did not indicate any of these states, the floor control server server did not indicate any of these states, the floor control server
will need to send subsequent FloorRequestInfo messages. will need to send subsequent FloorRequestStatus messages.
When the status of the floor request changes, the floor control When the status of the floor request changes, the floor control
server SHOULD send new FloorRequestInfo messages with the appropriate server SHOULD send new FloorRequestStatus messages with the
Request Status. The floor control server MUST add a FLOOR-REQUEST- appropriate Request Status. The floor control server MUST add a
INFORMATION attribute with a Floor Request ID equal to the one sent FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to
in the first FloorRequestInfo message to any new FloorRequestInfo the one sent in the first FloorRequestStatus message to any new
related to the same floor request. (The Floor Request ID identifies FloorRequestStatus related to the same floor request. (The Floor
the floor request the FloorRequestInfo applies to.) Request ID identifies the floor request the FloorRequestStatus
applies to.)
The floor control server MUST NOT add any TRANSACTION-ID attribute to The floor control server MUST set the Transaction ID of subsequent
subsequent FloorRequestInfo messages. FloorRequestStatus messages to 0.
The rate at which the floor control server sends FloorRequestInfo The rate at which the floor control server sends
messages is a matter of local policy. A floor control server may FloorRequestStatus messages is a matter of local policy. A floor
choose to send a new FloorRequestInfo message every time the floor control server may choose to send a new FloorRequestStatus message
request moves in the floor request queue while another may choose every time the floor request moves in the floor request queue
to only send a new FloorRequestInfo message when the floor request while another may choose to only send a new FloorRequestStatus
is Granted or Denied. message when the floor request is Granted or Denied.
The floor control server may add a STATUS-INFO attribute to any of The floor control server may add a STATUS-INFO attribute to any of
the FloorRequestInfo messages it generates to provide extra the FloorRequestStatus messages it generates to provide extra
information about its decisions regarding the floor request (e.g., information about its decisions regarding the floor request (e.g.,
why it was denied). why it was denied).
Floor participants and floor chairs may request to be informed Floor participants and floor chairs may request to be informed
about the status of a floor following the procedures in about the status of a floor following the procedures in
Section 12.1. If the processing of a floor request changes the Section 12.1. If the processing of a floor request changes the
status of a floor (e.g., the floor request is granted and status of a floor (e.g., the floor request is granted and
consequently the floor has a new holder), the floor control server consequently the floor has a new holder), the floor control server
needs to follow the procedures in Section 13.5 to inform the needs to follow the procedures in Section 13.5 to inform the
clients that have requested that information clients that have requested that information
The FIXED-HEADER and the rest of the attributes are the same as in The common header and the rest of the attributes are the same as in
the first FloorRequestInfo message. the first FloorRequestStatus message.
The floor control server can discard the state information about a The floor control server can discard the state information about a
particular floor request when this reaches a status of Cancelled, particular floor request when this reaches a status of Cancelled,
Released, or Revoked. Released, or Revoked.
13.2 Reception of a FloorRequestInfoWanted Message 13.2 Reception of a FloorRequestQuery Message
On reception of a FloorRequestInfoWanted message, the floor control On reception of a FloorRequestQuery message, the floor control server
server follows the rules in Section 9 which relate to client follows the rules in Section 9 which relate to client authentication
authentication and authorization. If while processing the and authorization. If while processing the FloorRequestQuery
FloorRequestInfoWanted message, the floor control server encounters message, the floor control server encounters an error, it SHOULD
an error, it SHOULD generate an Error response following the generate an Error response following the procedures described in
procedures described in Section 13.8 Section 13.8
The successful processing of a FloorRequestInfoWanted message by a The successful processing of a FloorRequestQuery message by a floor
floor control server involves generating a FloorRequestInfo message, control server involves generating a FloorRequestStatus message,
which SHOULD be generated as soon as possible. which SHOULD be generated as soon as possible.
The floor control server MUST copy the Conference ID, the The floor control server MUST copy the Conference ID, the Transaction
TRANSACTION-ID, and the USER-ID attributes from the ID, and the User ID from the FloorRequestQuery message into the
FloorRequestInfoWanted message into the FloorRequestInfo message, as FloorRequestStatus message, as described in Section 8.2.
described in Section 8.2. Additionally, the floor control server Additionally, the floor control server MUST add a FLOOR-REQUEST-
MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the INFORMATION grouped attribute to the FloorRequestStatus. The
FloorRequestInfo. The attributes contained in this grouped attribute attributes contained in this grouped attribute carry information
carry information about the floor request. about the floor request.
The floor control server MUST copy the contents of the The floor control server MUST copy the contents of the
FLOOR-REQUEST-ID attribute from the FloorRequestInfoWanted message FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into
into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
attribute. attribute.
The floor control server MUST add FLOOR-ID attributes to the FLOOR- The floor control server MUST add FLOOR-ID attributes to the FLOOR-
REQUEST-INFORMATION grouped attribute identifying the floors being REQUEST-INFORMATION grouped attribute identifying the floors being
requested (i.e., the floors associated with the floor request requested (i.e., the floors associated with the floor request
identified by the FLOOR-REQUEST-ID attribute). identified by the FLOOR-REQUEST-ID attribute).
The floor control server SHOULD add a BENEFICIARY-ID attribute to the The floor control server SHOULD add a BENEFICIARY-ID attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute identifying the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
beneficiary of the floor request. Additionally, the floor control beneficiary of the floor request. Additionally, the floor control
skipping to change at page 56, line 24 skipping to change at page 55, line 45
The floor control server MAY also add to the FLOOR-REQUEST- The floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request and a STATUS-INFO attribute value requested for the floor request and a STATUS-INFO attribute
with extra information about the floor request. with extra information about the floor request.
The floor control server adds a REQUEST-STATUS attribute to the The floor control server adds a REQUEST-STATUS attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute with the current status FLOOR-REQUEST-INFORMATION grouped attribute with the current status
of the floor request. of the floor request.
13.3 Reception of a UserInfoWanted Message 13.3 Reception of a UserQuery Message
On reception of a UserInfoWanted message, the floor control server
follows the rules in Section 9 which relate to client authentication
and authorization. If while processing the UserInfoWanted message,
the floor control server encounters an error, it SHOULD generate an
Error response following the procedures described in Section 13.8
The successful processing of a UserInfoWanted message by a floor On reception of a UserQuery message, the floor control server follows
control server involves generating a UserInfo message, which SHOULD the rules in Section 9 which relate to client authentication and
be generated as soon as possible. authorization. If while processing the UserQuery message, the floor
control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8
The successful processing of a UserQuery message by a floor control
server involves generating a UserStatus message, which SHOULD be
generated as soon as possible.
The floor control server MUST copy the Conference ID, the The floor control server MUST copy the Conference ID, the Transaction
TRANSACTION-ID, and the USER-ID attributes from the UserInfoWanted ID, and the User ID from the UserQuery message into the USerStatus
message into the USerInfo message, as described in Section 8.2. message, as described in Section 8.2.
The sender of the UserInfoWanted message is requesting information The sender of the UserQuery message is requesting information about
about all the floor requests associated to a given participant (i.e., all the floor requests associated to a given participant (i.e., the
the floor requests where the participant is either the beneficiary or floor requests where the participant is either the beneficiary or the
the requester). This participant is identified by a BENEFICIARY-ID requester). This participant is identified by a BENEFICIARY-ID
attribute or, in the absence of a BENEFICIARY-ID attribute, by a attribute or, in the absence of a BENEFICIARY-ID attribute, by a the
USER-ID attribute in the UserInfoWanted message. User ID in the common header of the UserQuery message.
The floor control server MUST copy, if present, the contents of the The floor control server MUST copy, if present, the contents of the
BENEFICIARY-ID attribute from the UserInfoWanted message into a BENEFICIARY-ID attribute from the UserQuery message into a
BENEFICIARY-INFORMATION attribute in the UserInfo message. BENEFICIARY-INFORMATION attribute in the UserStatus message.
Additionally, the floor control server MAY provide the display name Additionally, the floor control server MAY provide the display name
and the URI of the participant the UserInfo message provides and the URI of the participant the UserStatus message provides
information on in this BENEFICIARY-INFORMATION attribute. information on in this BENEFICIARY-INFORMATION attribute.
The floor control server SHOULD add to the UserInfo message a FLOOR- The floor control server SHOULD add to the UserStatus message a
REQUEST-INFORMATION grouped attribute for each floor request related FLOOR-REQUEST-INFORMATION grouped attribute for each floor request
to the participant the message provides information on (i.e., the related to the participant the message provides information on (i.e.,
floor requests where the participant is either the beneficiary or the the floor requests where the participant is either the beneficiary or
requester). For each FLOOR-REQUEST-INFORMATION attribute, the floor the requester). For each FLOOR-REQUEST-INFORMATION attribute, the
control server follows the following steps. floor control server follows the following steps.
The floor control server MUST identity the floor request the FLOOR- The floor control server MUST identity the floor request the FLOOR-
REQUEST-INFORMATION attribute applies to by filling the Floor Request REQUEST-INFORMATION attribute applies to by filling the Floor Request
ID field of the FLOOR-REQUEST-INFORMATION attribute. ID field of the FLOOR-REQUEST-INFORMATION attribute.
The floor control server MUST add FLOOR-ID attributes to the FLOOR- The floor control server MUST add FLOOR-ID attributes to the FLOOR-
REQUEST-INFORMATION grouped attribute identifying the floors being REQUEST-INFORMATION grouped attribute identifying the floors being
requested (i.e., the floors associated with the floor request requested (i.e., the floors associated with the floor request
identified by the FLOOR-REQUEST-ID attribute). identified by the FLOOR-REQUEST-ID attribute).
skipping to change at page 58, line 4 skipping to change at page 57, line 24
FLOOR-REQUEST-INFORMATION grouped attribute with the current status FLOOR-REQUEST-INFORMATION grouped attribute with the current status
of the floor request. of the floor request.
13.4 Reception of a FloorRelease Message 13.4 Reception of a FloorRelease Message
On reception of a FloorRelease message, the floor control server On reception of a FloorRelease message, the floor control server
follows the rules in Section 9 which relate to client authentication follows the rules in Section 9 which relate to client authentication
and authorization. If while processing the FloorRelease message, the and authorization. If while processing the FloorRelease message, the
floor control server encounters an error, it SHOULD generate an Error floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8 response following the procedures described in Section 13.8
The successful processing of a FloorRelease message by a floor The successful processing of a FloorRelease message by a floor
control server involves generating a FloorRequestInfo message, which control server involves generating a FloorRequestStatus message,
SHOULD be generated as soon as possible. which SHOULD be generated as soon as possible.
The floor control server MUST copy the Conference ID, the The floor control server MUST copy the Conference ID, the Transaction
TRANSACTION-ID, and the USER-ID attributes from the FloorRelease ID, and the User ID from the FloorRelease message into the
message into the FloorRequestInfo message, as described in FloorRequestStatus message, as described in Section 8.2.
Section 8.2.
The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped
attribute to the FloorRequestInfo. The attributes contained in this attribute to the FloorRequestStatus. The attributes contained in
grouped attribute carry information about the floor request. this grouped attribute carry information about the floor request.
The FloorRelease message identifies the floor request it applies to The FloorRelease message identifies the floor request it applies to
using a FLOOR-REQUEST-ID. The floor control server MUST copy the using a FLOOR-REQUEST-ID. The floor control server MUST copy the
contents of the FLOOR-REQUEST-ID attribute from the FloorRelease contents of the FLOOR-REQUEST-ID attribute from the FloorRelease
message into the Floor Request ID field of the FLOOR-REQUEST- message into the Floor Request ID field of the FLOOR-REQUEST-
INFORMATION attribute. INFORMATION attribute.
The floor control server MUST add FLOOR-ID attributes to the FLOOR- The floor control server MUST add FLOOR-ID attributes to the FLOOR-
REQUEST-INFORMATION grouped attribute identifying the floors being REQUEST-INFORMATION grouped attribute identifying the floors being
requested (i.e., the floors associated with the floor request requested (i.e., the floors associated with the floor request
skipping to change at page 59, line 5 skipping to change at page 58, line 23
INFORMATION grouped attribute a PRIORITY attribute with the Priority INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request and a STATUS-INFO attribute value requested for the floor request and a STATUS-INFO attribute
with extra information about the floor request. with extra information about the floor request.
The floor control server MUST add a REQUEST-STATUS attribute to the The floor control server MUST add a REQUEST-STATUS attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status
value SHOULD be Released, if the floor (or floors) had been value SHOULD be Released, if the floor (or floors) had been
previously granted, or Cancelled, if the floor (or floors) had not previously granted, or Cancelled, if the floor (or floors) had not
been previously granted. been previously granted.
13.5 Reception of a FloorInfoWanted Message 13.5 Reception of a FloorQuery Message
On reception of a FloorInfoWanted message, the floor control server On reception of a FloorQuery message, the floor control server
follows the rules in Section 9 which relate to client authentication. follows the rules in Section 9 which relate to client authentication.
If while processing the FloorRelease message, the floor control If while processing the FloorRelease message, the floor control
server encounters an error, it SHOULD generate an Error response server encounters an error, it SHOULD generate an Error response
following the procedures described in Section 13.8 following the procedures described in Section 13.8
A floor control server receiving a FloorInfoWanted message from a A floor control server receiving a FloorQuery message from a client
client SHOULD keep this client informed about the status of the SHOULD keep this client informed about the status of the floors
floors identified by FLOOR-ID attributes in the FloorInfoWanted identified by FLOOR-ID attributes in the FloorQuery message. Floor
message. Floor Control Servers keep clients informed by using Control Servers keep clients informed by using FloorStatus messages.
FloorInfo messages.
An individual FloorInfo message carries information about a single An individual FloorStatus message carries information about a single
floor. So, when a FloorInfoWanted message requests information about floor. So, when a FloorQuery message requests information about more
more than one floor, the floor control server needs to send separate than one floor, the floor control server needs to send separate
FloorInfo messages for different floors. FloorStatus messages for different floors.
The information FloorInfoWanted messages carry may depend on the user The information FloorQuery 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.5.1 Generation of the First FloorInfo Message 13.5.1 Generation of the First FloorStatus Message
The successful processing of a FloorInfoWanted message by a floor The successful processing of a FloorQuery message by a floor control
control server involves generating one or several FloorInfo messages, server involves generating one or several FloorStatus messages, the
the first of which SHOULD be generated as soon as possible. first of which SHOULD be generated as soon as possible.
The floor control server MUST copy the Conference ID, the The floor control server MUST copy the Conference ID, the Transaction
TRANSACTION-ID, and the USER-ID attributes from the FloorInfoWanted ID, and the User ID from the FloorQuery message into the FloorStatus
message into the FloorInfo message, as described in Section 8.2. message, as described in Section 8.2.
If the FloorInfoWanted message did not contain any FLOOR-ID If the FloorQuery message did not contain any FLOOR-ID attribute, the
attribute, the floor control server sends the FloorInfo message floor control server sends the FloorStatus message without adding any
without adding any additional attribute and does not send any additional attribute and does not send any subsequent FloorStatus
subsequent FloorInfo message to the floor participant. message to the floor participant.
If the FloorInfoWanted message contained one or more FLOOR-ID If the FloorQuery message contained one or more FLOOR-ID attributes,
attributes, the floor control server chooses one among them and adds the floor control server chooses one among them and adds this
this FLOOR-ID attribute to the FloorInfo message. The floor control FLOOR-ID attribute to the FloorStatus message. The floor control
server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for
each floor request associated to the floor. Each FLOOR-REQUEST- each floor request associated to the floor. Each FLOOR-REQUEST-
INFORMATION grouped attribute contains a number of attributes which INFORMATION grouped attribute contains a number of attributes which
provide information about the floor request. For each FLOOR-REQUEST- provide information about the floor request. For each FLOOR-REQUEST-
INFORMATION attribute, the floor control server follows the following INFORMATION attribute, the floor control server follows the following
steps. steps.
The floor control server MUST identity the floor request the FLOOR- The floor control server MUST identity the floor request the FLOOR-
REQUEST-INFORMATION attribute applies to by filling the Floor Request REQUEST-INFORMATION attribute applies to by filling the Floor Request
ID field of the FLOOR-REQUEST-INFORMATION attribute. ID field of the FLOOR-REQUEST-INFORMATION attribute.
skipping to change at page 60, line 36 skipping to change at page 60, line 5
The floor control server MAY also add to the FLOOR-REQUEST- The floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request and a STATUS-INFO attribute value requested for the floor request and a STATUS-INFO attribute
with extra information about the floor request. with extra information about the floor request.
The floor control server MUST add a REQUEST-STATUS attribute to the The floor control server MUST add a REQUEST-STATUS attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute with the current status FLOOR-REQUEST-INFORMATION grouped attribute with the current status
of the floor request. of the floor request.
13.5.2 Generation of Subsequent FloorInfo Messages 13.5.2 Generation of Subsequent FloorStatus Messages
If the FloorInfoWanted message carried more than one FLOOR-ID If the FloorQuery message carried more than one FLOOR-ID attribute,
attribute, the floor control server SHOULD generate a FloorInfo the floor control server SHOULD generate a FloorStatus message for
message for each of them (except for the FLOOR-ID attribute chosen each of them (except for the FLOOR-ID attribute chosen for the first
for the first FloorInfo message) as soon as possible. These FloorStatus message) as soon as possible. These FloorStatus messages
FloorInfo messages are generated following the same rules as for the are generated following the same rules as for the first FloorStatus
first FloorInfo message (see Section 13.5.1, but without adding a message (see Section 13.5.1, but their Transaction ID is 0.
TRANSACTION attribute.
After generating these messages, the floor control server sends After generating these messages, the floor control server sends
FloorInfo messages periodically keeping the client informed about all FloorStatus messages periodically keeping the client informed about
the floors the client requested information about. These messages all the floors the client requested information about. The
MUST NOT carry a TRANSACTION-ID attribute. Transaction ID of these messages MUSt be 0.
The rate at which the floor control server sends FloorInfo The rate at which the floor control server sends FloorStatus
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 FloorInfo message every time a new floor choose to send a new FloorStatus message every time a new floor
request arrives while another may choose to only send a new request arrives while another may choose to only send a new
FloorInfo message when a new floor request is Granted. FloorStatus message when a new floor request is Granted.
13.6 Reception of a ChairAction Message 13.6 Reception of a ChairAction Message
On reception of a ChairAction message, the floor control server On reception of a ChairAction message, the floor control server
follows the rules in Section 9 which relate to client authentication follows the rules in Section 9 which relate to client authentication
and authorization. If while processing the ChairAction message, the and authorization. If while processing the ChairAction message, the
floor control server encounters an error, it SHOULD generate an Error floor control server encounters an error, it SHOULD generate an Error
response following the procedures described in Section 13.8 response following the procedures described in Section 13.8
The successful processing of a ChairAction message by a floor control The successful processing of a ChairAction message by a floor control
server involves generating a ChairActionAck message, which SHOULD be server involves generating a ChairActionAck message, which SHOULD be
generated as soon as possible. generated as soon as possible.
The floor control server MUST copy the Conference ID, the The floor control server MUST copy the Conference ID, the Transaction
TRANSACTION-ID, and the USER-ID attributes from the ChairAction ID, and the User ID from the ChairAction message into the
message into the ChairActionAck message, as described in Section 8.2. ChairActionAck message, as described in Section 8.2.
The floor control server needs to take into consideration the The floor control server needs to take into consideration the
operation requested in the ChairAction message (e.g., granting a operation requested in the ChairAction message (e.g., granting a
floor), but does not necessarily need to perform it as requested by floor), but does not necessarily need to perform it as requested by
the floor chair. The operation that the floor control server the floor chair. The operation that the floor control server
performs depends on the ChairAction message and on the internal state performs depends on the ChairAction message and on the internal state
of the floor control server. of the floor control server.
For example, a floor chair may send a ChairAction message granting a For example, a floor chair may send a ChairAction message granting a
floor which was requested as part of an atomic floor request floor which was requested as part of an atomic floor request
skipping to change at page 62, line 16 skipping to change at page 61, line 29
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 which relate to client authentication. If while rules in Section 9 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.8 described in Section 13.8
The successful processing of a Hello message by a floor control The successful processing of a Hello message by a floor control
server involves generating a HelloAck message, which SHOULD be server involves generating a HelloAck message, which SHOULD be
generated as soon as possible. The floor control server MUST copy generated as soon as possible. The floor control server MUST copy
the Conference ID, the TRANSACTION-ID, and the USER-ID attributes the Conference ID, the Transaction ID, and the User ID from the Hello
from the Hello into the HelloAck, as described in Section 8.2. into the HelloAck, as described in Section 8.2.
The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to
the HelloAck message listing all the primitives (i.e., BFCP messages) the HelloAck message listing all the primitives (i.e., BFCP messages)
supported by the floor control server. supported by the floor control server.
The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to
the HelloAck message listing all the attributes supported by the the HelloAck message listing all the attributes supported by the
floor control server. floor control server.
13.8 Error Message Generation 13.8 Error Message Generation
Error messages are always sent in response to a previous message from Error messages are always sent in response to a previous message from
the client as part of a client-initiated transaction. The ABNF in the client as part of a client-initiated transaction. The ABNF in
Section 5.3.13 describes the attributes that an Error message can Section 5.3.13 describes the attributes that an Error message can
contain. In addition, the ABNF specifies normatively which of these contain. In addition, the ABNF specifies normatively which of these
attributes are mandatory, and which ones are optional. attributes are mandatory, and which ones are optional.
The floor control server MUST copy the Conference ID, the The floor control server MUST copy the Conference ID, the Transaction
TRANSACTION-ID, and the USER-ID attributes from the message from the ID, and the User ID from the message from the client into the Error
client into the Error message, as described in Section 8.2. message, as described in Section 8.2.
The floor control server MUST add an ERROR-CODE attribute to the The floor control server MUST add an ERROR-CODE attribute to the
Error message. The ERROR-CODE attribute contains an Error Code from Error message. The ERROR-CODE attribute contains an Error Code from
Table 6. Additionally, the floor control server may add a ERROR-INFO Table 6. Additionally, the floor control server may add a ERROR-INFO
attribute with extra information about the error. attribute with extra information about the error.
14. Security Considerations 14. Security Considerations
BFCP can use TLS or message signatures to provide client BFCP can use TLS or message signatures to provide client
authentication. Floor control server authentication is based on TLS, authentication. Floor control server authentication is based on TLS,
skipping to change at page 64, line 33 skipping to change at page 64, line 12
the reference to the RFC where the attribute is defined. The the reference to the RFC where the attribute is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
+------+---------------------------+------------+ +------+---------------------------+------------+
| Type | Attribute | Reference | | Type | Attribute | Reference |
+------+---------------------------+------------+ +------+---------------------------+------------+
| 1 | BENEFICIARY-ID | [RFC XXXX] | | 1 | BENEFICIARY-ID | [RFC XXXX] |
| 2 | FLOOR-ID | [RFC XXXX] | | 2 | FLOOR-ID | [RFC XXXX] |
| 3 | FLOOR-REQUEST-ID | [RFC XXXX] | | 3 | FLOOR-REQUEST-ID | [RFC XXXX] |
| 4 | NONCE | [RFC XXXX] | | 4 | NONCE | [RFC XXXX] |
| 5 | TRANSACTION-ID | [RFC XXXX] | | 5 | PRIORITY | [RFC XXXX] |
| 6 | USER-ID | [RFC XXXX] | | 6 | REQUEST-STATUS | [RFC XXXX] |
| 7 | PRIORITY | [RFC XXXX] | | 7 | DIGEST | [RFC XXXX] |
| 8 | REQUEST-STATUS | [RFC XXXX] | | 8 | ERROR-CODE | [RFC XXXX] |
| 9 | DIGEST | [RFC XXXX] | | 9 | ERROR-INFO | [RFC XXXX] |
| 10 | ERROR-CODE | [RFC XXXX] | | 10 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] |
| 11 | ERROR-INFO | [RFC XXXX] | | 11 | STATUS-INFO | [RFC XXXX] |
| 12 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | | 12 | SUPPORTED-ATTRIBUTES | [RFC XXXX] |
| 13 | STATUS-INFO | [RFC XXXX] | | 13 | SUPPORTED-PRIMITIVES | [RFC XXXX] |
| 14 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | | 14 | USER-DISPLAY-NAME | [RFC XXXX] |
| 15 | SUPPORTED-PRIMITIVES | [RFC XXXX] | | 15 | USER-URI | [RFC XXXX] |
| 16 | USER-DISPLAY-NAME | [RFC XXXX] | | 16 | BENEFICIARY-INFORMATION | [RFC XXXX] |
| 17 | USER-URI | [RFC XXXX] | | 17 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] |
| 18 | BENEFICIARY-INFORMATION | [RFC XXXX] | | 18 | REQUESTED-BY-INFORMATION | [RFC XXXX] |
| 19 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] |
| 20 | REQUESTED-BY-INFORMATION | [RFC XXXX] |
+------+---------------------------+------------+ +------+---------------------------+------------+
Table 7: Initial values of the BFCP Attribute subregistry Table 7: Initial values of the BFCP Attribute subregistry
15.2 Primitive Subregistry 15.2 Primitive Subregistry
This Section establishes the Primitive subregistry under the BFCP This Section establishes the Primitive subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [5], the Parameters registry. As per the terminology in RFC 2434 [5], the
registration policy for BFCP primitives shall be "Specification registration policy for BFCP primitives shall be "Specification
Required". For the purposes of this subregistry, the BFCP primitives Required". For the purposes of this subregistry, the BFCP primitives
for which IANA registration is requested MUST be defined by a for which IANA registration is requested MUST be defined by a
standards-track RFC. Such RFC MUST specify the primitive's value, standards-track RFC. Such RFC MUST specify the primitive's value,
name, format, and semantics. name, format, and semantics.
For each BFCP primitive, the IANA registers its value, its name, and For each BFCP primitive, the IANA registers its value, its name, and
the reference to the RFC where the primitive is defined. The the reference to the RFC where the primitive is defined. The
following table contains the initial values of this subregistry. following table contains the initial values of this subregistry.
+-------+------------------------+------------+ +-------+--------------------+------------+
| Value | Primitive | Reference | | Value | Primitive | Reference |
+-------+------------------------+------------+ +-------+--------------------+------------+
| 1 | FloorRequest | [RFC XXXX] | | 1 | FloorRequest | [RFC XXXX] |
| 2 | FloorRelease | [RFC XXXX] | | 2 | FloorRelease | [RFC XXXX] |
| 3 | FloorRequestInfoWanted | [RFC XXXX] | | 3 | FloorRequestQuery | [RFC XXXX] |
| 4 | FloorRequestInfo | [RFC XXXX] | | 4 | FloorRequestStatus | [RFC XXXX] |
| 5 | UserInfoWanted | [RFC XXXX] | | 5 | UserQuery | [RFC XXXX] |
| 6 | UserInfo | [RFC XXXX] | | 6 | UserStatus | [RFC XXXX] |
| 7 | FloorInfoWanted | [RFC XXXX] | | 7 | FloorQuery | [RFC XXXX] |
| 8 | FloorInfo | [RFC XXXX] | | 8 | FloorStatus | [RFC XXXX] |
| 9 | ChairAction | [RFC XXXX] | | 9 | ChairAction | [RFC XXXX] |
| 10 | ChairActionAck | [RFC XXXX] | | 10 | ChairActionAck | [RFC XXXX] |
| 11 | Hello | [RFC XXXX] | | 11 | Hello | [RFC XXXX] |
| 12 | HelloAck | [RFC XXXX] | | 12 | HelloAck | [RFC XXXX] |
| 13 | Error | [RFC XXXX] | | 13 | Error | [RFC XXXX] |
+-------+------------------------+------------+ +-------+--------------------+------------+
Table 8: Initial values of the BFCP primitive subregistry Table 8: Initial values of the BFCP primitive subregistry
15.3 Request Status Subregistry 15.3 Request Status Subregistry
This Section establishes the Request Status subregistry under the This Section establishes the Request Status subregistry under the
BFCP Parameters registry. As per the terminology in RFC 2434 [5], BFCP Parameters registry. As per the terminology in RFC 2434 [5],
the registration policy for BFCP request status shall be the registration policy for BFCP request status shall be
"Specification Required". For the purposes of this subregistry, the "Specification Required". For the purposes of this subregistry, the
BFCP request status for which IANA registration is requested MUST be BFCP request status for which IANA registration is requested MUST be
skipping to change at page 67, line 45 skipping to change at page 67, line 34
| 0 | HMAC-SHA1 | RFC 2104 | | 0 | HMAC-SHA1 | RFC 2104 |
+------------+-----------+-----------+ +------------+-----------+-----------+
Table 11: Initial values of the Digest Algorithms subregistry Table 11: Initial values of the Digest Algorithms 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, Miguel A. Garcia-Martin, Mary Barnes, Ben Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben
Campbell, and Dave Morgan provided useful comments. Campbell, Dave Morgan, and Oscar Novo provided useful comments.
17. References 17. References
17.1 Normative References 17.1 Normative References
[1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[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.
skipping to change at page 68, line 43 skipping to change at page 68, line 29
[9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [9] 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.
[10] Schulzrinne, H., "Requirements for Floor Control Protocol", [10] Schulzrinne, H., "Requirements for Floor Control Protocol",
draft-ietf-xcon-floor-control-req-03 (work in progress), draft-ietf-xcon-floor-control-req-03 (work in progress),
January 2005. January 2005.
[11] Rosenberg, J., "A Framework for Conferencing with the Session [11] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol", Initiation Protocol",
draft-ietf-sipping-conferencing-framework-04 (work in draft-ietf-sipping-conferencing-framework-05 (work in
progress), February 2005. progress), May 2005.
[12] Barnes, M. and C. Boulton, "A Framework and Data Model for [12] Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencing", draft-barnes-xcon-framework-02 (work Centralized Conferencing", draft-barnes-xcon-framework-02 (work
in progress), February 2005. in progress), February 2005.
[13] Camarillo, G., "Session Description Protocol (SDP) Format for [13] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-mmusic-sdp-bfcp-00 (work in progress), January 2005. draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
 End of changes. 

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