draft-ietf-xcon-bfcp-06.txt   rfc4582.txt 
XCON Working Group G. Camarillo Network Working Group G. Camarillo
Internet-Draft Ericsson Request for Comments: 4582 Ericsson
Expires: June 2, 2006 J. Ott Category: Standards Track J. Ott
Helsinki University of Technology Helsinki University of Technology
K. Drage K. Drage
Lucent Technologies Lucent Technologies
November 29, 2005 November 2006
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-xcon-bfcp-06.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any Status of This Memo
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 2, 2006. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The IETF Trust (2006).
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
conference and media session setup, conference policy manipulation, conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols. and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP). This document specifies the Binary Floor Control Protocol (BFCP).
BFCP is used between floor participants and floor control servers, BFCP is used between floor participants and floor control servers,
and between floor chairs (i.e., moderators) and floor control and between floor chairs (i.e., moderators) and floor control
servers. servers.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope ...........................................................5
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 ....7
3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 8 3.3. Obtaining Floor-Resource Associations ......................7
3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 8 3.4. Privileges of Floor Control ................................8
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 4. Overview of Operation ...........................................8
4.1. Floor Participant to Floor Control Server Interface . . . 9 4.1. Floor Participant to Floor Control Server Interface ........8
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. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 14 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 ...................................19
5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.4. PRIORITY ...........................................19
5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 19 5.2.5. REQUEST-STATUS .....................................20
5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 20 5.2.6. ERROR-CODE .........................................21
5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 22 5.2.6.1. Error-Specific Details for Error Code 4 ...22
5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 22 5.2.7. ERROR-INFO .........................................22
5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 23 5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23
5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 24 5.2.9. STATUS-INFO ........................................24
5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 24 5.2.10. SUPPORTED-ATTRIBUTES ..............................24
5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 25 5.2.11. SUPPORTED-PRIMITIVES ..............................25
5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 26 5.2.12. USER-DISPLAY-NAME .................................26
5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 26 5.2.13. USER-URI ..........................................26
5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 27 5.2.14. BENEFICIARY-INFORMATION ...........................27
5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 28 5.2.15. FLOOR-REQUEST-INFORMATION .........................27
5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 28 5.2.16. REQUESTED-BY-INFORMATION ..........................28
5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . . 29 5.2.17. FLOOR-REQUEST-STATUS .............................29
5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . . 29 5.2.18. OVERALL-REQUEST-STATUS ...........................30
5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 29 5.3. Message Format ............................................30
5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . . 29 5.3.1. FloorRequest .......................................31
5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 30 5.3.2. FloorRelease .......................................31
5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 30 5.3.3. FloorRequestQuery ..................................31
5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 30 5.3.4. FloorRequestStatus .................................31
5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 31 5.3.5. UserQuery ..........................................32
5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 31 5.3.6. UserStatus .........................................32
5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 31 5.3.7. FloorQuery .........................................32
5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.8. FloorStatus ........................................33
5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.9. ChairAction ........................................33
5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.10. ChairActionAck ....................................33
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.3.11. Hello .............................................33
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 33 5.3.12. HelloAck ..........................................34
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 34 5.3.13. Error .............................................34
8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 34 6. Transport ......................................................34
8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 34 7. Lower-Layer Security ...........................................35
9. Authentication and Authorization . . . . . . . . . . . . . . . 34 8. Protocol Transactions ..........................................35
9.1. TLS-based Mutual Authentication . . . . . . . . . . . . . 35 8.1. Client Behavior ...........................................36
10. Floor Participant Operations . . . . . . . . . . . . . . . . . 36 8.2. Server Behavior ...........................................36
10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 36 9. Authentication and Authorization ...............................36
10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 36 9.1. TLS-Based Mutual Authentication ...........................37
10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 37 10. Floor Participant Operations ..................................37
10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 38 10.1. Requesting a Floor .......................................37
10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 38 10.1.1. Sending a FloorRequest Message ....................38
10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 39 10.1.2. Receiving a Response ..............................38
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 39 10.2. Cancelling a Floor Request and Releasing a Floor .........40
11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 39 10.2.1. Sending a FloorRelease Message ....................40
11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 40 10.2.2. Receiving a Response ..............................40
12. General Client Operations . . . . . . . . . . . . . . . . . . 41 11. Chair Operations ..............................................41
12.1. Requesting Information about Floors . . . . . . . . . . . 41 11.1. Sending a ChairAction Message ............................41
12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 41 11.2. Receiving a Response .....................................42
12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 41 12. General Client Operations .....................................43
12.2. Requesting Information about Floor Requests . . . . . . . 42 12.1. Requesting Information about Floors ......................43
12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 42 12.1.1. Sending a FloorQuery Message ......................43
12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 43 12.1.2. Receiving a Response ..............................43
12.3. Requesting Information about a User . . . . . . . . . . . 43 12.2. Requesting Information about Floor Requests ..............44
12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 44 12.2.1. Sending a FloorRequestQuery Message ...............45
12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 44 12.2.2. Receiving a Response ..............................45
12.4. Obtaining the Capabilities of a Floor Control Server . . . 44 12.3. Requesting Information about a User ......................45
12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 44 12.3.1. Sending a UserQuery Message .......................46
12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 45 12.3.2. Receiving a Response ..............................46
13. Floor Control Server Operations . . . . . . . . . . . . . . . 45 12.4. Obtaining the Capabilities of a Floor Control Server .....46
13.1. Reception of a FloorRequest Message . . . . . . . . . . . 46 12.4.1. Sending a Hello Message ...........................47
13.1.1. Generating the First FloorRequestStatus Message . . . 46 12.4.2. Receiving Responses ...............................47
13.1.2. Generation of Subsequent FloorRequestStatus 13. Floor Control Server Operations ...............................47
Messages . . . . . . . . . . . . . . . . . . . . . . . 47 13.1. Reception of a FloorRequest Message ......................48
13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 48 13.1.1. Generating the First FloorRequestStatus Message ...48
13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 49 13.1.2. Generation of Subsequent
13.4. Reception of a FloorRelease Message . . . . . . . . . . . 51 FloorRequestStatus Messages .......................50
13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 52 13.2. Reception of a FloorRequestQuery Message .................51
13.5.1. Generation of the First FloorStatus Message . . . . . 52 13.3. Reception of a UserQuery Message .........................52
13.5.2. Generation of Subsequent FloorStatus Messages . . . . 54 13.4. Reception of a FloorRelease Message ......................53
13.6. Reception of a ChairAction Message . . . . . . . . . . . . 54 13.5. Reception of a FloorQuery Message ........................54
13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 55 13.5.1. Generation of the First FloorStatus Message .......55
13.8. Error Message Generation . . . . . . . . . . . . . . . . . 55 13.5.2. Generation of Subsequent FloorStatus Messages .....56
14. Security Considerations . . . . . . . . . . . . . . . . . . . 56 13.6. Reception of a ChairAction Message .......................56
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 13.7. Reception of a Hello Message .............................57
15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 57 13.8. Error Message Generation .................................58
15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 58 14. Security Considerations .......................................58
15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 58 15. IANA Considerations ...........................................59
15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 59 15.1. Attribute Subregistry ....................................59
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 15.2. Primitive Subregistry ....................................60
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 15.3. Request Status Subregistry ...............................61
17.1. Normative References . . . . . . . . . . . . . . . . . . . 60 15.4. Error Code Subregistry ...................................62
17.2. Informational References . . . . . . . . . . . . . . . . . 60 16. Acknowledgements ..............................................62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 17. References ....................................................63
Intellectual Property and Copyright Statements . . . . . . . . . . 63 17.1. Normative References .....................................63
17.2. Informational References .................................63
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 to a
particular media stream. Floor control enables such applications to particular media session. 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 [9] 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
bandwidth environments. The binary encoding used by BFCP achieves a low-bandwidth environments. The binary encoding used by BFCP
small message size (when message signatures are not used) that keeps achieves a small message size (when message signatures are not used)
the time it takes to transmit delay-sensitive BFCP messages at that keeps the time it takes to transmit delay-sensitive BFCP
minimum. Delay-sensitive BFCP messages include FloorRequest, messages to a minimum. Delay-sensitive BFCP messages include
FloorRelease, FloorRequestStatus, and ChairAction. It is expected FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It
that future extensions to these messages do not increase the size of is expected that future extensions to these messages will not
these messages in a significant way. increase the size of these messages in a significant way.
The remainder of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
defines the terminology used throughout this document, 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
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations. compliant implementations.
Media Participant: An entity that has access to the media resources Media Participant: An entity that has access to the media resources
of a conference (e.g., it can receive a media stream). In floor- of a conference (e.g., it can receive a media stream). In floor-
controlled conferences, a given media participant is typically co- controlled conferences, a given media participant is typically
located with a floor participant, but does not need to. Third-party colocated with a floor participant, but it does not need to be.
floor requests consist of having a floor participant request a floor Third-party floor requests consist of having a floor participant
for a media participant when they are not colocated. The protocol request a floor for a media participant when they are not colocated.
between a floor participant and a media participant (that are not The protocol between a floor participant and a media participant
colocated) is outside the scope of this document. (that are not colocated) is outside the scope of this document.
Client: a floor participant or a floor chair that communicate with a Client: A floor participant or a floor chair that communicates with a
floor control server using BFCP. floor control server using BFCP.
Floor: A permission to temporarily access or manipulate a specific Floor: A temporary permission to access or manipulate a specific
shared resource or set of resources. shared resource or set of resources.
Floor Chair: A logical entity that manages one floor (grants, denies, Floor Chair: A logical entity that manages one floor (grants, denies,
or revokes a floor). An entity that assumes the logical role of a or revokes a floor). An entity that assumes the logical role of a
floor chair for a given transaction may assume a different role floor chair for a given transaction may assume a different role
(e.g., floor participant) for a different transaction. The roles of (e.g., floor participant) for a different transaction. The roles of
floor chair and floor participant are defined on a transaction-by- floor chair and floor participant are defined on a transaction-by-
transaction basis. BFCP transactions are defined in Section 8. transaction basis. BFCP transactions are defined in Section 8.
Floor Control: A mechanism that enables applications or users to gain Floor Control: A mechanism that enables applications or users to gain
safe and mutually exclusive or non-exclusive input access to the safe and mutually exclusive or non-exclusive input access to the
shared object or resource. shared object or resource.
Floor Control Server: A logical entity that maintains the state of Floor Control Server: A logical entity that maintains the state of
the floor(s) including which floors exists, who the floor chairs are, the floor(s), including which floors exists, who the floor chairs
who holds a floor, etc. Requests to manipulate a floor are directed are, who holds a floor, etc. Requests to manipulate a floor are
at the floor control server. The floor control server of a directed at the floor control server. The floor control server of a
conference may perform other logical roles (e.g., floor participant) conference may perform other logical roles (e.g., floor participant)
in another conference. in another conference.
Floor Participant: A logical entity that requests floors, and Floor Participant: A logical entity that requests floors, and
possibly information about them, from a floor control server. An possibly information about them, from a floor control server. An
entity that assumes the logical role of a floor participant for a entity that assumes the logical role of a floor participant for a
given transaction may assume a different role (e.g., a floor chair) given transaction may assume a different role (e.g., a floor chair)
for a different transaction. The roles of floor participant and for a different transaction. The roles of floor participant and
floor chair are defined on a transaction-by-transaction basis. BFCP floor chair are defined on a transaction-by-transaction basis. BFCP
transactions are defined in Section 8. In floor-controlled transactions are defined in Section 8. In floor-controlled
conferences, a given floor participant is typically co-located with a conferences, a given floor participant is typically colocated with a
media participant, but does not need to. Third-party floor requests media participant, but it does not need to be. Third-party floor
consist of having a floor participant request a floor for a media requests consist of having a floor participant request a floor for a
participant when they are not co-located. media participant when they are not colocated.
Participant: An entity that acts as a floor participant, as a media Participant: An entity that acts as a floor participant, as a media
participant, or as both. participant, or as both.
3. Scope 3. Scope
As stated earlier, BFCP is a protocol to coordinate access to shared As stated earlier, BFCP is a protocol to coordinate access to shared
resources in a conference following the requirements defined in [10]. resources in a conference following the requirements defined in [9].
Floor control complements other functions defined in the XCON Floor control complements other functions defined in the XCON
conferencing framework [12] and is compatible with the SIPPING conferencing framework [10]. The floor control protocol BFCP defined
conferencing framework [11]. The floor control protocol BFCP defined
in this document only specifies a means to arbitrate access to in this document only specifies a means to arbitrate access to
floors. The rules and constraints for floor arbitration and the floors. The rules and constraints for floor arbitration and the
results of floor assignments are outside the scope of this document results of floor assignments are outside the scope of this document
and defined by other protocols [12]. and are defined by other protocols [10].
Figure 1 shows the tasks that BFCP can perform. Figure 1 shows the tasks that BFCP can perform.
+---------+ +---------+
| Floor | | Floor |
| Chair | | Chair |
| | | |
+---------+ +---------+
^ | ^ |
| | | |
skipping to change at page 7, line 33 skipping to change at page 6, line 31
| |<-----------| Server | | | | |<-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+ +-------------+ Granted or +---------+ +-------------+
Denied Denied
Figure 1: Functionality provided by BFCP Figure 1: Functionality provided by BFCP
BFCP provides a means: BFCP provides a means:
o for floor participants to send floor requests to floor control o for floor participants to send floor requests to floor control
servers. servers.
o for floor control servers to grant or deny requests to access a o for floor control servers to grant or deny requests to access a
given resource from floor participants. given resource from floor participants.
o for floor chairs to send floor control servers decisions regarding o for floor chairs to send floor control servers decisions regarding
floor requests. floor requests.
o for floor control servers to keep floor participants and floor o for floor control servers to keep floor participants and floor
chairs informed about the status of a given floor or a given floor chairs informed about the status of a given floor or a given floor
request. request.
Even though tasks that do not belong to the previous list are outside Even though tasks that do not belong to the previous list are outside
the scope of BFCP, some of these out-of-scope tasks relate to floor the scope of BFCP, some of these out-of-scope tasks relate to floor
control and are essential to create floors and to establish BFCP control and are essential for creating floors and establishing BFCP
connections between different entities. In the following connections between different entities. In the following
subsections, we discuss some of these tasks and mechanisms to perform subsections, we discuss some of these tasks and mechanisms to perform
them. them.
3.1. Floor Creation 3.1. Floor Creation
The association of a given floor with a resource or a set of The association of a given floor with a resource or a set of
resources (e.g., media streams) is out of the scope of BFCP as resources (e.g., media streams) is out of the scope of BFCP as
described in [12]. Floor creation and termination are also outside described in [10]. 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 a 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 [7]. Other an SDP offer/answer [8] exchange, which is described in [7]. Other
mechanisms are also described in the XCON framework (and other mechanisms are described in the XCON framework [10] (and other
related documents). related documents).
3.3. Obtaining Floor-Resource Associations 3.3. Obtaining Floor-Resource Associations
Floors are associated with resources. For example, a floor that Floors are associated with resources. For example, a floor that
controls who talks at a given time has a particular audio stream as controls who talks at a given time has a particular audio session as
its associated resource. Associations between floors and resources its associated resource. Associations between floors and resources
are part of the conference object. are part of the conference object.
Floor participants and floor chairs need to know which resources are Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information using associated with which floors. They can obtain this information by
different mechanisms, such as an offer/answer [9] exchange. How to using different mechanisms, such as an SDP offer/answer [8] exchange.
use an offer/answer exchange to obtain these associations is How to use an SDP offer/answer exchange to obtain these associations
described in [7]. is described in [7].
Note that floor participants perform offer/answer exchanges with Note that floor participants perform SDP offer/answer exchanges
the SIP [8] Focus of the conference. So, the SIP Focus needs to with the conference focus of the conference. So, the conference
obtain information about associations between floors and resources focus needs to obtain information about associations between
in order to be able to provide this information to a floor floors and resources in order to be able to provide this
participant in an offer/answer exchange. information to a floor participant in an SDP offer/answer
exchange.
Other mechanisms for obtaining this information, including discussion Other mechanisms for obtaining this information, including discussion
of how the information is made available to a (SIP) Focus, are of how the information is made available to a (SIP) Focus, are
described in the XCON framework (and other related documents). described in the XCON framework [10] (and other related documents).
3.4. Privileges of Floor Control 3.4. Privileges of Floor Control
A participant whose floor request is granted has the right to use (in A participant whose floor request is granted has the right to use (in
a certain way) the resource or resources associated with the floor a certain way) the resource or resources associated with the floor
that was requested. For example, the participant may have the right that was requested. For example, the participant may have the right
to send media over a particular audio stream. to send media over a particular audio stream.
Nevertheless, holding a floor does not imply that others will not be Nevertheless, holding a floor does not imply that others will not be
able to use its associated resources at the same time, even if they able to use its associated resources at the same time, even if they
do not have the right to do so. Determination of which media do not have the right to do so. Determination of which media
participants can actually use the resources in the conference is participants can actually use the resources in the conference is
discussed in the XCON Framework. discussed in the XCON Framework [10].
4. Overview of Operation 4. Overview of Operation
This section provides a non-normative description of BFCP operations. This section provides a non-normative description of BFCP operations.
Section 4.1 describes the interface between floor participants and Section 4.1 describes the interface between floor participants and
floor control servers and Section 4.2 describes the interface between floor control servers, and Section 4.2 describes the interface
floor chairs and floor control servers between 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 16-bit user identifiers. are identified by 16-bit user identifiers.
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.
skipping to change at page 9, line 41 skipping to change at page 8, line 48
Both messages can be related because they carry the same Transaction Both messages can be related because they carry the same Transaction
ID value in their common headers. Server-initiated transactions ID value in their common headers. Server-initiated transactions
consist of a single message, whose Transaction ID is 0, from the consist of a single message, whose Transaction ID is 0, from the
floor 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 colocated 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 the User ID field of the common the identity of the requester in the User ID field of the common
header, and the identity of the beneficiary of the floor (in third header, and the identity of the beneficiary of the floor (in third-
party floor 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.
skipping to change at page 10, line 46 skipping to change at page 10, line 18
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorRequestStatus | |(2) FloorRequestStatus |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| FLOOR-ID: 543 | | OVERALL-REQUEST-STATUS |
| REQUEST-STATUS: Pending | | Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(3) FloorRequestStatus | |(3) FloorRequestStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| FLOOR-ID: 543 | | OVERALL-REQUEST-STATUS |
| REQUEST-STATUS: Accepted (1st in Queue) | | Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(4) FloorRequestStatus | |(4) FloorRequestStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| FLOOR-ID: 543 | | OVERALL-REQUEST-STATUS |
| REQUEST-STATUS: Granted | | Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(5) FloorRelease | |(5) FloorRelease |
|Transaction ID: 154 | |Transaction ID: 154 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(6) FloorRequestStatus | |(6) FloorRequestStatus |
|Transaction ID: 154 | |Transaction ID: 154 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| FLOOR-ID: 543 | | OVERALL-REQUEST-STATUS |
| REQUEST-STATUS: Released | | Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------| |<----------------------------------------------|
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 FloorStatus message from the floor status of a floor. The first FloorStatus message from the floor
control server is the response to the FloorQuery message, and as control server is the response to the FloorQuery message and, as
such, has the same Transaction ID as the FloorQuery message. such, has the same Transaction ID as the FloorQuery message.
Subsequent FloorStatus messages consist of server-initiated Subsequent FloorStatus messages consist of server-initiated
transactions, and therefore their Transaction ID is 0. FloorStatus transactions, and therefore their Transaction ID is 0. FloorStatus
message (2) indicates that there are currently two floor requests for message (2) indicates that there are currently two floor requests for
the floor whose Floor ID is 543. FloorStatus message (3) indicates the floor whose Floor ID is 543. FloorStatus message (3) indicates
that the floor requests with Floor Request ID 764 has been granted, that the floor requests with Floor Request ID 764 has been granted,
while the floor request with Floor Request ID 635 is the first in the and the floor request with Floor Request ID 635 is the first in the
queue. FloorStatus message (4) indicates that the floor request with queue. FloorStatus message (4) indicates that the floor 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) FloorQuery | |(1) FloorQuery |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorStatus | |(2) FloorStatus |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |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 | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
| REQUEST-STATUS: Accepted (1st in Queue) |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| FLOOR-ID: 543 | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
| REQUEST-STATUS: Accepted (2nd in Queue) |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(3) FloorStatus | |(3) FloorStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|User ID: 234 | |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 | | OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
| REQUEST-STATUS: Granted |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| FLOOR-ID: 543 | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
| REQUEST-STATUS: Accepted (1st in Queue) |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(4) FloorStatus | |(4) FloorStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|User ID: 234 | |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 | | OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
| REQUEST-STATUS: Granted |
|<----------------------------------------------| |<----------------------------------------------|
Figure 3: Obtaining status information about a floor Figure 3: Obtaining status information about a floor
FloorStatus messages contain information about the floor requests FloorStatus messages contain information about the floor requests
they carry. For example, FloorStatus message (4) indicates that the they carry. For example, FloorStatus message (4) indicates that the
floor request with Floor Request ID 635 has as the beneficiary (i.e., floor request with Floor Request ID 635 has as the beneficiary (i.e.,
the participant that holds the floor when a particular floor request the participant that holds the floor when a particular floor request
is 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 floors.
4.2. Floor Chair to Floor Control Server Interface 4.2. Floor Chair to Floor Control Server Interface
Figure 4 shows a floor chair instructing a floor control server to Figure 4 shows a floor chair instructing a floor control server to
grant a floor. Note, however, that although the floor control server grant a floor.
needs to take into consideration the instructions received in
ChairAction messages (e.g., granting a floor), it does not Note, however, that although the floor control server needs to
necessarily need to perform them exactly as requested by the floor take into consideration the instructions received in ChairAction
chair. The operation that the floor control server performs depends messages (e.g., granting a floor), it does not necessarily need to
on the ChairAction message and on the internal state of the floor perform them exactly as requested by the floor chair. The
control server. operation that the floor control server performs depends on the
ChairAction message and on the internal state 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 that was requested as part of an atomic floor request operation
operation that involved several floors. Even if the chair that involved several floors. Even if the chair responsible for one
responsible for one of the floors instructs the floor control server of the floors instructs the floor control server to grant the floor,
to grant the floor, the floor control server will not grant it until the floor control server will not grant it until the chairs
the chairs responsible for the other floors agree to grant them as responsible for the other floors agree to grant them as well. In
well. In another example, a floor chair may instruct the floor another example, a floor chair may instruct the floor control server
control server to grant a floor to a participant. The floor control to grant a floor to a participant. The floor control server needs to
server needs to revoke the floor from its current holder before revoke the floor from its current holder before granting it to the
granting it to the new participant. new participant.
So, the floor control server is ultimately responsible to keep a So, the floor control server is ultimately responsible for keeping 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 |
|Transaction ID: 769 | |Transaction ID: 769 |
|User ID: 357 | |User ID: 357 |
|FLOOR-ID: 543 | |FLOOR-REQUEST-INFORMATION |
|FLOOR-REQUEST-ID: 635 | | Floor Request ID: 635 |
|REQUEST-STATUS: Granted | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| Request Status: Granted |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) ChairActionAck | |(2) ChairActionAck |
|Transaction ID: 769 | |Transaction ID: 769 |
|User ID: 357 | |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 a 12-octet common header followed by BFCP packets consist of a 12-octet 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. COMMON-HEADER Format 5.1. COMMON-HEADER Format
The following is format of the common header. The following is the 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 | | Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: COMMON-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 | FloorRequestQuery | P -> S ; Ch -> S | | 3 | FloorRequestQuery | P -> S ; Ch -> S |
| 4 | FloorRequestStatus | P <- S ; Ch <- S | | 4 | FloorRequestStatus | P <- S ; Ch <- S |
| 5 | UserQuery | P -> S ; Ch -> S | | 5 | UserQuery | P -> S ; Ch -> S |
skipping to change at page 15, line 31 skipping to change at page 15, line 48
| 5 | UserQuery | P -> S ; Ch -> S | | 5 | UserQuery | P -> S ; Ch -> S |
| 6 | UserStatus | P <- S ; Ch <- S | | 6 | UserStatus | P <- S ; Ch <- S |
| 7 | FloorQuery | P -> S ; Ch -> S | | 7 | FloorQuery | P -> S ; Ch -> S |
| 8 | FloorStatus | 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 the length of the message
in 4-octet units, excluding the common header.
Payload Length: this 16-bit field contains length of the message in Conference ID: This 32-bit field identifies the conference the
4-octet units excluding the common header.
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 Transaction ID: This field contains a 16-bit value that allows users
to match a given message with its response. The value of the to match a given message with its response. The value of the
Transaction ID in server-initiated transactions is 0 (see Section 8). Transaction ID in server-initiated transactions is 0 (see Section 8).
User ID: this field contains a 16-bit value that uniquely identifies User ID: This field contains a 16-bit value that uniquely identifies
a participant within a conference. a participant within a conference.
The identity used by a participant in BFCP, which is carried in 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 the User ID field, is generally mapped to the identity used by the
same participant in the session establishment protocol (e.g., in same participant in the session establishment protocol (e.g., in
SIP). The way this mapping is performed is outside the scope of SIP). The way this mapping is performed is outside the scope of
this specification. this specification.
5.2. Attribute Format 5.2. Attribute Format
skipping to change at page 16, line 29 skipping to change at page 16, line 41
| Type |M| Length | | | Type |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Attribute Contents / / Attribute Contents /
/ / / /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Attribute format Figure 6: Attribute format
Type: this 7-bit field contains the type of the attribute. Each Type: This 7-bit field contains the type of the attribute. Each
attribute, identified by its type, has a particular format. The attribute, identified by its type, has a particular format. The
attribute formats defined are: attribute formats defined are:
Unsigned16: the contents of the attribute consist of a 16-bit Unsigned16: The contents of the attribute consist of a 16-bit
unsigned integer. unsigned integer.
OctetString16: the contents of the attribute consist of 16 bits of OctetString16: The contents of the attribute consist of 16 bits of
arbitrary data. arbitrary data.
OctetString: the contents of the attribute consist of arbitrary OctetString: The contents of the attribute consist of arbitrary
data of variable length. data of variable length.
Grouped: the contents of the attribute consist of a sequence of Grouped: The contents of the attribute consist of a sequence of
attributes. attributes.
Note that extension attributes defined in the future may define new Note that extension attributes defined in the future may define
attribute formats. new attribute formats.
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 | PRIORITY | OctetString16 | | 4 | PRIORITY | OctetString16 |
skipping to change at page 17, line 24 skipping to change at page 17, line 35
| 7 | ERROR-INFO | OctetString | | 7 | ERROR-INFO | OctetString |
| 8 | PARTICIPANT-PROVIDED-INFO | OctetString | | 8 | PARTICIPANT-PROVIDED-INFO | OctetString |
| 9 | STATUS-INFO | OctetString | | 9 | STATUS-INFO | OctetString |
| 10 | SUPPORTED-ATTRIBUTES | OctetString | | 10 | SUPPORTED-ATTRIBUTES | OctetString |
| 11 | SUPPORTED-PRIMITIVES | OctetString | | 11 | SUPPORTED-PRIMITIVES | OctetString |
| 12 | USER-DISPLAY-NAME | OctetString | | 12 | USER-DISPLAY-NAME | OctetString |
| 13 | USER-URI | OctetString | | 13 | USER-URI | OctetString |
| 14 | BENEFICIARY-INFORMATION | Grouped | | 14 | BENEFICIARY-INFORMATION | Grouped |
| 15 | FLOOR-REQUEST-INFORMATION | Grouped | | 15 | FLOOR-REQUEST-INFORMATION | Grouped |
| 16 | REQUESTED-BY-INFORMATION | Grouped | | 16 | REQUESTED-BY-INFORMATION | Grouped |
| 17 | FLOOR-REQUEST-STATUS | Grouped |
| 18 | OVERALL-REQUEST-STATUS | 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. The 'M' bit is
significant for extension attributes defined in other documents only.
All attributes specified in this document MUST be understood by the
receiver so that the setting of the 'M' bit is irrelevant for these.
In all other cases, the unrecognised attribute is ignored but the
message is processed.
Length: this 8-bit field contains the length of the attribute in Length: This 8-bit field contains the length of the attribute in
octets, excluding any padding defined for specific attributes. The octets, excluding any padding defined for specific attributes. The
Type, 'M' bit, and Length fields are included. The Length in grouped length of attributes that are not grouped includes the Type, 'M' bit,
attributes is the length of the grouped attribute itself (including and Length fields. The Length in grouped attributes is the length of
Type, 'M' bit, and Length fields) plus the total length (including the grouped attribute itself (including Type, 'M' bit, and Length
padding) of all the included attributes. fields) plus the total length (including padding) of all the included
attributes.
Attribute Contents: the contents of the different attributes are Attribute Contents: The contents of the different attributes are
defined in the following sections. defined in the following sections.
5.2.1. BENEFICIARY-ID 5.2.1. BENEFICIARY-ID
The following is the format of the BENEFICIARY-ID attribute. The following is the format of the BENEFICIARY-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 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 |
skipping to change at page 18, line 4 skipping to change at page 18, line 21
5.2.1. BENEFICIARY-ID 5.2.1. BENEFICIARY-ID
The following is the format of the BENEFICIARY-ID attribute. The following is the format of the BENEFICIARY-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 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 and of the User Note that although the formats of the Beneficiary ID and of the
ID field in the common header are similar, their semantics are User ID field in the common header are similar, their semantics
different. The Beneficiary ID is used in third-party floor requests are different. The Beneficiary ID is used in third-party floor
and to request information about a particular participant. requests and to request information about a particular
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FLOOR-ID format Figure 8: FLOOR-ID format
Floor ID: this field contains a 16-bit value that uniquely identifies Floor ID: This field contains a 16-bit value that uniquely identifies
a floor within a conference. a floor within a conference.
5.2.3. FLOOR-REQUEST-ID 5.2.3. FLOOR-REQUEST-ID
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 identifies 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. PRIORITY 5.2.4. 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 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: PRIORITY format Figure 10: 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
Senders SHOULD NOT use values higher than 4 in this field. Receivers Table 3. Senders SHOULD NOT use values higher than 4 in this field.
MUST treat values higher than 4 as if the value received had been 4 Receivers MUST treat values higher than 4 as if the value received
(Highest). The default priority value when the PRIORITY attribute is were 4 (Highest). The default priority value when the PRIORITY
missing is 2 (Normal). attribute is missing is 2 (Normal).
+-------+----------+ +-------+----------+
| Value | Priority | | Value | Priority |
+-------+----------+ +-------+----------+
| 0 | Lowest | | 0 | Lowest |
| 1 | Low | | 1 | Low |
| 2 | Normal | | 2 | Normal |
| 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.5. REQUEST-STATUS 5.2.5. 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 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: REQUEST-STATUS format Figure 11: 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 |
| 4 | Denied | | 4 | Denied |
| 5 | Cancelled | | 5 | Cancelled |
| 6 | Released | | 6 | Released |
| 7 | Revoked | | 7 | Revoked |
+-------+-----------+ +-------+-----------+
Table 4: Request Status values Table 4: Request Status values
Queue Position: this 8-bit field contains, when applicable, the Queue Position: This 8-bit field contains, when applicable, the
position of the floor request in the floor request queue at the position of the floor request in the floor request queue at the
server. If the Request Status value is different from Accepted, the server. If the Request Status value is different from Accepted, if
floor control server does not implement a floor request queue, or the the floor control server does not implement a floor request queue, or
floor control server does not want to provide the client with this if the floor control server does not want to provide the client with
information, all the bits of this field SHOULD be set to zero. this information, all the bits of this field SHOULD be set to zero.
A floor request is in Pending state if the floor control server needs 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.6. ERROR-CODE 5.2.6. ERROR-CODE
The following is the format of the ERROR-CODE attribute. The following is the format of the ERROR-CODE attribute.
skipping to change at page 20, line 49 skipping to change at page 21, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Error Specific Details | | Error Specific Details |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ERROR-CODE format Figure 12: 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. If an error code is not recognised by the receiver,
then the receiver MUST assume that an error exists, and therefore
that the message is processed, but the nature of the error is
unclear.
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 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 | Unknown Primitive | | 3 | Unknown Primitive |
| 4 | Unknown Mandatory Attribute | | 4 | Unknown Mandatory Attribute |
| 5 | Unauthorized Operation | | 5 | Unauthorized Operation |
| 6 | Invalid Floor ID | | 6 | Invalid Floor ID |
skipping to change at page 21, line 26 skipping to change at page 21, line 50
| | Floor Requests for this Floor | | | Floor Requests for this Floor |
| 9 | Use TLS | | 9 | Use TLS |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 5: Error Code meaning Table 5: 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 4 (Unknown Mandatory Attribute). this document, only for Error Code 4 (Unknown Mandatory Attribute).
See Section 5.2.6.1 for its definition. See Section 5.2.6.1 for its definition.
Padding: one, two, or three octets of padding added so that the Padding: One, two, or three octets 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.6.1. Error Specific Details for Error Code 4 5.2.6.1. Error-Specific Details for Error Code 4
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 4. Error Code 4.
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 13: Unknown attributes format Figure 13: 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.7. ERROR-INFO 5.2.7. 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 0 1 1 1|M| Length | | |0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: ERROR-INFO format Figure 14: ERROR-INFO format
Text: this field contains UTF-8 [6] encoded text. Text: This field contains UTF-8 [6] 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 this 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 octets of padding added so that the Padding: One, two, or three octets 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.8. PARTICIPANT-PROVIDED-INFO 5.2.8. 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.
skipping to change at page 23, line 18 skipping to change at page 23, line 34
|0 0 0 1 0 0 0|M| Length | | |0 0 0 1 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: PARTICIPANT-PROVIDED-INFO format Figure 15: PARTICIPANT-PROVIDED-INFO format
Text: this field contains UTF-8 [6] encoded text. Text: This field contains UTF-8 [6] encoded text.
Padding: one, two, or three octets of padding added so that the Padding: One, two, or three octets 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.9. STATUS-INFO 5.2.9. 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
skipping to change at page 23, line 43 skipping to change at page 24, line 22
|0 0 0 1 0 0 1|M| Length | | |0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: STATUS-INFO format Figure 16: STATUS-INFO format
Text: this field contains UTF-8 [6] encoded text. Text: This field contains UTF-8 [6] 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 this 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 octets of padding added so that the Padding: One, two, or three octets 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.10. SUPPORTED-ATTRIBUTES 5.2.10. 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 0 1 0|M| Length | Supported Attribute | |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Attribute | Supported Attribute | | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: SUPPORTED-ATTRIBUTES format Figure 17: SUPPORTED-ATTRIBUTES format
Supp. Attr.: These fields contain the Types of the attributes that
are supported by the floor control server in the following format:
Supported Attribute: these fields contain the Types of the attributes R: Reserved: This bit MUST be set to zero upon transmission and MUST
that are supported by the floor control server. be ignored upon reception.
Padding: two octets of padding added so that the contents of the Padding: Two octets 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.11. SUPPORTED-PRIMITIVES 5.2.11. SUPPORTED-PRIMITIVES
The following is the format of the SUPPORTED-PRIMITIVES attribute. The following is the format of the SUPPORTED-PRIMITIVES attribute.
skipping to change at page 25, line 20 skipping to change at page 25, line 36
| Primitive | Primitive | Primitive | Primitive | | Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SUPPORTED-PRIMITIVES format Figure 18: 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 octets of padding added so that the Padding: One, two, or three octets 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.12. USER-DISPLAY-NAME 5.2.12. 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.
skipping to change at page 25, line 48 skipping to change at page 26, line 22
|0 0 0 1 1 0 0|M| Length | | |0 0 0 1 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: USER-DISPLAY-NAME format Figure 19: 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 octets of padding added so that the Padding: One, two, or three octets 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.13. USER-URI 5.2.13. 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
skipping to change at page 26, line 25 skipping to change at page 26, line 47
|0 0 0 1 1 0 1|M| Length | | |0 0 0 1 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: USER-URI format Figure 20: USER-URI format
Text: this field contains the UTF-8 encoded user's contact URI. That Text: This field contains the UTF-8 encoded user's contact URI, that
is, the URI used by the user to set up the resources (e.g., media is, the URI used by the user to set up the resources (e.g., media
streams) that are controlled by BFCP. For example, in the context of streams) that are controlled by BFCP. For example, in the context of
a conference set up by SIP, the USER-URI attribute would carry the a conference set up by SIP, the USER-URI attribute would carry the
SIP URI of the user. SIP URI of the user.
Messages containing a user's URI in a USER-URI attribute also Messages containing a user's URI in a USER-URI attribute also
contain the user's User ID. This way, a client receiving such a contain the user's User ID. This way, a client receiving such a
message can correlate the user's URI (e.g., the SIP URI the user message can correlate the user's URI (e.g., the SIP URI the user
used to join a conference) with the user's User ID. used to join a conference) with the user's User ID.
Padding: one, two, or three octets of padding added so that the Padding: One, two, or three octets 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.14. BENEFICIARY-INFORMATION 5.2.14. 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 0 1 1 1 0|M| Length | Beneficiary ID | |0 0 0 1 1 1 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: BENEFICIARY-INFORMATION-HEADER format Figure 21: 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) [2] of the The following is the ABNF (Augmented Backus-Naur Form) [2] 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]
skipping to change at page 27, line 42 skipping to change at page 28, line 13
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 0 1 1 1 1|M| Length | Floor Request ID | |0 0 0 1 1 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format
Floor Request ID: this field contains a 16-bit value that identifies 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) [OVERALL-REQUEST-STATUS]
1*(FLOOR-ID) 1*(FLOOR-REQUEST-STATUS)
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION] [REQUESTED-BY-INFORMATION]
[PRIORITY] [PRIORITY]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 24: FLOOR-REQUEST-INFORMATION format Figure 24: FLOOR-REQUEST-INFORMATION format
5.2.16. REQUESTED-BY-INFORMATION 5.2.16. 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 0 0 0|M| Length | Requested-by ID | |0 0 1 0 0 0 0|M| Length | Requested-by ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: REQUESTED-BY-INFORMATION-HEADER format Figure 25: 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 26: REQUESTED-BY-INFORMATION format Figure 26: REQUESTED-BY-INFORMATION format
5.2.17. FLOOR-REQUEST-STATUS
The FLOOR-REQUEST-STATUS attribute is a grouped attribute that
consists of a header, which is referred to as
FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes.
The following is the format of the FLOOR-REQUEST-STATUS-HEADER:
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 1 0 0 0 1|M| Length | Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: FLOOR-REQUEST-STATUS-HEADER format
Floor ID: this field contains a 16-bit value that uniquely identifies
a floor within a conference.
The following is the ABNF of the FLOOR-REQUEST-STATUS grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.)
FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
Figure 28: FLOOR-REQUEST-STATUS format
5.2.18. OVERALL-REQUEST-STATUS
The OVERALL-REQUEST-STATUS attribute is a grouped attribute that
consists of a header, which is referred to as
OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes.
The following is the format of the OVERALL-REQUEST-STATUS-HEADER:
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 1 0 0 1 0|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: OVERALL-REQUEST-STATUS-HEADER format
Floor Request ID: this field contains a 16-bit value that identifies
a floor request at the floor control server.
The following is the ABNF of the OVERALL-REQUEST-STATUS grouped
attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
may be defined in the future.)
OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER)
[REQUEST-STATUS]
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE]
Figure 30: OVERALL-REQUEST-STATUS 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)
[2] of the BFCP messages. Extension attributes that may be defined [2] 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 = (COMMON-HEADER) FloorRequest = (COMMON-HEADER)
*(FLOOR-ID) 1*(FLOOR-ID)
[BENEFICIARY-ID] [BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
[PRIORITY] [PRIORITY]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 27: FloorRequest format Figure 31: 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 = (COMMON-HEADER) FloorRelease = (COMMON-HEADER)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 28: FloorRelease format Figure 32: FloorRelease format
5.3.3. FloorRequestQuery 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 FloorRequestQuery message to the floor control request by sending a FloorRequestQuery message to the floor control
server. The following is the format of the FloorRequestQuery server. The following is the format of the FloorRequestQuery
message: message:
FloorRequestQuery = (COMMON-HEADER) FloorRequestQuery = (COMMON-HEADER)
(FLOOR-REQUEST-ID) (FLOOR-REQUEST-ID)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 29: FloorRequestQuery format Figure 33: FloorRequestQuery format
5.3.4. FloorRequestStatus 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
FloorRequestStatus messages. The following is the format of the FloorRequestStatus messages. The following is the format of the
FloorRequestStatus message: FloorRequestStatus message:
FloorRequestStatus = (COMMON-HEADER) FloorRequestStatus = (COMMON-HEADER)
(FLOOR-REQUEST-INFORMATION) (FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 30: FloorRequestStatus format Figure 34: FloorRequestStatus format
5.3.5. UserQuery 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 UserQuery message to the floor control server. The sending a UserQuery message to the floor control server. The
following is the format of the UserQuery message: following is the format of the UserQuery message:
UserQuery = (COMMON-HEADER) UserQuery = (COMMON-HEADER)
[BENEFICIARY-ID] [BENEFICIARY-ID]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 31: UserQuery format Figure 35: UserQuery format
5.3.6. UserStatus 5.3.6. UserStatus
The floor control server provide information about participants and The floor control server provides 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 UserStatus messages. The following is the format of by sending them UserStatus messages. The following is the format of
the UserStatus message: the UserStatus message:
UserStatus = (COMMON-HEADER) UserStatus = (COMMON-HEADER)
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
1*(FLOOR-REQUEST-INFORMATION) *(FLOOR-REQUEST-INFORMATION)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 32: UserStatus format Figure 36: UserStatus format
5.3.7. FloorQuery 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 FloorQuery 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:
FloorQuery = (COMMON-HEADER) FloorQuery = (COMMON-HEADER)
*(FLOOR-ID) *(FLOOR-ID)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 33: FloorQuery format Figure 37: FloorQuery format
5.3.8. FloorStatus 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 FloorStatus messages. The following is the format of the them FloorStatus messages. The following is the format of the
FloorStatus message: FloorStatus message:
FloorStatus = (COMMON-HEADER) FloorStatus = (COMMON-HEADER)
(FLOOR-ID) *1(FLOOR-ID)
*[FLOOR-REQUEST-INFORMATION] *[FLOOR-REQUEST-INFORMATION]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 34: FloorStatus format Figure 38: 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 = (COMMON-HEADER) ChairAction = (COMMON-HEADER)
1*(FLOOR-ID) (FLOOR-REQUEST-INFORMATION)
(FLOOR-REQUEST-ID)
(REQUEST-STATUS)
[STATUS-INFO]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 35: ChairAction format Figure 39: 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 = (COMMON-HEADER) ChairActionAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 36: ChairActionAck format Figure 40: 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 liveliness 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 = (COMMON-HEADER) Hello = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 37: Hello format Figure 41: 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 = (COMMON-HEADER) HelloAck = (COMMON-HEADER)
(SUPPORTED-PRIMITIVES) (SUPPORTED-PRIMITIVES)
(SUPPORTED-ATTRIBUTES) (SUPPORTED-ATTRIBUTES)
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 38: HelloAck format Figure 42: 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 = (COMMON-HEADER) Error = (COMMON-HEADER)
(ERROR-CODE) (ERROR-CODE)
[ERROR-INFO] [ERROR-INFO]
*[EXTENSION-ATTRIBUTE] *[EXTENSION-ATTRIBUTE]
Figure 39: Error format Figure 43: 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
with a given floor control server within a conference. Nevertheless, with a given floor control server within a conference. Nevertheless,
if the same physical box handles different clients (e.g., a floor if the same physical box handles different clients (e.g., a floor
chair and a floor participant), which are identified by different chair and a floor participant), which are identified by different
User IDs, a separate connection per client is allowed. User IDs, a separate connection per client is allowed.
If a BFCP entity (a client or a floor control server) receives data If a BFCP entity (a client or a floor control server) receives data
from TCP that cannot be parsed the entity MUST close the TCP from TCP that cannot be parsed, the entity MUST close the TCP
connection using a RESET call (send a TCP RST bit) and the connection connection, and the connection SHOULD be reestablished. Similarly,
SHOULD be reestablished. Similarly, if a TCP connection cannot if a TCP connection cannot deliver a BFCP message and times out, the
deliver a BFCP message and times out, the TCP connection SHOULD be TCP connection SHOULD be reestablished.
reestablished.
The way connection reestablishment is handled depends on how the The way connection reestablishment is handled depends on how the
client obtains information to contact the floor control server (e.g., client obtains information to contact the floor control server (e.g.,
using an offer/answer exchange [7]). Once the TCP connection is using an SDP offer/answer exchange [7]). Once the TCP connection is
reestablished, the client MAY resend those messages it did not get a reestablished, the client MAY resend those messages for which it did
response for from the floor control server. not get a response from the floor control server.
If a floor control server detects that the TCP connection towards one If a floor control server detects that the TCP connection towards one
of the floor participants is lost, it is up to the local policy of of the floor participants is lost, it is up to the local policy of
the floor control server what to do with the pending floor requests the floor control server what to do with the pending floor requests
of the floor participant. In any case, it is RECOMMENDED that the of the floor participant. In any case, it is RECOMMENDED that the
floor control server keeps the floor requests (i.e., does not cancel floor control server keep the floor requests (i.e., that it does not
them) while the TCP connection is reestablished. cancel them) while the TCP connection is reestablished.
If a client wishes to end its BFCP connection with a floor control If a client wishes to end its BFCP connection with a floor control
server, the client closes (i.e., a graceful close) the TCP connection server, the client closes (i.e., a graceful close) the TCP connection
towards the floor control server. If a floor control server wishes towards the floor control server. If a floor control server wishes
to end its BFCP connection with a client (e.g., the Focus of the to end its BFCP connection with a client (e.g., the Focus of the
conference informs the floor control server that the client has been conference informs the floor control server that the client has been
kicked out from the conference), the floor control server closes kicked out from the conference), the floor control server closes
(i.e., a graceful close) the TCP connection towards the client. (i.e., a graceful close) the TCP connection towards the client.
7. Lower-Layer Security 7. Lower-Layer Security
BFCP relies on lower-layer security mechanisms to provide replay and BFCP relies on lower-layer security mechanisms to provide replay and
integrity protection, and confidentiality. BFCP floor control integrity protection and confidentiality. BFCP floor control servers
servers and clients (which include both floor participants and floor and clients (which include both floor participants and floor chairs)
chairs) MUST support TLS [3]. Any BFCP entity MAY support other MUST support TLS [3]. Any BFCP entity MAY support other security
security mechanisms. mechanisms.
BFCP entities MUST support, at a minimum, the TLS BFCP entities MUST support, at a minimum, the TLS
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5]. TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5].
Which party, the client or the floor control server, acts as the TLS Which party, the client or the floor control server, acts as the TLS
server depends on how the underlying TCP connection is established. server depends on how the underlying TCP connection is established.
For example, when the TCP connection is established using an offer/ For example, when the TCP connection is established using an SDP
answer exchange [7], the answerer (which may be the client or the offer/answer exchange [7], the answerer (which may be the client or
floor control server) always acts as the TLS server. the floor control server) always acts as the TLS server.
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 in its common the client. The request carries a Transaction ID in its common
header which the floor control server copies into the response. header, which the floor control server copies into the response.
Clients use Transaction ID values to match responses with previously- Clients use Transaction ID values to match responses with previously
issued 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, their Transaction ID is set to 0. response, their Transaction ID is set to 0.
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 common header of the message to the Conference Conference ID in the common header of the message to the Conference
ID 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 common header to The client MUST set the Transaction ID value in the common header to
a number which is different to 0 and which MUST NOT be reused in a number that is different from 0 and that MUST NOT be reused in
another message from the client until a response from the server is another message from the client until a response from the server is
received for the transaction. The client uses the Transaction ID received for the transaction. The client uses the Transaction ID
value to match this message with the response from the floor control value to match this message with the response from the floor control
server. 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, and the transaction MUST copy the Conference ID, the Transaction ID, and the
User ID from the request received from the client into the response. User ID from the request received from the client into the response.
skipping to change at page 35, line 24 skipping to change at page 37, line 5
In addition to authenticating BFCP messages, floor control servers In addition to authenticating BFCP messages, floor control servers
need to authorize them. On receiving an authenticated BFCP message, need to authorize them. On receiving an authenticated BFCP message,
the floor control server checks whether the client sending the the floor control server checks whether the client sending the
message is authorized. If the client is not authorized to perform message is authorized. If the client is not authorized to perform
the operation being requested, the floor control server generates an the operation being requested, the floor control server generates an
Error message, as described in Section 13.8, with an Error code with Error message, as described in Section 13.8, with an Error code with
a value of 5 (Unauthorized Operation). Messages from a client that a value of 5 (Unauthorized Operation). Messages from a client that
cannot be authorized MUST NOT be processed further. cannot be authorized MUST NOT be processed further.
9.1. TLS-based Mutual Authentication 9.1. TLS-Based Mutual Authentication
BFCP supports TLS-based mutual authentication between clients and BFCP supports TLS-based mutual authentication between clients and
floor control servers. BFCP assumes that there is an integrity- floor control servers. BFCP assumes that there is an integrity-
protected channel between the client and the floor control server protected channel between the client and the floor control server
that can be used to exchange their self-signed certificates or, more that can be used to exchange their self-signed certificates or, more
commonly, the fingerprints of these certificates. These certificates commonly, the fingerprints of these certificates. These certificates
are used at TLS establishment time. are used at TLS establishment time.
The implementation of such an integrity-protected channel using The implementation of such an integrity-protected channel using
SIP and the offer/answer model is described in [7]. SIP and the SDP offer/answer model is described in [7].
BFCP messages received over an authenticated TLS connection are BFCP messages received over an authenticated TLS connection are
considered authenticated. A floor control server that receives a considered authenticated. A floor control server that receives a
BFCP message over TCP (no TLS) can request the use of TLS by BFCP message over TCP (no TLS) can request the use of TLS by
generating an Error message, as described in Section 13.8, with an generating an Error message, as described in Section 13.8, with an
Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore
unauthenticated messages. unauthenticated messages.
Note that future extensions may define additional authentication Note that future extensions may define additional authentication
mechanisms that may not require an initial integrity-protected mechanisms that may not require an initial integrity-protected
skipping to change at page 36, line 36 skipping to change at page 38, line 20
are optional. are optional.
The floor participant sets the Conference ID and the Transaction ID The floor participant sets the Conference ID and the Transaction ID
in the common header following the rules given in Section 8.1. in the common header following the rules given in Section 8.1.
The floor participant sets the User ID in the common header to the The floor participant sets the User ID in the common header to the
floor participant's identifier. This User ID will be used by the floor participant's identifier. This User ID will be used by the
floor control server to authenticate and authorize the request. If floor control server to authenticate and authorize the request. If
the sender of the FloorRequest message (identified by the User ID) is the sender of the FloorRequest message (identified by the User ID) is
not the participant that would eventually get the floor (i.e., a not the participant that would eventually get the floor (i.e., a
third party floor request), the sender SHOULD add a BENEFICIARY-ID third-party floor request), the sender SHOULD add a BENEFICIARY-ID
attribute to the message identifying the 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 the User ID in the common single 16-bit value that can be used in the User ID in the common
header and in several attributes: BENEFICIARY-ID, BENEFICIARY- header and in several attributes: BENEFICIARY-ID, BENEFICIARY-
INFORMATION, and REQUESTED-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 attribute, the floor control server will treat all the floor
floor requests as an atomic package. That is, the floor control requests as an atomic package. That is, the floor control server
server will either grant or deny all the floors in the FloorRequest 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
Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for
human consumption. human consumption.
The floor participant may request the server to handle the floor The floor participant may request that the server handle the floor
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 a response to
response to the FloorRequest message if the message from the floor the FloorRequest message if the message from the floor control server
control server has the same Conference ID, Transaction ID, and User has the same Conference ID, Transaction ID, and User ID as the
ID as the FloorRequest message, as described in Section 8.1. On FloorRequest message, as described in Section 8.1. On receiving such
receiving such a response, the floor participant follows the rules in a response, the floor participant follows the rules in Section 9 that
Section 9 which relate to floor control server authentication. relate to floor control server authentication.
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 FloorRequestStatus 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 FloorRequestStatus message from the floor control server. the first FloorRequestStatus message from the floor control server.
Subsequent FloorRequestStatus 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
FloorRequestStatus message. This way, the floor participant can FloorRequestStatus message. This way, the floor participant can
associate subsequent incoming FloorRequestStatus 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 FloorRequestStatus messages received from the floor control the FloorRequestStatus messages received from the floor control
server. This attribute is a grouped attribute and, as such, it server. This attribute is a grouped attribute, and as such it
includes a number of attributes that provide information about the includes a number of attributes that provide information about the
floor request. floor request.
The REQUEST-STATUS attribute. If the Request Status value is The OVERALL-REQUEST-STATUS attribute provides information about the
overall status of the floor request. 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. If the floor request
value is unknown, then the response is still processed. However, no
meaningful value can be reported to the user.
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. that the floor participant MAY display to the user.
The FLOOR-REQUEST-STATUS attributes provide information about the
status of the floor request as it relates to a particular floor. The
STATUS-INFO attribute, if present, provides extra information that
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
INFORMATION attribute may be not be present in FloorRequestStatus REQUESTED-BY-INFORMATION attribute need not be present in
messages received by the floor participant that requested the floor FloorRequestStatus messages received by the floor participant that
because this floor participant is already identified by the User ID requested the floor, as this floor participant is already identified
in the common header. by the User ID 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 38, line 38 skipping to change at page 40, line 31
are optional. are optional.
The floor participant sets the Conference ID and the Transaction ID The floor participant sets the Conference ID and the Transaction ID
in the common header following the rules given in Section 8.1. The in the common header following the rules given in Section 8.1. The
floor participant sets the User ID in the common header to the floor floor participant sets the User ID in the common header to the floor
participant's identifier. This User ID will be used by the floor participant's identifier. This User ID will be used by the floor
control server to authenticate and authorize the 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
message is cancelling. message is cancelling.
Note that if the floor participant requested several floors as an Note that if the floor participant requested several floors as an
atomic operation (i.e., in a single FloorRequest message), all the atomic operation (i.e., in a single FloorRequest message), all the
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 a response to
response to the FloorRelease message if the message from the floor the FloorRelease message if the message from the floor control server
control server has the same Conference ID, Transaction ID, and User has the same Conference ID, Transaction ID, and User ID as the
ID as the FloorRequest message, as described in Section 8.1. On FloorRequest message, as described in Section 8.1. On receiving such
receiving such a response, the floor participant follows the rules in a response, the floor participant follows the rules in Section 9 that
Section 9 which relate to floor control server authentication. relate to floor control server authentication.
If the response is a FloorRequestStatus 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 OVERALL-REQUEST-STATUS attribute (within the FLOOR-
INFORMATION grouped attribute) will be Cancelled or Released. REQUEST-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 FloorRequestStatus 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
FloorRequestStatus 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, as 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 and the Transaction ID in the The floor chair sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The floor common header following the rules given in Section 8.1. The floor
participant sets the User ID in the common header to the floor chair sets the User ID in the common header to the floor
participant's identifier. This User ID will be used by the floor participant's identifier. This User ID will be used by the floor
control server to authenticate and authorize the request. 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 the FLOOR-REQUEST-STATUS attributes and the floor
identified by a FLOOR-REQUEST-ID attribute, which are carried in the request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which
ChairAction message. are carried in the 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
on different floor chairs, each floor chair will grant its floor different floor chairs, each floor chair will grant its floor within
within the floor request. Once both chairs have granted their the floor request. Once both chairs have granted their floor, the
floor, the floor control server will grant the floor request as a floor control server will grant the floor request as a whole. On the
whole. On the other hand, if one of the floor chairs denies its other hand, if one of the floor chairs denies its floor, the floor
floor, the floor control server will deny the floor request as a control server will deny the floor request as a whole, regardless of
whole, regardless of the other floor chair's decision. the other floor chair's decision.
The floor chair provides the new status for one or more floors within The floor chair provides the new status of the floor request as it
the floor request using a REQUEST-STATUS attribute. If the new relates to a particular floor using a FLOOR-REQUEST-STATUS attribute.
status of the floor request is Accepted, the floor chair MAY use the If the new status of the floor request is Accepted, the floor chair
Queue Position field to provide a queue position for the floor MAY use the Queue Position field to provide a queue position for the
request. If the floor chair does not wish to provide a queue floor request. If the floor chair does not wish to provide a queue
position, all the bits of the Queue Position field SHOULD be set to position, all the bits of the Queue Position field SHOULD be set to
zero. The floor chair SHOULD use the Status Revoked to revoke a zero. The floor chair SHOULD use the Status Revoked to revoke a
floor that was granted (i.e., Granted status) and the Status Denied floor that was granted (i.e., Granted status) and SHOULD use the
to reject floor requests in any other status (e.g., Pending and Status Denied to reject floor requests in any other status (e.g.,
Accepted). Pending and Accepted).
Note that a floor request may involve several floors and that a The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the
ChairAction message may only deal with a subset of these floors ChairAction message to provide a new overall status for the floor
(e.g., if a single floor chair is not authorized to manage all the request. If the new overall status of the floor request is Accepted,
floors). In this case, the REQUEST-STATUS that the floor chair the floor chair MAY use the Queue Position field to provide a queue
provides in the ChairAction message might not be the actual status position for the floor request.
that the floor request gets at the server. The floor control
server will combine the instructions received from the different
floor chairs to come up with the actual status of the floor
request.
The floor chair may use a STATUS-INFO attribute to state the reason Note that a particular floor control server may implement a
different queue for each floor containing all the floor requests
that relate to that particular floor, a general queue for all
floor requests, or both. Also note that a floor request may
involve several floors and that a ChairAction message may only
deal with a subset of these floors (e.g., if a single floor chair
is not authorized to manage all the floors). In this case, the
floor control server will combine the instructions received from
the different floor chairs in FLOOR-REQUEST-STATUS attributes to
come up with the overall status of the floor request.
Note that, while the action of a floor chair may communicate
information in the OVERALL-REQUEST-STATUS attribute, the floor
control server may override, modify, or ignore this field's
content.
The floor chair may use STATUS-INFO attributes to state the reason
why the floor or floors are being accepted, granted, or revoked. The why the floor or floors are being accepted, granted, or revoked. The
Text in the STATUS-INFO attribute is intended for human consumption. Text in the STATUS-INFO attribute is intended for human consumption.
11.2. Receiving a Response 11.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 a response to
response to the ChairAction message if the message from the server the ChairAction message if the message from the server has the same
has the same Conference ID, Transaction ID, and User ID as the Conference ID, Transaction ID, and User ID as the ChairAction
ChairAction message, as described in Section 8.1. On receiving such message, as described in Section 8.1. On receiving such a response,
a response, the floor chair follows the rules in Section 9 which the floor chair follows the rules in Section 9 that relate to floor
relate to floor control server authentication. control server authentication.
A ChairActionAck message from the floor control server confirms that A ChairActionAck message from the floor control server confirms that
the floor control server has accepted the ChairAction message. An the floor control server has accepted the ChairAction message. An
Error message indicates that the floor control server could not Error message indicates that the floor control server could not
process the ChairAction message for some reason, which is described process the ChairAction message for some reason, which is described
in the Error message. in the Error message.
12. General Client Operations 12. General Client Operations
This section specifies operations that can be performed by any This section specifies operations that can be performed by any
skipping to change at page 41, line 38 skipping to change at page 43, line 41
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 and the Transaction ID in the The client sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The client common header following the rules given in Section 8.1. The client
sets the User ID in the common header to the client's identifier. sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate This User ID will be used by the floor control server to authenticate
and authorize the request. 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 of these floors. If the client does
want to receive information about a particular floor any longer, it not want to receive information about a particular floor any longer,
sends a new FloorQuery message removing the FLOOR-ID of this floor. it sends a new FloorQuery message removing the FLOOR-ID of this
If the client does not want to receive information about any floor floor. If the client does not want to receive information about any
any longer, it sends a FloorQuery message with no FLOOR-ID attribute. floor any longer, it sends a FloorQuery message with no FLOOR-ID
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 a response to
response to the FloorQuery message if the message from the floor the FloorQuery message if the message from the floor control server
control server has the same Conference ID, Transaction ID, and User has the same Conference ID, Transaction ID, and User ID as the
ID as the FloorRequest message, as described in Section 8.1. On FloorRequest message, as described in Section 8.1. On receiving such
receiving such a response, the client follows the rules in Section 9 a response, the client follows the rules in Section 9 that relate to
which relate to floor control server authentication. floor control server authentication.
On reception of the FloorQuery message, the floor control server will On reception of the FloorQuery message, the floor control server will
respond with a FloorStatus message or with an Error message. If the respond with a FloorStatus message or with an Error message. If the
response is a FloorStatus message, it will contain information about response is a FloorStatus message, it will contain information about
one of the floors the client requested information about. If the one of the floors the client requested information about. If the
client did not include any FLOOR-ID attribute in its FloorQuery client did not include any FLOOR-ID attribute in its FloorQuery
message (i.e., the client does not want to receive information about message (i.e., the client does not want to receive information about
any floor any longer), the FloorStatus message from the floor control any floor any longer), the FloorStatus message from the floor control
server will not include any FLOOR-ID attribute either. server will not include any FLOOR-ID attribute either.
FloorStatus messages which carry information about a floor contain a FloorStatus messages that 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,
FloorStatus 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 requests 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 FloorStatus, the floor control server will continue After the first FloorStatus, the floor control server will continue
sending FloorStatus 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 FloorRequestQuery message to the floor control request by sending a FloorRequestQuery message to the floor 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 message, a floor control server may choose to return
FloorRequestStatus messages only when the floor request changes its FloorRequestStatus messages only when the floor request changes its
state (e.g., from Accepted to Granted), but not when the floor state (e.g., from Accepted to Granted), but not when the floor
request advances in its queue. In this situation, if the user request advances in its queue. In this situation, if the user
requests it, the floor participant can use a FloorRequestQuery requests it, the floor participant can use a FloorRequestQuery
message to poll the floor control server for the status of the floor message to poll the floor control server for the status of the floor
skipping to change at page 43, line 19 skipping to change at page 45, line 23
common header following the rules given in Section 8.1. The client common header following the rules given in Section 8.1. The client
sets the User ID in the common header to the client's identifier. sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate This User ID will be used by the floor control server to authenticate
and authorize the request. 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 a response to
response to the FloorRequestQuery message if the message from the the FloorRequestQuery message if the message from the floor control
floor control server has the same Conference ID, Transaction ID, and server has the same Conference ID, Transaction ID, and User ID as the
User ID as the FloorRequestQuery message, as described in FloorRequestQuery message, as described in Section 8.1. On receiving
Section 8.1. On receiving such a response, the client follows the such a response, the client follows the rules in Section 9 that
rules in Section 9 which relate to floor control server relate to floor control server authentication.
authentication.
If the response is a FloorRequestStatus 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 FloorRequestQuery message for some reason, which is not process the FloorRequestQuery message for some reason, which 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
skipping to change at page 44, line 5 skipping to change at page 46, line 7
requests related to this participant by sending a UserQuery message requests related to this participant by sending a UserQuery 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 floor requests associated to itself that still exist.
12.3.1. Sending a UserQuery Message 12.3.1. Sending a UserQuery Message
The ABNF in Section 5.3.5 describes the attributes that a UserQuery The ABNF in Section 5.3.5 describes the attributes that a UserQuery
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 and the Transaction ID in the The client sets the Conference ID and the Transaction ID in the
common header following the rules given in Section 8.1. The client common header following the rules given in Section 8.1. The client
sets the User ID in the common header to the client's identifier. sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate This User ID will be used by the floor control server to authenticate
and authorize the request. 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 UserQuery message (which is identified is not the client issuing the UserQuery message (which is identified
by the User ID in the common header of 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 a response to
response to the UserQuery message if the message from the floor the UserQuery message if the message from the floor control server
control server has the same Conference ID, Transaction ID, and User has the same Conference ID, Transaction ID, and User ID as the
ID as the UserQuery message, as described in Section 8.1. On UserQuery message, as described in Section 8.1. On receiving such a
receiving such a response, the client follows the rules in Section 9 response, the client follows the rules in Section 9 that relate to
which relate to floor control server authentication. floor control server authentication.
If the response is a UserStatus message, the client obtains If the response is a UserStatus message, the client obtains
information about the floor participant in a BENEFICIARY-INFORMATION information about the floor participant in a BENEFICIARY-INFORMATION
grouped attribute and about the status of the floor requests grouped attribute and about the status of the floor requests
associated with the floor participant in FLOOR-REQUEST-INFORMATION associated with the floor participant in FLOOR-REQUEST-INFORMATION
attributes. 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 UserQuery message for some reason, which is described not process the UserQuery message for some reason, which is described
in the Error message. in the Error message.
skipping to change at page 45, line 19 skipping to change at page 47, line 23
sets the User ID in the common header to the client's identifier. sets the User ID in the common header to the client's identifier.
This User ID will be used by the floor control server to authenticate This User ID will be used by the floor control server to authenticate
and authorize the request. 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. On receiving such a Hello message, as described in Section 8.1. On receiving such a
response, the client follows the rules in Section 9 which relate to response, the client follows the rules in Section 9 that relate to
floor control server authentication. floor control server authentication.
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 the Hello message successfully. The SUPPORTED-PRIMITVIES and
attribute indicates which attributes are supported by the server. SUPPORTED-ATTRIBUTES attributes indicate which primitives and
attributes, respectively, are supported by the server.
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 Hello message for some reason, which is described in not process the Hello message for some reason, which is described in
the Error message. the Error message.
13. Floor Control Server Operations 13. Floor Control Server Operations
This section specifies how floor control servers can perform This section specifies how floor control servers can perform
different operations, such as granting a floor, using the protocol different operations, such as granting a floor, using the protocol
elements described in earlier sections. elements described in earlier sections.
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
MUST check whether or not the value of the Conference ID matched an MUST check whether the value of the Primitive is supported. If it
existing conference. If it does not, the floor control server SHOULD does not, the floor control server SHOULD send an Error message, as
send an Error message, as described in Section 13.8, with Error code described in Section 13.8, with Error code 3 (Unknown Primitive).
1 (Conference does not Exist).
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
follows the rules in Section 9, which relate to the authentication of MUST check whether the value of the Conference ID matched an existing
conference. If it does not, the floor control server SHOULD send an
Error message, as described in Section 13.8, with Error code 1
(Conference does not Exist).
On reception of a message from a client, the floor control server
follows the rules in Section 9 that relate to the authentication of
the message. the message.
On reception of a message from a client, the floor control server On reception of a message from a client, the floor control server
MUST check whether or not it understands all the mandatory ( 'M' bit MUST check whether it understands all the mandatory ('M' bit set)
set) attributes in the message. If the floor control server does not attributes in the message. If the floor control server does not
understand all of them, the floor control server SHOULD send an Error understand all of them, the floor control server SHOULD send an Error
message, as described in Section 13.8, with Error code 2 message, as described in Section 13.8, with Error code 2
(Authentication Failed). The Error message SHOULD list the (Authentication Failed). The Error message SHOULD list the
attributes that were not understood. attributes that were not understood.
13.1. Reception of a FloorRequest Message 13.1. Reception of a FloorRequest Message
On reception of a FloorRequest message, the floor control server On reception of a FloorRequest message, the floor control server
follows the rules in Section 9 which relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRequest message, the and authorization. If while processing the FloorRequest 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.
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 8 (You have Already Reached the Maximum Number of Error Code 8 (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 FloorRequestStatus 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 FloorRequestStatus 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 OVERALL-REQUEST-
attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped
the first FloorRequestStatus message it generates. attribute) of the first FloorRequestStatus message it generates.
The policy a floor control server follows to grant or deny floors The policy that a floor control server follows to grant or deny
is outside the scope of this document. A given floor control floors is outside the scope of this document. A given floor
server may perform these decisions automatically while another may control server may perform these decisions automatically while
contact a human acting as a chair everytime a decision needs to be another may contact a human acting as a chair every time a
made. decision needs to be made.
The floor control server MUST copy the Conference ID, the Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRequest into the ID, and the User ID from the FloorRequest into the
FloorRequestStatus, 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 FloorRequestStatus. The attributes contained in attribute to the FloorRequestStatus. The attributes contained in
this 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 identifier 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 identifier will be used by the floor participant (or attribute. This identifier will be used by the floor participant (or
by a chair or chairs) to refer to this specific floor request in the by a chair or chairs) to refer to this specific floor request in the
future. future.
The floor control server MUST copy the FLOOR-ID attributes from the The floor control server MUST copy the Floor IDs in the FLOOR-ID
FloorRequest into the FLOOR-REQUEST-INFORMATION attribute. These attributes of the FloorRequest into the FLOOR-REQUEST-STATUS
FLOOR-ID attributes identify the floors being requested (i.e., the attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These
floors associated with this particular floor request). Floor IDs identify the floors being requested (i.e., the 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
INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped BENEFICIARY-INFORMATION attribute inside the
attribute. Additionally, the floor control server MAY provide the FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, the floor
display name and the URI of the beneficiary in this BENEFICIARY- control server MAY provide the display name and the URI of the
INFORMATION attribute. beneficiary in this BENEFICIARY-INFORMATION attribute.
The floor control server MAY provide information about the requester The floor control server MAY provide information about the requester
of the floor in a REQUESTED-BY-INFORMATION attribute inside the of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute. FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MAY copy (if present) the PRIORITY attribute The floor control server MAY copy (if present) the PARTICIPANT-
from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped PROVIDED-INFO attribute from the FloorRequest into the FLOOR-
attribute. Note that this attribute carries the priority requested REQUEST-INFORMATION grouped attribute.
by the participant. The priority the floor control server assigns to
the floor request depends on the priority requested by the Note that this attribute carries the priority requested by the
participant. The priority that the floor control server assigns
to the floor request depends on the priority requested by the
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
floor request. In that case, the floor control server would ignore for a floor request. In that case, the floor control server would
the priority requested by the participant. ignore 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
PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the
INFO grouped attribute. FLOOR-REQUEST-INFORMATION grouped attribute.
13.1.2. Generation of Subsequent FloorRequestStatus 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 OVERALL-REQUEST-
attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped
the first FloorRequestStatus message generated by the floor control attribute) of the first FloorRequestStatus message generated by the
server did not indicate any of these states, the floor control server floor control server did not indicate any of these states, the floor
will need to send subsequent FloorRequestStatus messages. control server 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 FloorRequestStatus messages with the server SHOULD send new FloorRequestStatus messages with the
appropriate Request Status. The floor control server MUST add a appropriate Request Status. The floor control server MUST add a
FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to
the one sent in the first FloorRequestStatus message to any new the one sent in the first FloorRequestStatus message to any new
FloorRequestStatus related to the same floor request. (The Floor FloorRequestStatus related to the same floor request. (The Floor
Request ID identifies the floor request the FloorRequestStatus Request ID identifies the floor request to which the
applies to.) FloorRequestStatus applies.)
The floor control server MUST set the Transaction ID of subsequent The floor control server MUST set the Transaction ID of subsequent
FloorRequestStatus messages to 0. FloorRequestStatus messages to 0.
The rate at which the floor control server sends The rate at which the floor control server sends
FloorRequestStatus messages is a matter of local policy. A floor FloorRequestStatus messages is a matter of local policy. A floor
control server may choose to send a new FloorRequestStatus message control server may choose to send a new FloorRequestStatus message
every time the floor request moves in the floor request queue every time the floor request moves in the floor request queue,
while another may choose to only send a new FloorRequestStatus while another may choose only to send a new FloorRequestStatus
message when the floor request 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 FloorRequestStatus 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 common 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 FloorRequestStatus 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 FloorRequestQuery Message 13.2. Reception of a FloorRequestQuery Message
On reception of a FloorRequestQuery message, the floor control server On reception of a FloorRequestQuery message, the floor control server
follows the rules in Section 9 which relate to client authentication follows the rules in Section 9 that relate to client authentication
and authorization. If while processing the FloorRequestQuery and authorization. If while processing the FloorRequestQuery
message, the floor control server encounters an error, it SHOULD message, the floor control server encounters an error, it SHOULD
generate an Error response following the procedures described in generate an Error response following the procedures described in
Section 13.8 Section 13.8.
The successful processing of a FloorRequestQuery message by a floor The successful processing of a FloorRequestQuery message by a floor
control server involves generating a FloorRequestStatus 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 Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRequestQuery message into the ID, and the User ID from the FloorRequestQuery message into the
FloorRequestStatus message, as described in Section 8.2. FloorRequestStatus message, as described in Section 8.2.
Additionally, the floor control server MUST add a FLOOR-REQUEST- Additionally, the floor control server MUST include information about
INFORMATION grouped attribute to the FloorRequestStatus. The the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute
attributes contained in this grouped attribute carry information to the FloorRequestStatus.
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 FloorRequestQuery message into FLOOR-REQUEST-ID attribute from the FloorRequestQuery message 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-REQUEST-STATUS attributes to
REQUEST-INFORMATION grouped attribute identifying the floors being the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
requested (i.e., the floors associated with the floor request floors being requested (i.e., the floors associated with the floor
identified by the FLOOR-REQUEST-ID attribute). request 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
server MAY provide the display name and the URI of the beneficiary in server MAY provide the display name and the URI of the beneficiary in
this BENEFICIARY-INFORMATION attribute. this BENEFICIARY-INFORMATION attribute.
The floor control server MAY provide information about the requester The floor control server MAY provide information about the requester
of the floor in a REQUESTED-BY-INFORMATION attribute inside the of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute. FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MAY provide the reason why the floor The floor control server MAY provide the reason why the floor
participant requested the floor in a PARTICIPANT-PROVIDED-INFO. participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
The floor control server MAY also add to the FLOOR-REQUEST- The floor control server MAY also add to the
INFORMATION grouped attribute a PRIORITY attribute with the Priority FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with
value requested for the floor request and a STATUS-INFO attribute the Priority value requested for the floor request and a STATUS-INFO
with extra information about the floor request. attribute with extra information about the floor request.
The floor control server adds a REQUEST-STATUS attribute to the The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
FLOOR-REQUEST-INFORMATION grouped attribute with the current status to the FLOOR-REQUEST-INFORMATION grouped attribute with the current
of the floor request. status of the floor request. The floor control server MAY provide
information about the status of the floor request as it relates to
each of the floors being requested in the FLOOR-REQUEST-STATUS
attributes.
13.3. Reception of a UserQuery Message 13.3. Reception of a UserQuery Message
On reception of a UserQuery message, the floor control server follows On reception of a UserQuery message, the floor control server follows
the rules in Section 9 which relate to client authentication and the rules in Section 9 that relate to client authentication and
authorization. If while processing the UserQuery message, the floor authorization. If while processing the UserQuery message, the floor
control server encounters an error, it SHOULD generate an Error 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 UserQuery message by a floor control The successful processing of a UserQuery message by a floor control
server involves generating a UserStatus message, which SHOULD be server involves generating a UserStatus message, which SHOULD be
generated as soon as possible. generated as soon as possible.
The floor control server MUST copy the Conference ID, the Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the UserQuery message into the USerStatus ID, and the User ID from the UserQuery message into the USerStatus
message, as described in Section 8.2. message, as described in Section 8.2.
The sender of the UserQuery message is requesting information about The sender of the UserQuery message is requesting information about
all the floor requests associated to a given participant (i.e., the all the floor requests associated with a given participant (i.e., the
floor requests where the participant is either the beneficiary or the floor requests where the participant is either the beneficiary or 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 the attribute or, in the absence of a BENEFICIARY-ID attribute, by a the
User ID in the common header of the UserQuery 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 UserQuery message into a BENEFICIARY-ID attribute from the UserQuery message into a
BENEFICIARY-INFORMATION attribute in the UserStatus 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 UserStatus message provides and the URI of the participant about which the UserStatus message
information on in this BENEFICIARY-INFORMATION attribute. provides information in this BENEFICIARY-INFORMATION attribute.
The floor control server SHOULD add to the UserStatus message a The floor control server SHOULD add to the UserStatus message a
FLOOR-REQUEST-INFORMATION grouped attribute for each floor request FLOOR-REQUEST-INFORMATION grouped attribute for each floor request
related to the participant the message provides information on (i.e., related to the participant about which the message provides
the floor requests where the participant is either the beneficiary or information (i.e., the floor requests where the participant is either
the requester). For each FLOOR-REQUEST-INFORMATION attribute, the the beneficiary or the requester). For each
floor control server follows the following steps. FLOOR-REQUEST-INFORMATION attribute, the floor control server follows
the following steps.
The floor control server MUST identity the floor request the FLOOR- The floor control server MUST identify the floor request the
REQUEST-INFORMATION attribute applies to by filling the Floor Request FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor
ID field of the FLOOR-REQUEST-INFORMATION attribute. Request 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-REQUEST-STATUS attributes to
REQUEST-INFORMATION grouped attribute identifying the floors being the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
requested (i.e., the floors associated with the floor request floors being requested (i.e., the floors associated with the floor
identified by the FLOOR-REQUEST-ID attribute). request 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
server MAY provide the display name and the URI of the beneficiary in server MAY provide the display name and the URI of the beneficiary in
this BENEFICIARY-INFORMATION attribute. this BENEFICIARY-INFORMATION attribute.
The floor control server MAY provide information about the requester The floor control server MAY provide information about the requester
of the floor in a REQUESTED-BY-INFORMATION attribute inside the of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute. FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MAY provide the reason why the floor The floor control server MAY provide the reason why the floor
participant requested the floor in a PARTICIPANT-PROVIDED-INFO. participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
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.
with extra information about the floor request.
The floor control server MUST add a REQUEST-STATUS attribute to the The floor control server MUST include the current status of the floor
FLOOR-REQUEST-INFORMATION grouped attribute with the current status request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-
of the floor request. INFORMATION grouped attribute. The floor control server MAY add a
STATUS-INFO attribute with extra information about the floor request.
The floor control server MAY provide information about the status of
the floor request as it relates to each of the floors being requested
in the FLOOR-REQUEST-STATUS attributes.
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 that 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 FloorRequestStatus 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 Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRelease message into the ID, and the User ID from the FloorRelease message into the
FloorRequestStatus message, as described in Section 8.2. FloorRequestStatus message, as described in 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 FloorRequestStatus. The attributes contained in attribute to the FloorRequestStatus. The attributes contained in
this 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
INFORMATION attribute. FLOOR-REQUEST-INFORMATION attribute.
The floor control server MUST add FLOOR-ID attributes to the FLOOR-
REQUEST-INFORMATION grouped attribute identifying the floors being
requested (i.e., the floors associated with the floor request
identified by the FLOOR-REQUEST-ID attribute).
The floor control server SHOULD add a BENEFICIARY-ID attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute identifying the
beneficiary of the floor request. Additionally, the floor control
server MAY provide the display name and the URI of the beneficiary in
this BENEFICIARY-INFORMATION attribute.
The floor control server MAY provide information about the requester The floor control server MUST identify the floors being requested
of the floor in a REQUESTED-BY-INFORMATION attribute inside the (i.e., the floors associated with the floor request identified by the
FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the
FLOOR-REQUEST-INFORMATION grouped attribute. FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MAY provide the reason why the floor The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
participant requested the floor in a PARTICIPANT-PROVIDED-INFO. to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request
Status value SHOULD be Released, if the floor (or floors) had been
The floor control server MAY also add to the FLOOR-REQUEST-
INFORMATION grouped attribute a PRIORITY attribute with the Priority
value requested for the floor request and a STATUS-INFO attribute
with extra information about the floor request.
The floor control server MUST add a REQUEST-STATUS attribute to the
FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status
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. The floor control server MAY add a STATUS-
INFO attribute with extra information about the floor request.
13.5. Reception of a FloorQuery Message 13.5. Reception of a FloorQuery Message
On reception of a FloorQuery 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 that 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 FloorQuery message from a client A floor control server receiving a FloorQuery message from a client
SHOULD keep this client informed about the status of the floors SHOULD keep this client informed about the status of the floors
identified by FLOOR-ID attributes in the FloorQuery message. Floor identified by FLOOR-ID attributes in the FloorQuery message. Floor
Control Servers keep clients informed by using FloorStatus messages. Control Servers keep clients informed by using FloorStatus messages.
An individual FloorStatus message carries information about a single An individual FloorStatus message carries information about a single
floor. So, when a FloorQuery message requests information about more floor. So, when a FloorQuery message requests information about more
than one floor, the floor control server needs to send separate than one floor, the floor control server needs to send separate
FloorStatus messages for different floors. FloorStatus messages for different floors.
The information FloorQuery 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 FloorStatus Message 13.5.1. Generation of the First FloorStatus Message
The successful processing of a FloorQuery message by a floor control The successful processing of a FloorQuery message by a floor control
server involves generating one or several FloorStatus messages, the server involves generating one or several FloorStatus messages, 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 Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorQuery message into the FloorStatus ID, and the User ID from the FloorQuery message into the FloorStatus
message, as described in Section 8.2. message, as described in Section 8.2.
If the FloorQuery message did not contain any FLOOR-ID attribute, the If the FloorQuery message did not contain any FLOOR-ID attribute, the
floor control server sends the FloorStatus message without adding any floor control server sends the FloorStatus message without adding any
additional attribute and does not send any subsequent FloorStatus additional attribute and does not send any subsequent FloorStatus
message to the floor participant. message to the floor participant.
If the FloorQuery message contained one or more FLOOR-ID attributes, If the FloorQuery message contained one or more FLOOR-ID attributes,
the floor control server chooses one among them and adds this the floor control server chooses one from among them and adds this
FLOOR-ID attribute to the FloorStatus 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
INFORMATION grouped attribute contains a number of attributes which FLOOR-REQUEST-INFORMATION grouped attribute contains a number of
provide information about the floor request. For each FLOOR-REQUEST- attributes that provide information about the floor request. For
INFORMATION attribute, the floor control server follows the following each FLOOR-REQUEST-INFORMATION attribute, the floor control server
steps. follows the following steps.
The floor control server MUST identity the floor request the FLOOR- The floor control server MUST identify the floor request the
REQUEST-INFORMATION attribute applies to by filling the Floor Request FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor
ID field of the FLOOR-REQUEST-INFORMATION attribute. Request 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-REQUEST-STATUS attributes to
REQUEST-INFORMATION grouped attribute identifying the floors being the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
requested (i.e., the floors associated with the floor request floors being requested (i.e., the floors associated with the floor
identified by the FLOOR-REQUEST-ID attribute). request 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
server MAY provide the display name and the URI of the beneficiary in server MAY provide the display name and the URI of the beneficiary in
this BENEFICIARY-INFORMATION attribute. this BENEFICIARY-INFORMATION attribute.
The floor control server MAY provide information about the requester The floor control server MAY provide information about the requester
of the floor in a REQUESTED-BY-INFORMATION attribute inside the of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute. FLOOR-REQUEST-INFORMATION grouped attribute.
The floor control server MAY provide the reason why the floor The floor control server MAY provide the reason why the floor
participant requested the floor in a PARTICIPANT-PROVIDED-INFO. participant requested the floor in a PARTICIPANT-PROVIDED-INFO.
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.
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 an OVERALL-REQUEST-STATUS attribute
FLOOR-REQUEST-INFORMATION grouped attribute with the current status to the FLOOR-REQUEST-INFORMATION grouped attribute with the current
of the floor request. status of the floor request. The floor control server MAY add a
STATUS-INFO attribute with extra information about the floor request.
The floor control server MAY provide information about the status of
the floor request as it relates to each of the floors being requested
in the FLOOR-REQUEST-STATUS attributes.
13.5.2. Generation of Subsequent FloorStatus Messages 13.5.2. Generation of Subsequent FloorStatus Messages
If the FloorQuery message carried more than one FLOOR-ID attribute, If the FloorQuery message carried more than one FLOOR-ID attribute,
the floor control server SHOULD generate a FloorStatus message for the floor control server SHOULD generate a FloorStatus message for
each of them (except for the FLOOR-ID attribute chosen for the first each of them (except for the FLOOR-ID attribute chosen for the first
FloorStatus message) as soon as possible. These FloorStatus messages FloorStatus message) as soon as possible. These FloorStatus messages
are generated following the same rules as for the first FloorStatus are generated following the same rules as those for the first
message (see Section 13.5.1, but their Transaction ID is 0. FloorStatus message (see Section 13.5.1), but their Transaction ID is
0.
After generating these messages, the floor control server sends After generating these messages, the floor control server sends
FloorStatus messages periodically keeping the client informed about FloorStatus messages, periodically keeping the client informed about
all the floors the client requested information about. The all the floors for which the client requested information. The
Transaction ID of these messages MUST be 0. Transaction ID of these messages MUST be 0.
The rate at which the floor control server sends FloorStatus 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 FloorStatus 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
FloorStatus 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 that 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 Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the ChairAction message into the ID, and the User ID from the ChairAction 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 that was requested as part of an atomic floor request operation
operation that involved several floors. Even if the chair that involved several floors. Even if the chair responsible for one
responsible for one of the floors instructs the floor control server of the floors instructs the floor control server to grant the floor,
to grant the floor, the floor control server will not grant it until the floor control server will not grant it until the chairs
the chairs responsible for the other floors agree to grant them as responsible for the other floors agree to grant them as well.
well.
So, the floor control server is ultimately responsible to keep a So, the floor control server is ultimately responsible for keeping a
coherent floor state using instructions from floor chairs as input to coherent floor state using instructions from floor chairs as input to
this state. this state.
If the new Status in the ChairAction message is Accepted and all the If the new Status in the ChairAction message is Accepted and all the
bits of the Queue Position field are zero, the floor chair is bits of the Queue Position field are zero, the floor chair is
requesting the floor control server to assign a queue position (e.g., requesting that the floor control server assign a queue position
the last in the queue) to the floor request based on the local policy (e.g., the last in the queue) to the floor request based on the local
of the floor control server. (Of course, such a request only applies policy of the floor control server. (Of course, such a request only
in case the floor control server implements a queue.) applies if the floor control server implements a queue.)
13.7. Reception of a Hello Message 13.7. Reception of a Hello Message
On reception of a Hello message, the floor control server follows the On reception of a Hello message, the floor control server follows the
rules in Section 9 which relate to client authentication. If while rules in Section 9 that 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 from the Hello the Conference ID, the Transaction ID, and the User ID 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.
skipping to change at page 55, line 46 skipping to change at page 58, line 15
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 Transaction The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the message from the client into the Error ID, and the User ID from the message from the 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 5. Additionally, the floor control server may add a ERROR-INFO Table 5. Additionally, the floor control server may add an
attribute with extra information about the error. ERROR-INFO attribute with extra information about the error.
14. Security Considerations 14. Security Considerations
BFCP uses TLS to provide mutual authentication between clients and BFCP uses TLS to provide mutual authentication between clients and
servers. TLS also provides replay and integrity protection, and servers. TLS also provides replay and integrity protection and
confidentiality. It is RECOMMENDED that TLS with non-null encryption confidentiality. It is RECOMMENDED that TLS with non-null encryption
is always used. BFCP entities MAY use other security mechanisms as always be used. BFCP entities MAY use other security mechanisms as
long as they provide similar security properties. long as they provide similar security properties.
The remainder of this Section analyzes some of the threats against The remainder of this section analyzes some of the threats against
BFCP and how they are addressed. BFCP and how they are addressed.
An attacker may attempt to impersonate a client (a floor participant An attacker may attempt to impersonate a client (a floor participant
or a floor chair) in order to generate forged floor requests or to or a floor chair) in order to generate forged floor requests or to
grant or deny existing floor requests. Client impersonation is grant or deny existing floor requests. Client impersonation is
avoided by having servers only accept BFCP messages over avoided by having servers only accept BFCP messages over
authenticated TLS connections. The floor control server assumes that authenticated TLS connections. The floor control server assumes that
attackers cannot hickjack the TLS connection and, therefore, that attackers cannot highjack the TLS connection and, therefore, that
messages over the TLS connection come from the client that was messages over the TLS connection come from the client that was
initially authenticated. initially authenticated.
An attacker may attempt to impersonate a floor control server. A An attacker may attempt to impersonate a floor control server. A
successful attacker would be able to make clients think that they successful attacker would be able to make clients think that they
hold a particular floor so that they would try to access a resource hold a particular floor so that they would try to access a resource
(e.g., sending media) without having legitimate rights to access it. (e.g., sending media) without having legitimate rights to access it.
Floor control server impersonation is avoided by having servers only Floor control server impersonation is avoided by having servers only
accept BFCP messages over authenticated TLS connections. accept BFCP messages over authenticated TLS connections.
skipping to change at page 57, line 4 skipping to change at page 59, line 20
a floor control server and replay it over a connection between the a floor control server and replay it over a connection between the
attacker and the floor control server. This attack is prevented by attacker and the floor control server. This attack is prevented by
having floor control servers check that messages arriving over a having floor control servers check that messages arriving over a
given authenticated TLS connection use an authorized user ID (i.e., a given authenticated TLS connection use an authorized user ID (i.e., a
user ID that the user that established the authenticated TLS user ID that the user that established the authenticated TLS
connection is allowed to use). connection is allowed to use).
Attackers may attempt to pick messages from the network to get access Attackers may attempt to pick messages from the network to get access
to confidential information between the floor control server and a to confidential information between the floor control server and a
client (e.g., why a floor request was denied). TLS confidentiality client (e.g., why a floor request was denied). TLS confidentiality
prevents this attack. Therefore, it is RECOMMENDED that TLS is used prevents this attack. Therefore, it is RECOMMENDED that TLS be used
with a non-null encryption algorithm. with a non-null encryption algorithm.
15. IANA Considerations 15. IANA Considerations
This document instructs the IANA to create a new registry for BFCP The IANA has created a new registry for BFCP parameters called
parameters called "Binary Floor Control Protocol (BFCP) Parameters". "Binary Floor Control Protocol (BFCP) Parameters". This new registry
This new registry has a number of subregistries, which are described has a number of subregistries, which are described in the following
in the following Sections sections.
15.1. Attribute Subregistry 15.1. Attribute Subregistry
This Section establishes the Attribute subregistry under the BFCP This section establishes the Attribute subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [4], the Parameters registry. As per the terminology in RFC 2434 [4], the
registration policy for BFCP attributes shall be "Specification registration policy for BFCP attributes shall be "Specification
Required". For the purposes of this subregistry, the BFCP attributes Required". For the purposes of this subregistry, the BFCP attributes
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 attribute's type, standards-track RFC. Such an RFC MUST specify the attribute's type,
name, format, and semantics. name, format, and semantics.
For each BFCP attribute, the IANA registers its type, its name, and For each BFCP attribute, the IANA registers its type, its name, and
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 4582] |
| 2 | FLOOR-ID | [RFC XXXX] | | 2 | FLOOR-ID | [RFC 4582] |
| 3 | FLOOR-REQUEST-ID | [RFC XXXX] | | 3 | FLOOR-REQUEST-ID | [RFC 4582] |
| 4 | PRIORITY | [RFC XXXX] | | 4 | PRIORITY | [RFC 4582] |
| 5 | REQUEST-STATUS | [RFC XXXX] | | 5 | REQUEST-STATUS | [RFC 4582] |
| 6 | ERROR-CODE | [RFC XXXX] | | 6 | ERROR-CODE | [RFC 4582] |
| 7 | ERROR-INFO | [RFC XXXX] | | 7 | ERROR-INFO | [RFC 4582] |
| 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | | 8 | PARTICIPANT-PROVIDED-INFO | [RFC 4582] |
| 9 | STATUS-INFO | [RFC XXXX] | | 9 | STATUS-INFO | [RFC 4582] |
| 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | | 10 | SUPPORTED-ATTRIBUTES | [RFC 4582] |
| 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | | 11 | SUPPORTED-PRIMITIVES | [RFC 4582] |
| 12 | USER-DISPLAY-NAME | [RFC XXXX] | | 12 | USER-DISPLAY-NAME | [RFC 4582] |
| 13 | USER-URI | [RFC XXXX] | | 13 | USER-URI | [RFC 4582] |
| 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | | 14 | BENEFICIARY-INFORMATION | [RFC 4582] |
| 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | | 15 | FLOOR-REQUEST-INFORMATION | [RFC 4582] |
| 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | | 16 | REQUESTED-BY-INFORMATION | [RFC 4582] |
| 17 | FLOOR-REQUEST-STATUS | [RFC 4582] |
| 18 | OVERALL-REQUEST-STATUS | [RFC 4582] |
+------+---------------------------+------------+ +------+---------------------------+------------+
Table 6: Initial values of the BFCP Attribute subregistry Table 6: 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 [4], the Parameters registry. As per the terminology in RFC 2434 [4], 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 an 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 4582] |
| 2 | FloorRelease | [RFC XXXX] | | 2 | FloorRelease | [RFC 4582] |
| 3 | FloorRequestQuery | [RFC XXXX] | | 3 | FloorRequestQuery | [RFC 4582] |
| 4 | FloorRequestStatus | [RFC XXXX] | | 4 | FloorRequestStatus | [RFC 4582] |
| 5 | UserQuery | [RFC XXXX] | | 5 | UserQuery | [RFC 4582] |
| 6 | UserStatus | [RFC XXXX] | | 6 | UserStatus | [RFC 4582] |
| 7 | FloorQuery | [RFC XXXX] | | 7 | FloorQuery | [RFC 4582] |
| 8 | FloorStatus | [RFC XXXX] | | 8 | FloorStatus | [RFC 4582] |
| 9 | ChairAction | [RFC XXXX] | | 9 | ChairAction | [RFC 4582] |
| 10 | ChairActionAck | [RFC XXXX] | | 10 | ChairActionAck | [RFC 4582] |
| 11 | Hello | [RFC XXXX] | | 11 | Hello | [RFC 4582] |
| 12 | HelloAck | [RFC XXXX] | | 12 | HelloAck | [RFC 4582] |
| 13 | Error | [RFC XXXX] | | 13 | Error | [RFC 4582] |
+-------+--------------------+------------+ +-------+--------------------+------------+
Table 7: Initial values of the BFCP primitive subregistry Table 7: 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 [4], BFCP Parameters registry. As per the terminology in RFC 2434 [4],
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
defined by a standards-track RFC. Such RFC MUST specify the value defined by a standards-track RFC. Such an RFC MUST specify the value
and the semantics of the request status. and the semantics of the request status.
For each BFCP request status, the IANA registers its value, its For each BFCP request status, the IANA registers its value, its
meaning, and the reference to the RFC where the request status is meaning, and the reference to the RFC where the request status is
defined. The following table contains the initial values of this defined. The following table contains the initial values of this
subregistry. subregistry.
+-------+-----------+------------+ +-------+-----------+------------+
| Value | Status | Reference | | Value | Status | Reference |
+-------+-----------+------------+ +-------+-----------+------------+
| 1 | Pending | [RFC XXXX] | | 1 | Pending | [RFC 4582] |
| 2 | Accepted | [RFC XXXX] | | 2 | Accepted | [RFC 4582] |
| 3 | Granted | [RFC XXXX] | | 3 | Granted | [RFC 4582] |
| 4 | Denied | [RFC XXXX] | | 4 | Denied | [RFC 4582] |
| 5 | Cancelled | [RFC XXXX] | | 5 | Cancelled | [RFC 4582] |
| 6 | Released | [RFC XXXX] | | 6 | Released | [RFC 4582] |
| 7 | Revoked | [RFC XXXX] | | 7 | Revoked | [RFC 4582] |
+-------+-----------+------------+ +-------+-----------+------------+
Table 8: Initial values of the Request Status subregistry Table 8: Initial values of the Request Status subregistry
15.4. Error Code Subregistry 15.4. Error Code Subregistry
This Section establishes the Error Code subregistry under the BFCP This section establishes the Error Code subregistry under the BFCP
Parameters registry. As per the terminology in RFC 2434 [4], the Parameters registry. As per the terminology in RFC 2434 [4], the
registration policy for BFCP error codes shall be "Specification registration policy for BFCP error codes shall be "Specification
Required". For the purposes of this subregistry, the BFCP error Required". For the purposes of this subregistry, the BFCP error
codes for which IANA registration is requested MUST be defined by a codes for which IANA registration is requested MUST be defined by a
standards-track RFC. Such RFC MUST specify the value and the standards-track RFC. Such an RFC MUST specify the value and the
semantics of the error code, and any Error Specific Details that semantics of the error code, and any Error Specific Details that
apply to it. apply to it.
For each BFCP primitive, the IANA registers its value, its meaning, For each BFCP primitive, the IANA registers its value, its meaning,
and the reference to the RFC where the primitive is defined. The and 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 | Meaning | Reference | | Value | Meaning | Reference |
+-------+--------------------------------------------------+-----------+ +-------+-----------------------------------------------+------------+
| 1 | Conference does not Exist | [RFC | | 1 | Conference does not Exist | [RFC 4582] |
| | | XXXX] | | 2 | User does not Exist | [RFC 4582] |
| 2 | User does not Exist | [RFC | | 3 | Unknown Primitive | [RFC 4582] |
| | | XXXX] | | 4 | Unknown Mandatory Attribute | [RFC 4582] |
| 3 | Unknown Primitive | [RFC | | 5 | Unauthorized Operation | [RFC 4582] |
| | | XXXX] | | 6 | Invalid Floor ID | [RFC 4582] |
| 4 | Unknown Mandatory Attribute | [RFC | | 7 | Floor Request ID Does Not Exist | [RFC 4582] |
| | | XXXX] | | 8 | You have Already Reached the Maximum Number | [RFC 4582] |
| 5 | Unauthorized Operation | [RFC | | | of Ongoing Floor Requests for this Floor | |
| | | XXXX] | | 9 | Use TLS | [RFC 4582] |
| 6 | Invalid Floor ID | [RFC | +-------+-----------------------------------------------+-----------+
| | | XXXX] |
| 7 | Floor Request ID Does Not Exist | [RFC |
| | | XXXX] |
| 8 | You have Already Reached the Maximum Number of | [RFC |
| | Ongoing Floor Requests for this Floor | XXXX] |
| 9 | Use TLS | [RFC |
| | | XXXX] |
+-------+--------------------------------------------------+-----------+
Table 9: Initial Values of the Error Code subregistry Table 9: Initial Values of the Error Code subregistry
16. Acknowledgments 16. Acknowledgements
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, Dave Morgan, and Oscar Novo 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] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] 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.
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 4234, October 2005.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
RFC 2246, January 1999. Protocol Version 1.1", RFC 4346, April 2006.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002. Transport Layer Security (TLS)", RFC 3268, June 2002.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
STD 63, RFC 3629, November 2003. 63, RFC 3629, November 2003.
[7] Camarillo, G., "Session Description Protocol (SDP) Format for [7] Camarillo, G., "Session Description Protocol (SDP) Format for
Binary Floor Control Protocol (BFCP) Streams", Binary Floor Control Protocol (BFCP) Streams", RFC 4583,
draft-ietf-mmusic-sdp-bfcp-02 (work in progress), July 2005. November 2006.
17.2. Informational References 17.2. Informational References
[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[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", [9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu,
draft-ietf-xcon-floor-control-req-03 (work in progress), "Requirements for Floor Control Protocols", RFC 4376, February
October 2005. 2006.
[11] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol",
draft-ietf-sipping-conferencing-framework-05 (work in
progress), May 2005.
[12] Barnes, M. and C. Boulton, "A Framework and Data Model for [10] Barnes, M. and C. Boulton, "A Framework and Data Model for
Centralized Conferencing", draft-barnes-xcon-framework-02 (work Centralized Conferencing", Work in Progress, February 2005.
in progress), February 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
Joerg Ott Joerg Ott
Helsinki University of Technology Helsinki University of Technology
Department for Electrical and Communications Engineering Department for Electrical and Communications Engineering
Networking Laboratory Networking Laboratory
Helsinki PO Box 3000
02015 TKK
Finland Finland
Email: jo@netlab.hut.fi EMail: jo@netlab.hut.fi
Keith Drage Keith Drage
Lucent Technologies Lucent Technologies
Windmill Hill Business Park Windmill Hill Business Park
Swindon Swindon
Wiltshire SN5 6PP Wiltshire SN5 6PP
UK UK
Email: drage@lucent.com EMail: drage@lucent.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 63, line 29 skipping to change at page 65, line 46
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 274 change blocks. 
724 lines changed or deleted 812 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/