idnits 2.17.1 draft-ietf-xcon-bfcp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3128. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3112. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3118. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 2978 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '1') ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3268 (ref. '6') (Obsoleted by RFC 5246) == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-sdp-bfcp-01 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: January 14, 2006 J. Ott 5 Helsinki University of Technology 6 K. Drage 7 Lucent Technologies 8 July 13, 2005 10 The Binary Floor Control Protocol (BFCP) 11 draft-ietf-xcon-bfcp-05.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 14, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 Floor control is a means to manage joint or exclusive access to 45 shared resources in a (multiparty) conferencing environment. 46 Thereby, floor control complements other functions -- such as 47 conference and media session setup, conference policy manipulation, 48 and media control -- that are realized by other protocols. 50 This document specifies the Binary Floor Control Protocol (BFCP). 51 BFCP is used between floor participants and floor control servers, 52 and between floor chairs (i.e., moderators) and floor control 53 servers. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2 Obtaining Information to Contact a Floor Control Server . 8 62 3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 8 63 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 8 64 3.5 Privileges of Floor Control . . . . . . . . . . . . . . . 9 65 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 9 66 4.1 Floor Participant to Floor Control Server Interface . . . 10 67 4.2 Floor Chair to Floor Control Server Interface . . . . . . 13 68 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 14 69 5.1 COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 15 70 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 16 71 5.2.1 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 18 72 5.2.2 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 18 73 5.2.3 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18 74 5.2.4 NONCE . . . . . . . . . . . . . . . . . . . . . . . . 19 75 5.2.5 PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.2.6 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20 77 5.2.7 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 21 78 5.2.8 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 22 79 5.2.9 ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 24 80 5.2.10 PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . 25 81 5.2.11 STATUS-INFO . . . . . . . . . . . . . . . . . . . . 26 82 5.2.12 SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . 26 83 5.2.13 SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . 27 84 5.2.14 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 28 85 5.2.15 USER-URI . . . . . . . . . . . . . . . . . . . . . . 28 86 5.2.16 BENEFICIARY-INFORMATION . . . . . . . . . . . . . . 29 87 5.2.17 FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . 30 88 5.2.18 REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . 30 89 5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 31 90 5.3.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . 31 91 5.3.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . 32 92 5.3.3 FloorRequestQuery . . . . . . . . . . . . . . . . . . 32 93 5.3.4 FloorRequestStatus . . . . . . . . . . . . . . . . . . 33 94 5.3.5 UserQuery . . . . . . . . . . . . . . . . . . . . . . 33 95 5.3.6 UserStatus . . . . . . . . . . . . . . . . . . . . . . 33 96 5.3.7 FloorQuery . . . . . . . . . . . . . . . . . . . . . . 34 97 5.3.8 FloorStatus . . . . . . . . . . . . . . . . . . . . . 34 98 5.3.9 ChairAction . . . . . . . . . . . . . . . . . . . . . 34 99 5.3.10 ChairActionAck . . . . . . . . . . . . . . . . . . . 35 100 5.3.11 Hello . . . . . . . . . . . . . . . . . . . . . . . 35 101 5.3.12 HelloAck . . . . . . . . . . . . . . . . . . . . . . 35 102 5.3.13 Error . . . . . . . . . . . . . . . . . . . . . . . 36 103 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 36 104 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 37 105 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 37 106 8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 38 107 8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 38 108 9. Authentication and Authorization . . . . . . . . . . . . . . 38 109 9.1 TLS-based Mutual Authentication . . . . . . . . . . . . . 38 110 9.2 Digest-based Client Authentication . . . . . . . . . . . . 39 111 9.2.1 Client Behavior . . . . . . . . . . . . . . . . . . . 39 112 9.2.2 Floor Control Server Behavior . . . . . . . . . . . . 41 113 10. Floor Participant Operations . . . . . . . . . . . . . . . . 42 114 10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 42 115 10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 42 116 10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 43 117 10.2 Cancelling a Floor Request and Releasing a Floor . . . . 44 118 10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 44 119 10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 45 120 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 45 121 11.1 Sending a ChairAction Message . . . . . . . . . . . . . 45 122 11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 46 123 12. General Client Operations . . . . . . . . . . . . . . . . . 47 124 12.1 Requesting Information about Floors . . . . . . . . . . 47 125 12.1.1 Sending a FloorQuery Message . . . . . . . . . . . . 47 126 12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 47 127 12.2 Requesting Information about Floor Requests . . . . . . 48 128 12.2.1 Sending a FloorRequestQuery Message . . . . . . . . 49 129 12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 49 130 12.3 Requesting Information about a User . . . . . . . . . . 49 131 12.3.1 Sending a UserQuery Message . . . . . . . . . . . . 50 132 12.3.2 Receiving a Response . . . . . . . . . . . . . . . . 50 133 12.4 Obtaining the Capabilities of a Floor Control Server . . 50 134 12.4.1 Sending a Hello Message . . . . . . . . . . . . . . 51 135 12.4.2 Receiving Responses . . . . . . . . . . . . . . . . 51 136 13. Floor Control Server Operations . . . . . . . . . . . . . . 51 137 13.1 Reception of a FloorRequest Message . . . . . . . . . . 52 138 13.1.1 Generating the First FloorRequestStatus Message . . 52 139 13.1.2 Generation of Subsequent FloorRequestStatus 140 Messages . . . . . . . . . . . . . . . . . . . . . . 53 141 13.2 Reception of a FloorRequestQuery Message . . . . . . . . 54 142 13.3 Reception of a UserQuery Message . . . . . . . . . . . . 55 143 13.4 Reception of a FloorRelease Message . . . . . . . . . . 57 144 13.5 Reception of a FloorQuery Message . . . . . . . . . . . 58 145 13.5.1 Generation of the First FloorStatus Message . . . . 58 146 13.5.2 Generation of Subsequent FloorStatus Messages . . . 60 147 13.6 Reception of a ChairAction Message . . . . . . . . . . . 60 148 13.7 Reception of a Hello Message . . . . . . . . . . . . . . 61 149 13.8 Error Message Generation . . . . . . . . . . . . . . . . 61 150 14. Security Considerations . . . . . . . . . . . . . . . . . . 62 151 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 63 152 15.1 Attribute Subregistry . . . . . . . . . . . . . . . . . 63 153 15.2 Primitive Subregistry . . . . . . . . . . . . . . . . . 64 154 15.3 Request Status Subregistry . . . . . . . . . . . . . . . 65 155 15.4 Error Code Subregistry . . . . . . . . . . . . . . . . . 66 156 15.5 Digest Algorithm Subregistry . . . . . . . . . . . . . . 67 157 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 67 158 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 159 17.1 Normative References . . . . . . . . . . . . . . . . . . 67 160 17.2 Informational References . . . . . . . . . . . . . . . . 68 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 68 162 Intellectual Property and Copyright Statements . . . . . . . 70 164 1. Introduction 166 Within a conference, some applications need to manage the access to a 167 set of shared resources, such as the right to send media over a 168 particular media stream. Floor control enables such applications to 169 provide users with coordinated (shared or exclusive) access to these 170 resources. 172 The Requirements for Floor Control Protocol [10] list a set of 173 requirements that need to be met by floor control protocols. The 174 Binary Floor Control Protocol (BFCP), which is specified in this 175 document, meets these requirements. 177 In addition, BFCP has been designed so that it can be used in low- 178 bandwidth environments. The binary encoding used by BFCP achieves a 179 small message size (when message signatures are not used) that keeps 180 the time it takes to transmit delay-sensitive BFCP messages at 181 minimum. Delay-sensitive BFCP messages include FloorRequest, 182 FloorRelease, FloorRequestStatus, and ChairAction. It is expected 183 that future extensions to these messages do not increase the size of 184 these messages in a significant way. 186 The remainder of this document is organized as follows: Section 2 187 defines the terminology used throughout this document, Section 3 188 discusses the scope of BFCP (i.e., which tasks fall within the scope 189 of BFCP and which ones are performed using different mechanisms), 190 Section 4 provides a non-normative overview of BFCP operation, and 191 subsequent sections provide the normative specification of BFCP. 193 2. Terminology 195 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 196 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 197 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 198 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 199 compliant implementations. 201 Media Participant: An entity that has access to the media resources 202 of a conference (e.g., it can receive a media stream). In floor- 203 controlled conferences, a given media participant is typically co- 204 located with a floor participant, but does not need to. Third-party 205 floor requests consist of having a floor participant request a floor 206 for a media participant when they are not colocated. The protocol 207 between a floor participant and a media participant (that are not 208 colocated) is outside the scope of this document. 210 Client: a floor participant or a floor chair that communicate with a 211 floor control server using BFCP. 213 Floor: A permission to temporarily access or manipulate a specific 214 shared resource or set of resources. 216 Floor Chair: A logical entity that manages one floor (grants, denies, 217 or revokes a floor). An entity that assumes the logical role of a 218 floor chair for a given transaction may assume a different role 219 (e.g., floor participant) for a different transaction. The roles of 220 floor chair and floor participant are defined on a transaction-by- 221 transaction basis. BFCP transactions are defined in Section 8. 223 Floor Control: A mechanism that enables applications or users to gain 224 safe and mutually exclusive or non-exclusive input access to the 225 shared object or resource. 227 Floor Control Server: A logical entity that maintains the state of 228 the floor(s) including which floors exists, who the floor chairs are, 229 who holds a floor, etc. Requests to manipulate a floor are directed 230 at the floor control server. The floor control server of a 231 conference may perform other logical roles (e.g., floor participant) 232 in another conference. 234 Floor Participant: A logical entity that requests floors, and 235 possibly information about them, from a floor control server. An 236 entity that assumes the logical role of a floor participant for a 237 given transaction may assume a different role (e.g., a floor chair) 238 for a different transaction. The roles of floor participant and 239 floor chair are defined on a transaction-by-transaction basis. BFCP 240 transactions are defined in Section 8. In floor-controlled 241 conferences, a given floor participant is typically co-located with a 242 media participant, but does not need to. Third-party floor requests 243 consist of having a floor participant request a floor for a media 244 participant when they are not co-located. 246 Participant: An entity that acts as a floor participant, as a media 247 participant, or as both. 249 3. Scope 251 As stated earlier, BFCP is a protocol to coordinate access to shared 252 resources in a conference following the requirements defined in [10]. 253 Floor control complements other functions defined in the XCON 254 conferencing framework [12] and is compatible with the SIPPING 255 conferencing framework [11]. The floor control protocol BFCP defined 256 in this document only specifies a means to arbitrate access to 257 floors. The rules and constraints for floor arbitration and the 258 results of floor assignments are outside the scope of this document 259 and defined by other protocols [12]. 261 Figure 1 shows the tasks that BFCP can perform. 263 +---------+ 264 | Floor | 265 | Chair | 266 | | 267 +---------+ 268 ^ | 269 | | 270 Notification | | Decision 271 | | 272 | | 273 Floor | v 274 +-------------+ Request +---------+ +-------------+ 275 | Floor |----------->| Floor | Notification | Floor | 276 | Participant | | Control |------------->| Participant | 277 | |<-----------| Server | | | 278 +-------------+ Granted or +---------+ +-------------+ 279 Denied 281 Figure 1: Functionality provided by BFCP 283 BFCP provides a means: 285 o for floor participants to send floor requests to floor control 286 servers. 287 o for floor control servers to grant or deny requests to access a 288 given resource from floor participants. 289 o for floor chairs to send floor control servers decisions regarding 290 floor requests. 291 o for floor control servers to keep floor participants and floor 292 chairs informed about the status of a given floor or a given floor 293 request. 295 Even though tasks that do not belong to the previous list are outside 296 the scope of BFCP, some of these out-of-scope tasks relate to floor 297 control and are essential to create floors and to establish BFCP 298 connections between different entities. In the following 299 subsections, we discuss some of these tasks and mechanisms to perform 300 them. 302 3.1 Floor Creation 304 The association of a given floor with a resource or a set of 305 resources (e.g., media streams) is out of the scope of BFCP as 306 described in [12]. Floor creation and termination are also outside 307 the scope of BFCP; these aspects are handled using the conference 308 control protocol for manipulating the conference object. 309 Consequently, the floor control server needs to stay up to date on 310 changes to the conference object (e.g., when a new floor is created). 312 3.2 Obtaining Information to Contact a Floor Control Server 314 A client needs a set of data in order to establish a BFCP connection 315 to a floor control server. These data include the transport address 316 of the server, the conference identifier, and a user identifier. 318 Clients can obtain this information in different ways. One is to use 319 an offer/answer [9] exchange, which is described in [13]. Other 320 mechanisms are also described in the XCON framework (and other 321 related documents). 323 3.3 Generating a Shared Secret 325 Authentication in BFCP is based on a shared secret between the client 326 and the floor control server. So, there is a need for a mechanism to 327 generate such a shared secret. However, such mechanism is outside 328 the scope of BFCP. 330 Shared secrets can also be generated and exchanged using out-of-band 331 means. For example, when the floor participant or the floor chair 332 obtains the information needed to contact the BFCP floor control 333 server over a secure channel (e.g., an offer/answer [9] exchange 334 using SIP [8] protected using S/MIME), they can get the shared secret 335 using the same channel. 337 3.4 Obtaining Floor-Resource Associations 339 Floors are associated with resources. For example, a floor that 340 controls who talks at a given time has a particular audio stream as 341 its associated resource. Associations between floors and resources 342 are part of the conference object. 344 Floor participants and floor chairs need to know which resources are 345 associated with which floors. They can obtain this information using 346 different mechanisms, such as an offer/answer [9] exchange. How to 347 use an offer/answer exchange to obtain these associations is 348 described in [13]. 350 Note that floor participants perform offer/answer exchanges with 351 the SIP Focus of the conference. So, the SIP Focus needs to 352 obtain information about associations between floors and resources 353 in order to be able to provide this information to a floor 354 participant in an offer/answer exchange. 356 Other mechanisms for obtaining this information, including discussion 357 of how the information is made available to a (SIP) Focus, are 358 described in the XCON framework (and other related documents). 360 3.5 Privileges of Floor Control 362 A participant whose floor request is granted has the right to use (in 363 a certain way) the resource or resources associated with the floor 364 that was requested. For example, the participant may have the right 365 to send media over a particular audio stream. 367 Nevertheless, holding a floor does not imply that others will not be 368 able to use its associated resources at the same time, even if they 369 do not have the right to do so. Determination of which media 370 participants can actually use the resources in the conference is 371 discussed in the XCON Framework. 373 4. Overview of Operation 375 This section provides a non-normative description of BFCP operations. 376 Section 4.1 describes the interface between floor participants and 377 floor control servers and Section 4.2 describes the interface between 378 floor chairs and floor control servers 380 BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 381 consist of a common header followed by a set of attributes. The 382 common header contains, among other information, a 32-bit conference 383 identifier. Floor participants, media participants, and floor chairs 384 are identified by 16-bit user identifiers. 386 Participant authentication in BFCP is based on shared secrets. The 387 floor control server of a conference shares a secret with each of the 388 participants in the conference and can request them to sign their 389 messages using that shared secret. 391 BFCP supports nested attributes (i.e., attributes that contain 392 attributes). These are referred to as grouped attributes. 394 There are two types of transactions in BFCP: client-initiated 395 transactions and server-initiated transactions. Client-initiated 396 transactions consist of a message from a client to the floor control 397 server and a response from the floor control server to the client. 398 Both messages can be related because they carry the same Transaction 399 ID value in their common headers. Server-initiated transactions 400 consist of a single message, whose Transaction ID is 0, from the 401 floor control server to a client. 403 4.1 Floor Participant to Floor Control Server Interface 405 Floor participants request a floor by sending a FloorRequest message 406 to the floor control server. BFCP supports third-party floor 407 requests. That is, the floor participant sending the floor request 408 need not be co-located with the media participant that will get the 409 floor once the floor request is granted. FloorRequest messages carry 410 the identity of the requester in the User ID field of the common 411 header, and the identity of the beneficiary of the floor (in third 412 party floor requests) in a BENEFICIARY-ID attribute. 414 Third party floor requests can be sent, for example, by floor 415 participants that have a BFCP connection to the floor control 416 server but that are not media participants (i.e., they do not 417 handle any media). 419 FloorRequest messages identify the floor or floors being requested by 420 carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a 421 FloorRequest message carries more than one floor identifier, the 422 floor control server treats all the floor requests as an atomic 423 package. That is, the floor control server either grants or denies 424 all the floors in the FloorRequest message. 426 Floor control servers respond to FloorRequest messages with 427 FloorRequestStatus messages, which provide information about the 428 status of the floor request. The first FloorRequestStatus message is 429 the response to the FloorRequest message from the client, and 430 therefore has the same Transaction ID as the FloorRequest. 432 Additionally, the first FloorRequestStatus message carries the Floor 433 Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent 434 FloorRequestStatus messages related to the same floor request will 435 carry the same Floor Request ID. This way, the floor participant can 436 associate them with the appropriate floor request. 438 Messages from the floor participant related to a particular floor 439 request also use the same Floor Request ID as the first 440 FloorRequestStatus Message from the floor control server. 442 Figure 2 shows how a floor participant requests a floor, obtains it, 443 and, at a later time, releases it. This figure illustrates the use, 444 among other things, of the Transaction ID and the FLOOR-REQUEST-ID 445 attribute. 447 Floor Participant Floor Control 448 Server 450 |(1) FloorRequest | 451 |Transaction ID: 123 | 452 |User ID: 234 | 453 |FLOOR-ID: 543 | 454 |---------------------------------------------->| 455 | | 456 |(2) FloorRequestStatus | 457 |Transaction ID: 123 | 458 |User ID: 234 | 459 |FLOOR-REQUEST-INFORMATION | 460 | Floor Request ID: 789 | 461 | FLOOR-ID: 543 | 462 | REQUEST-STATUS: Pending | 463 |<----------------------------------------------| 464 | | 465 |(3) FloorRequestStatus | 466 |Transaction ID: 0 | 467 |User ID: 234 | 468 |FLOOR-REQUEST-INFORMATION | 469 | Floor Request ID: 789 | 470 | FLOOR-ID: 543 | 471 | REQUEST-STATUS: Accepted (1st in Queue) | 472 |<----------------------------------------------| 473 | | 474 |(4) FloorRequestStatus | 475 |Transaction ID: 0 | 476 |User ID: 234 | 477 |FLOOR-REQUEST-INFORMATION | 478 | Floor Request ID: 789 | 479 | FLOOR-ID: 543 | 480 | REQUEST-STATUS: Granted | 481 |<----------------------------------------------| 482 | | 483 |(5) FloorRelease | 484 |Transaction ID: 154 | 485 |User ID: 234 | 486 |FLOOR-REQUEST-ID: 789 | 487 |---------------------------------------------->| 488 | | 489 |(6) FloorRequestStatus | 490 |Transaction ID: 154 | 491 |User ID: 234 | 492 |FLOOR-REQUEST-INFORMATION | 493 | Floor Request ID: 789 | 494 | FLOOR-ID: 543 | 495 | REQUEST-STATUS: Released | 496 |<----------------------------------------------| 497 Figure 2: Requesting and releasing a floor 499 Figure 3 shows how a floor participant requests to be informed on the 500 status of a floor. The first FloorStatus message from the floor 501 control server is the response to the FloorQuery message, and as 502 such, has the same Transaction ID as the FloorQuery message. 504 Subsequent FloorStatus messages consist of server-initiated 505 transactions, and therefore their Transaction ID is 0. FloorStatus 506 message (2) indicates that there are currently two floor requests for 507 the floor whose Floor ID is 543. FloorStatus message (3) indicates 508 that the floor requests with Floor Request ID 764 has been granted, 509 while the floor request with Floor Request ID 635 is the first in the 510 queue. FloorStatus message (4) indicates that the floor request with 511 Floor Request ID 635 has been granted. 513 Floor Participant Floor Control 514 Server 515 |(1) FloorQuery | 516 |Transaction ID: 257 | 517 |User ID: 234 | 518 |FLOOR-ID: 543 | 519 |---------------------------------------------->| 520 | | 521 |(2) FloorStatus | 522 |Transaction ID: 257 | 523 |User ID: 234 | 524 |FLOOR-ID:543 | 525 |FLOOR-REQUEST-INFORMATION | 526 | Floor Request ID: 764 | 527 | FLOOR-ID: 543 | 528 | BENEFICIARY-INFORMATION | 529 | Beneficiary ID: 124 | 530 | REQUEST-STATUS: Accepted (1st in Queue) | 531 |FLOOR-REQUEST-INFORMATION | 532 | Floor Request ID: 635 | 533 | FLOOR-ID: 543 | 534 | BENEFICIARY-INFORMATION | 535 | Beneficiary ID: 154 | 536 | REQUEST-STATUS: Accepted (2nd in Queue) | 537 |<----------------------------------------------| 538 | | 539 |(3) FloorStatus | 540 |Transaction ID: 0 | 541 |User ID: 234 | 542 |FLOOR-ID:543 | 543 |FLOOR-REQUEST-INFORMATION | 544 | Floor Request ID: 764 | 545 | FLOOR-ID: 543 | 546 | BENEFICIARY-INFORMATION | 547 | Beneficiary ID: 124 | 548 | REQUEST-STATUS: Granted | 549 |FLOOR-REQUEST-INFORMATION | 550 | Floor Request ID: 635 | 551 | FLOOR-ID: 543 | 552 | BENEFICIARY-INFORMATION | 553 | Beneficiary ID: 154 | 554 | REQUEST-STATUS: Accepted (1st in Queue) | 555 |<----------------------------------------------| 556 | | 557 |(4) FloorStatus | 558 |Transaction ID: 0 | 559 |User ID: 234 | 560 |FLOOR-ID:543 | 561 |FLOOR-REQUEST-INFORMATION | 562 | Floor Request ID: 635 | 563 | FLOOR-ID: 543 | 564 | BENEFICIARY-INFORMATION | 565 | Beneficiary ID: 154 | 566 | REQUEST-STATUS: Granted | 567 |<----------------------------------------------| 569 Figure 3: Obtaining status information about a floor 571 FloorStatus messages contain information about the floor requests 572 they carry. For example, FloorStatus message (4) indicates that the 573 floor request with Floor Request ID 635 has as the beneficiary (i.e., 574 the participant that holds the floor when a particular floor request 575 is granted) the participant whose User ID is 154. The floor request 576 applies only to the floor whose Floor ID is 543. That is, this is 577 not a multi-floor floor request. 579 A multi-floor floor request applies to more than one floor (e.g., 580 a participant wants to be able to speak and write on the 581 whiteboard at the same time). The floor control server treats a 582 multi-floor floor request as an atomic package. That is, the 583 floor control server either grants the request for all floors or 584 denies the request for all the floors. 586 4.2 Floor Chair to Floor Control Server Interface 588 Figure 4 shows a floor chair instructing a floor control server to 589 grant a floor. Note, however, that although the floor control server 590 needs to take into consideration the instructions received in 591 ChairAction messages (e.g., granting a floor), it does not 592 necessarily need to perform them exactly as requested by the floor 593 chair. The operation that the floor control server performs depends 594 on the ChairAction message and on the internal state of the floor 595 control server. 597 For example, a floor chair may send a ChairAction message granting a 598 floor which was requested as part of an atomic floor request 599 operation that involved several floors. Even if the chair 600 responsible for one of the floors instructs the floor control server 601 to grant the floor, the floor control server will not grant it until 602 the chairs responsible for the other floors agree to grant them as 603 well. In another example, a floor chair may instruct the floor 604 control server to grant a floor to a participant. The floor control 605 server needs to revoke the floor from its current holder before 606 granting it to the new participant. 608 So, the floor control server is ultimately responsible to keep a 609 coherent floor state using instructions from floor chairs as input to 610 this state. 612 Floor Chair Floor Control 613 Server 614 |(1) ChairAction | 615 |Transaction ID: 769 | 616 |User ID: 357 | 617 |FLOOR-ID: 543 | 618 |FLOOR-REQUEST-ID: 635 | 619 |REQUEST-STATUS: Granted | 620 |---------------------------------------------->| 621 | | 622 |(2) ChairActionAck | 623 |Transaction ID: 769 | 624 |User ID: 357 | 625 |<----------------------------------------------| 627 Figure 4: Chair instructing the floor control server 629 5. Packet Format 631 BFCP packets consist of a 12-byte common header followed by 632 attributes. All the protocol values MUST be sent in network byte 633 order. 635 5.1 COMMON-HEADER Format 637 The following is format of the common header. 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Ver |Reserved | Primitive | Payload Length | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Conference ID | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Transaction ID | User ID | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Figure 5: COMMON-HEADER format 651 Ver: the 3-bit version field MUST be set to 1 to indicate this 652 version of BFCP. 654 Reserved: at this point, the 5 bits in the reserved field SHOULD be 655 set to zero by the sender of the message and MUST be ignored by the 656 receiver. 658 Primitive: this 8-bit field identifies the main purpose of the 659 message. The following primitive values are defined: 661 +-------+--------------------+-----------------------+ 662 | Value | Primitive | Direction | 663 +-------+--------------------+-----------------------+ 664 | 1 | FloorRequest | P -> S | 665 | 2 | FloorRelease | P -> S | 666 | 3 | FloorRequestQuery | P -> S ; Ch -> S | 667 | 4 | FloorRequestStatus | P <- S ; Ch <- S | 668 | 5 | UserQuery | P -> S ; Ch -> S | 669 | 6 | UserStatus | P <- S ; Ch <- S | 670 | 7 | FloorQuery | P -> S ; Ch -> S | 671 | 8 | FloorStatus | P <- S ; Ch <- S | 672 | 9 | ChairAction | Ch -> S | 673 | 10 | ChairActionAck | Ch <- S | 674 | 11 | Hello | P -> S ; Ch -> S | 675 | 12 | HelloAck | P <- S ; Ch <- S | 676 | 13 | Error | P <- S ; Ch <- S | 677 +-------+--------------------+-----------------------+ 679 S: Floor Control Server 680 P: Floor Participant 681 Ch: Floor Chair 683 Table 1: BFCP primitives 685 Payload Length: this 16-bit field contains length of the message in 686 4-byte units excluding the common header. 688 Conference ID: this 32-bit field identifies the conference the 689 message belongs to. 691 Transaction ID: this field contains a 16-bit value that allows users 692 to match a given message with its response. The value of the 693 Transaction ID in server-initiated transactions is 0 (see Section 8). 695 User ID: this field contains a 16-bit value that uniquely identifies 696 a participant within a conference. 698 The identity used by a participant in BFCP, which is carried in 699 the User ID field, is generally mapped to the identity used by the 700 same participant in the session establishment protocol (e.g., in 701 SIP). The way this mapping is performed is outside the scope of 702 this specification. 704 5.2 Attribute Format 706 BFCP attributes are encoded in TLV (Type-Length-Value) format. 707 Attributes are 32-bit aligned. 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Type |M| Length | | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 714 | | 715 / Attribute Contents / 716 / / 717 | | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Figure 6: Attribute format 722 Type: this 7-bit field contains the type of the attribute. Each 723 attribute, identified by its type, has a particular format. The 724 attribute formats defined are: 726 Unsigned16: the contents of the attribute consist of a 16-bit 727 unsigned integer. 729 OctetString16: the contents of the attribute consist of 16 bits of 730 arbitrary data. 732 OctetString: the contents of the attribute consist of arbitrary 733 data of variable length. 735 Grouped: the contents of the attribute consist of a sequence of 736 attributes. 738 Note that extension attributes defined in the future may define new 739 attribute formats. 741 The following attribute types are defined: 743 +------+---------------------------+---------------+ 744 | Type | Attribute | Format | 745 +------+---------------------------+---------------+ 746 | 1 | BENEFICIARY-ID | Unsigned16 | 747 | 2 | FLOOR-ID | Unsigned16 | 748 | 3 | FLOOR-REQUEST-ID | Unsigned16 | 749 | 4 | NONCE | Unsigned16 | 750 | 5 | PRIORITY | OctetString16 | 751 | 6 | REQUEST-STATUS | OctetString16 | 752 | 7 | DIGEST | OctetString | 753 | 8 | ERROR-CODE | OctetString | 754 | 9 | ERROR-INFO | OctetString | 755 | 10 | PARTICIPANT-PROVIDED-INFO | OctetString | 756 | 11 | STATUS-INFO | OctetString | 757 | 12 | SUPPORTED-ATTRIBUTES | OctetString | 758 | 13 | SUPPORTED-PRIMITIVES | OctetString | 759 | 14 | USER-DISPLAY-NAME | OctetString | 760 | 15 | USER-URI | OctetString | 761 | 16 | BENEFICIARY-INFORMATION | Grouped | 762 | 17 | FLOOR-REQUEST-INFORMATION | Grouped | 763 | 18 | REQUESTED-BY-INFORMATION | Grouped | 764 +------+---------------------------+---------------+ 766 Table 2: BFCP attributes 768 M: the 'M' bit, known as the Mandatory bit, indicates whether support 769 of the attribute is required. If an unrecognized attribute with the 770 'M' bit set is received, the message is rejected. 772 Length: this 8-bit field contains the length of the attribute in 773 bytes, excluding any padding defined for specific attributes. The 774 Type, 'M' bit, and Length fields are included. The Length in grouped 775 attributes is the length of the grouped attribute itself (including 776 Type, 'M' bit, and Length fields) plus the total length (including 777 padding) of all the included attributes. 779 Attribute Contents: the contents of the different attributes are 780 defined in the following sections. 782 5.2.1 BENEFICIARY-ID 784 The following is the format of the BENEFICIARY-ID attribute. 786 0 1 2 3 787 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 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Figure 7: BENEFICIARY-ID format 794 Beneficiary ID: this field contains a 16-bit value that uniquely 795 identifies a user within a conference. 797 Note that although the formats of the Beneficiary ID and of the User 798 ID field in the common header are similar, their semantics are 799 different. The Beneficiary ID is used in third-party floor requests 800 and to request information about a particular participant. 802 5.2.2 FLOOR-ID 804 The following is the format of the FLOOR-ID attribute. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Figure 8: FLOOR-ID format 814 Floor ID: this field contains a 16-bit value that uniquely identifies 815 a floor within a conference. 817 5.2.3 FLOOR-REQUEST-ID 819 The following is the format of the FLOOR-REQUEST-ID attribute. 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Figure 9: FLOOR-REQUEST-ID format 829 Floor Request ID: this field contains a 16-bit value that identifies 830 a floor request at the floor control server. 832 5.2.4 NONCE 834 The following is the format of the NONCE attribute. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0| Nonce Value | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Figure 10: NONCE format 844 Nonce Value: this 16-bit field contains a nonce. 846 5.2.5 PRIORITY 848 The following is the format of the PRIORITY attribute. 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Prio | Reserved | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Figure 11: PRIORITY format 858 Prio: this field contains a 3-bit priority value as shown in Table 3. 859 Senders SHOULD NOT use values higher than 4 in this field. Receivers 860 MUST treat values higher than 4 as if the value received had been 4 861 (Highest). The default priority value when the PRIORITY attribute is 862 missing is 2 (Normal). 864 +-------+----------+ 865 | Value | Priority | 866 +-------+----------+ 867 | 0 | Lowest | 868 | 1 | Low | 869 | 2 | Normal | 870 | 3 | High | 871 | 4 | Highest | 872 +-------+----------+ 874 Table 3: Priority values 876 Reserved: at this point, the 13 bits in the reserved field SHOULD be 877 set to zero by the sender of the message and MUST be ignored by the 878 receiver. 880 5.2.6 REQUEST-STATUS 882 The following is the format of the REQUEST-STATUS attribute. 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 |0 0 0 0 1 1 0|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 Figure 12: REQUEST-STATUS format 892 Request Status: this 8-bit field contains the status of the request, 893 as described in the following table. 895 +-------+-----------+ 896 | Value | Status | 897 +-------+-----------+ 898 | 1 | Pending | 899 | 2 | Accepted | 900 | 3 | Granted | 901 | 4 | Denied | 902 | 5 | Cancelled | 903 | 6 | Released | 904 | 7 | Revoked | 905 +-------+-----------+ 907 Table 4: Request Status values 909 Queue Position: this 8-bit field contains, when applicable, the 910 position of the floor request in the floor request queue at the 911 server. If the Request Status value is different from Accepted, the 912 floor control server does not implement a floor request queue, or the 913 floor control server does not want to provide the client with this 914 information, all the bits of this field SHOULD be set to zero. 916 A floor request is in Pending state if the floor control server needs 917 to contact a floor chair in order to accept the floor request, but 918 has not done it yet. Once the floor control chair accepts the floor 919 request, the floor request is moved to the Accepted state. 921 5.2.7 DIGEST 923 The following is the format of the DIGEST attribute. 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 |0 0 0 0 1 1 1|M|0 0 0 1 1 0 0 0| Algorithm | | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 930 | | 931 + + 932 | | 933 + Digest + 934 | | 935 + + 936 | | 937 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | | Padding | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Figure 13: DIGEST format 943 Algorithm: this 8-bit field contains the identifier of the algorithm 944 used to calculate the keyed digest. The following are the algorithm 945 identifiers defined: 947 +------------+-----------+---------------+--------------+ 948 | Identifier | Algorithm | Digest Length | Reference | 949 +------------+-----------+---------------+--------------+ 950 | 0 | HMAC-SHA1 | 20 bytes | RFC 2104 [1] | 951 +------------+-----------+---------------+--------------+ 953 Table 5: Digest algorithms 955 The text used as input to the digest algorithm is the BFCP 956 message, including the common header, up to and including the 957 attribute preceding the DIGEST attribute. Depending on the 958 algorithm, this text may need to be padded with zeroes. When 959 HMAC-SHA1 is used, the input text needs to be padded so as to be a 960 multiple of 64 bytes. 961 The key used as input to the keyed digest is the secret shared 962 between the server and the user identified by the User ID in the 963 common header of the message. 965 Digest: this field contains a keyed digest of the BFCP message. Its 966 calculation is described in Section 9. 968 Padding: padding added so that the contents of the DIGEST attribute 969 is 32-bit aligned. The Padding bits SHOULD be set to zero by the 970 sender and MUST be ignored by the receiver. 972 5.2.8 ERROR-CODE 974 The following is the format of the ERROR-CODE attribute. 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 |0 0 0 1 0 0 0|M| Length | Error Code | | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 981 | | 982 | Error Specific Details | 983 / / 984 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | | Padding | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Figure 14: ERROR-CODE format 990 Error Code: this 8-bit field contains an error code from the 991 following table. 993 +---------------------------------+---------------------------------+ 994 | Value | Meaning | 995 +---------------------------------+---------------------------------+ 996 | 1 | Conference does not Exist | 997 | 2 | User does not Exist | 998 | 3 | DIGEST Attribute Required | 999 | 4 | Invalid Nonce | 1000 | 5 | Authentication Failed | 1001 | 6 | Unknown Primitive | 1002 | 7 | Unknown Mandatory Attribute | 1003 | 8 | Unauthorized Operation | 1004 | 9 | Invalid Floor ID | 1005 | 10 | Floor Request ID Does Not Exist | 1006 | 11 | You have Already Reached the | 1007 | | Maximum Number of Ongoing Floor | 1008 | | Requests for this Floor | 1009 +---------------------------------+---------------------------------+ 1011 Table 6: Error Code meaning 1013 Error Specific Details: Present only for certain Error Codes. In 1014 this document, only for Error Code 3 (DIGEST Attribute Needed) and 1015 Error Code 7 (Unknown Mandatory Attribute). See Section 5.2.8.1 and 1016 Section 5.2.8.2 for their respective definitions. 1018 Padding: one, two, or three bytes of padding added so that the 1019 contents of the ERROR-CODE attribute is 32-bit aligned. If the 1020 attribute is already 32-bit aligned, no padding is needed. 1022 The Padding bits SHOULD be set to zero by the sender and MUST be 1023 ignored by the receiver. 1025 5.2.8.1 Error Specific Details for Error Code 3 1027 The following is the format of the Error Specific Details field for 1028 Error Code 3. 1030 0 1 2 3 1031 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 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Algorithm ID | Algorithm ID | Algorithm ID | Algorithm ID | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | | 1036 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | | Algorithm ID | Algorithm ID | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Algorithm ID | Algorithm ID | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 Figure 15: Digest algorithms format 1044 Algorithm ID: these 8-bit fields contain the identifiers of the 1045 digest algorithms supported by the floor control server in order of 1046 preference (i.e., the first algorithm is the most preferred). 1048 5.2.8.2 Error Specific Details for Error Code 7 1050 The following is the format of the Error Specific Details field for 1051 Error Code 7. 1053 0 1 2 3 1054 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 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | | 1059 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | | Unknown Type|R| Unknown Type|R| 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Unknown Type|R| Unknown Type|R| 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Figure 16: Unknown attributes format 1067 Unknown Type: these 7-bit fields contain the Types of the attributes 1068 (which were present in the message that triggered the Error message) 1069 that were unknown to the receiver 1071 R: at this point, this bit is reserved. It SHOULD be set to zero by 1072 the sender of the message and MUST be ignored by the receiver. 1074 5.2.9 ERROR-INFO 1076 The following is the format of the ERROR-INFO attribute. 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 |0 0 0 1 0 0 1|M| Length | | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1083 | | 1084 / Text / 1085 / +-+-+-+-+-+-+-+-+ 1086 | | Padding | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 Figure 17: ERROR-INFO format 1091 Text: this field contains UTF-8 [7] encoded text. 1093 In some situations, the contents of the Text field may be generated 1094 by an automaton. If such automaton has information about the 1095 preferred language of the receiver of a particular ERROR-INFO 1096 attribute, it MAY use this language to generate the Text field. 1098 Padding: one, two, or three bytes of padding added so that the 1099 contents of the ERROR-INFO attribute is 32-bit aligned. The Padding 1100 bits SHOULD be set to zero by the sender and MUST be ignored by the 1101 receiver. If the attribute is already 32-bit aligned, no padding is 1102 needed. 1104 5.2.10 PARTICIPANT-PROVIDED-INFO 1106 The following is the format of the PARTICIPANT-PROVIDED-INFO 1107 attribute. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 |0 0 0 1 0 1 0|M| Length | | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1114 | | 1115 / Text / 1116 / +-+-+-+-+-+-+-+-+ 1117 | | Padding | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Figure 18: PARTICIPANT-PROVIDED-INFO format 1122 Text: this field contains UTF-8 [7] encoded text. 1124 Padding: one, two, or three bytes of padding added so that the 1125 contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit 1126 aligned. The Padding bits SHOULD be set to zero by the sender and 1127 MUST be ignored by the receiver. If the attribute is already 32-bit 1128 aligned, no padding is needed. 1130 5.2.11 STATUS-INFO 1132 The following is the format of the STATUS-INFO attribute. 1134 0 1 2 3 1135 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 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 |0 0 0 1 0 1 1|M| Length | | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1139 | | 1140 / Text / 1141 / +-+-+-+-+-+-+-+-+ 1142 | | Padding | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 Figure 19: STATUS-INFO format 1147 Text: this field contains UTF-8 [7] encoded text. 1149 In some situations, the contents of the Text field may be generated 1150 by an automaton. If such automaton has information about the 1151 preferred language of the receiver of a particular STATUS-INFO 1152 attribute, it MAY use this language to generate the Text field. 1154 Padding: one, two, or three bytes of padding added so that the 1155 contents of the STATUS-INFO attribute is 32-bit aligned. The Padding 1156 bits SHOULD be set to zero by the sender and MUST be ignored by the 1157 receiver. If the attribute is already 32-bit aligned, no padding is 1158 needed. 1160 5.2.12 SUPPORTED-ATTRIBUTES 1162 The following is the format of the SUPPORTED-ATTRIBUTES attribute. 1164 0 1 2 3 1165 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 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 |0 0 0 1 1 0 0|M| Length | Supported Attribute | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Supported Attribute | Supported Attribute | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | | 1172 / / 1173 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | | Padding | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 Figure 20: SUPPORTED-ATTRIBUTES format 1179 Supported Attribute: these fields contain the Types of the attributes 1180 that are supported by the floor control server. 1182 Padding: two bytes of padding added so that the contents of the 1183 SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute 1184 is already 32-bit aligned, no padding is needed. 1186 The Padding bits SHOULD be set to zero by the sender and MUST be 1187 ignored by the receiver. 1189 5.2.13 SUPPORTED-PRIMITIVES 1191 The following is the format of the SUPPORTED-PRIMITIVES attribute. 1193 0 1 2 3 1194 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 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 |0 0 0 1 1 0 1|M| Length | Primitive | Primitive | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | Primitive | Primitive | Primitive | Primitive | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | | 1201 / / 1202 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | | Padding | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 Figure 21: SUPPORTED-PRIMITIVES format 1208 Primitive: these fields contain the types of the BFCP messages that 1209 are supported by the floor control server. See Table 1 for the list 1210 of BFCP primitives. 1212 Padding: one, two, or three bytes of padding added so that the 1213 contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If 1214 the attribute is already 32-bit aligned, no padding is needed. 1216 The Padding bits SHOULD be set to zero by the sender and MUST be 1217 ignored by the receiver. 1219 5.2.14 USER-DISPLAY-NAME 1221 The following is the format of the USER-DISPLAY-NAME attribute. 1223 0 1 2 3 1224 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 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 |0 0 0 1 1 1 0|M| Length | | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1228 | | 1229 / Text / 1230 / +-+-+-+-+-+-+-+-+ 1231 | | Padding | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 Figure 22: USER-DISPLAY-NAME format 1236 Text: this field contains the UTF-8 encoded name of the user. 1238 Padding: one, two, or three bytes of padding added so that the 1239 contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The 1240 Padding bits SHOULD be set to zero by the sender and MUST be ignored 1241 by the receiver. If the attribute is already 32-bit aligned, no 1242 padding is needed. 1244 5.2.15 USER-URI 1246 The following is the format of the USER-URI attribute. 1248 0 1 2 3 1249 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 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 |0 0 0 1 1 1 1|M| Length | | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1253 | | 1254 / Text / 1255 / +-+-+-+-+-+-+-+-+ 1256 | | Padding | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Figure 23: USER-URI format 1261 Text: this field contains the UTF-8 encoded URI of the user. 1263 Padding: one, two, or three bytes of padding added so that the 1264 contents of the USER-URI attribute is 32-bit aligned. The Padding 1265 bits SHOULD be set to zero by the sender and MUST be ignored by the 1266 receiver. If the attribute is already 32-bit aligned, no padding is 1267 needed. 1269 5.2.16 BENEFICIARY-INFORMATION 1271 The BENEFICIARY-INFORMATION attribute is a grouped attribute that 1272 consists of a header, which is referred to as BENEFICIARY- 1273 INFORMATION-HEADER, followed by a sequence of attributes. The 1274 following is the format of the BENEFICIARY-INFORMATION-HEADER: 1276 0 1 2 3 1277 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 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 |0 0 1 0 0 0 0|M| Length | Beneficiary ID | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1282 Figure 24: BENEFICIARY-INFORMATION-HEADER format 1284 Beneficiary ID: this field contains a 16-bit value that uniquely 1285 identifies a user within a conference. 1287 The following is the ABNF (Augmented Backus-Naur Form) [3] of the 1288 BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE 1289 refers to extension attributes that may be defined in the future.) 1290 BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) 1291 [USER-DISPLAY-NAME] 1292 [USER-URI] 1293 *[EXTENSION-ATTRIBUTE] 1295 Figure 25: BENEFICIARY-INFORMATION format 1297 5.2.17 FLOOR-REQUEST-INFORMATION 1299 The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that 1300 consists of a header, which is referred to as FLOOR-REQUEST- 1301 INFORMATION-HEADER, followed by a sequence of attributes. The 1302 following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 1304 0 1 2 3 1305 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 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 |0 0 1 0 0 0 1|M| Length | Floor Request ID | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 Figure 26: FLOOR-REQUEST-INFORMATION-HEADER format 1312 Floor Request ID: this field contains a 16-bit value that identifies 1313 a floor request at the floor control server. 1315 The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped 1316 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1317 may be defined in the future.) 1319 FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) 1320 (REQUEST-STATUS) 1321 1*(FLOOR-ID) 1322 [BENEFICIARY-INFORMATION] 1323 [REQUESTED-BY-INFORMATION] 1324 [PRIORITY] 1325 [PARTICIPANT-PROVIDED-INFO] 1326 [STATUS-INFO] 1327 *[EXTENSION-ATTRIBUTE] 1329 Figure 27: FLOOR-REQUEST-INFORMATION format 1331 5.2.18 REQUESTED-BY-INFORMATION 1333 The REQUESTED-BY-INFORMATION attribute is a grouped attribute that 1334 consists of a header, which is referred to as REQUESTED-BY- 1335 INFORMATION-HEADER, followed by a sequence of attributes. The 1336 following is the format of the REQUESTED-BY-INFORMATION-HEADER: 1338 0 1 2 3 1339 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 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 |0 0 1 0 0 1 0|M| Length | Requested-by ID | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 Figure 28: REQUESTED-BY-INFORMATION-HEADER format 1346 Requested-by ID: this field contains a 16-bit value that uniquely 1347 identifies a user within a conference. 1349 The following is the ABNF of the REQUESTED-BY-INFORMATION grouped 1350 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1351 may be defined in the future.) 1353 REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) 1354 [USER-DISPLAY-NAME] 1355 [USER-URI] 1356 *[EXTENSION-ATTRIBUTE] 1358 Figure 29: REQUESTED-BY-INFORMATION format 1360 5.3 Message Format 1362 This section contains the normative ABNF (Augmented Backus-Naur Form) 1363 [3] of the BFCP messages. Extension attributes that may be defined 1364 in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 1366 5.3.1 FloorRequest 1368 Floor participants request a floor by sending a FloorRequest message 1369 to the floor control server. The following is the format of the 1370 FloorRequest message: 1372 FloorRequest = (COMMON-HEADER) 1373 *(FLOOR-ID) 1374 [BENEFICIARY-ID] 1375 [PARTICIPANT-PROVIDED-INFO] 1376 [PRIORITY] 1377 *[EXTENSION-ATTRIBUTE] 1378 [NONCE] 1379 [DIGEST] 1381 Figure 30: FloorRequest format 1383 5.3.2 FloorRelease 1385 Floor participants release a floor by sending a FloorRelease message 1386 to the floor control server. Floor participants also use the 1387 FloorRelease message to cancel pending floor requests. The following 1388 is the format of the FloorRelease message: 1390 FloorRelease = (COMMON-HEADER) 1391 (FLOOR-REQUEST-ID) 1392 *[EXTENSION-ATTRIBUTE] 1393 [NONCE] 1394 [DIGEST] 1396 Figure 31: FloorRelease format 1398 5.3.3 FloorRequestQuery 1400 Floor participants and floor chairs request information about a floor 1401 request by sending a FloorRequestQuery message to the floor control 1402 server. The following is the format of the FloorRequestQuery 1403 message: 1405 FloorRequestQuery = (COMMON-HEADER) 1406 (FLOOR-REQUEST-ID) 1407 *[EXTENSION-ATTRIBUTE] 1408 [NONCE] 1409 [DIGEST] 1411 Figure 32: FloorRequestQuery format 1413 5.3.4 FloorRequestStatus 1415 The floor control server informs floor participants and floor chairs 1416 about the status of their floor requests by sending them 1417 FloorRequestStatus messages. The following is the format of the 1418 FloorRequestStatus message: 1420 FloorRequestStatus = (COMMON-HEADER) 1421 (FLOOR-REQUEST-INFORMATION) 1422 [NONCE] 1423 *[EXTENSION-ATTRIBUTE] 1425 Figure 33: FloorRequestStatus format 1427 5.3.5 UserQuery 1429 Floor participants and floor chairs request information about a 1430 participant and the floor requests related to this participant by 1431 sending a UserQuery message to the floor control server. The 1432 following is the format of the UserQuery message: 1434 UserQuery = (COMMON-HEADER) 1435 [BENEFICIARY-ID] 1436 *[EXTENSION-ATTRIBUTE] 1437 [NONCE] 1438 [DIGEST] 1440 Figure 34: UserQuery format 1442 5.3.6 UserStatus 1444 The floor control server provide information about participants and 1445 their related floor requests to floor participants and floor chairs 1446 by sending them UserStatus messages. The following is the format of 1447 the UserStatus message: 1449 UserStatus = (COMMON-HEADER) 1450 [BENEFICIARY-INFORMATION] 1451 1*(FLOOR-REQUEST-INFORMATION) 1452 [NONCE] 1453 *[EXTENSION-ATTRIBUTE] 1455 Figure 35: UserStatus format 1457 5.3.7 FloorQuery 1459 Floor participants and floor chairs request information about a floor 1460 or floors by sending a FloorQuery message to the floor control 1461 server. The following is the format of the FloorRequest message: 1463 FloorQuery = (COMMON-HEADER) 1464 *(FLOOR-ID) 1465 *[EXTENSION-ATTRIBUTE] 1466 [NONCE] 1467 [DIGEST] 1469 Figure 36: FloorQuery format 1471 5.3.8 FloorStatus 1473 The floor control server informs floor participants and floor chairs 1474 about the status (e.g., the current holder) of a floor by sending 1475 them FloorStatus messages. The following is the format of the 1476 FloorStatus message: 1478 FloorStatus = (COMMON-HEADER) 1479 (FLOOR-ID) 1480 *[FLOOR-REQUEST-INFORMATION] 1481 [NONCE] 1482 *[EXTENSION-ATTRIBUTE] 1484 Figure 37: FloorStatus format 1486 5.3.9 ChairAction 1488 Floor chairs send instructions to floor control servers by sending 1489 ChairAction messages. The following is the format of the ChairAction 1490 message: 1492 ChairAction = (COMMON-HEADER) 1493 1*(FLOOR-ID) 1494 (FLOOR-REQUEST-ID) 1495 (REQUEST-STATUS) 1496 [STATUS-INFO] 1497 *[EXTENSION-ATTRIBUTE] 1498 [NONCE] 1499 [DIGEST] 1501 Figure 38: ChairAction format 1503 5.3.10 ChairActionAck 1505 Floor control servers confirm that they have accepted a ChairAction 1506 message by sending a ChairActionAck message. The following is the 1507 format of the ChairActionAck message: 1509 ChairActionAck = (COMMON-HEADER) 1510 [NONCE] 1511 *[EXTENSION-ATTRIBUTE] 1513 Figure 39: ChairActionAck format 1515 5.3.11 Hello 1517 Floor participants and floor chairs check the liveness of floor 1518 control servers by sending a Hello message. The following is the 1519 format of the Hello message: 1521 Hello = (COMMON-HEADER) 1522 *[EXTENSION-ATTRIBUTE] 1523 [NONCE] 1524 [DIGEST] 1526 Figure 40: Hello format 1528 5.3.12 HelloAck 1530 Floor control servers confirm that they are alive on reception of a 1531 Hello message by sending a HelloAck message. The following is the 1532 format of the HelloAck message: 1534 HelloAck = (COMMON-HEADER) 1535 (SUPPORTED-PRIMITIVES) 1536 (SUPPORTED-ATTRIBUTES) 1537 [NONCE] 1538 *[EXTENSION-ATTRIBUTE] 1540 Figure 41: HelloAck format 1542 5.3.13 Error 1544 Floor control servers inform floor participants and floor chairs 1545 about errors processing requests by sending them Error messages. The 1546 following is the format of the Error message: 1548 Error = (COMMON-HEADER) 1549 (ERROR-CODE) 1550 [NONCE] 1551 [ERROR-INFO] 1552 *[EXTENSION-ATTRIBUTE] 1554 Figure 42: Error format 1556 6. Transport 1558 BFCP entities exchange BFCP messages using TCP connections. TCP 1559 provides an in-order reliable delivery of a stream of bytes. 1560 Consequently, message framing is implemented in the application 1561 layer. BFCP implements application-layer framing using TLV-encoded 1562 attributes. 1564 A client MUST NOT use more than one TCP connection to communicate 1565 with a given floor control server within a conference. Nevertheless, 1566 if the same physical box handles different clients (e.g., a floor 1567 chair and a floor participant), which are identified by different 1568 User IDs, a separate connection per client is allowed. 1570 If a BFCP entity (a client or a floor control server) receives data 1571 from TCP that cannot be parsed the entity MUST close the TCP 1572 connection using a RESET call (send a TCP RST bit) and the connection 1573 SHOULD be reestablished. Similarly, if a TCP connection cannot 1574 deliver a BFCP message and times out, the TCP connection SHOULD be 1575 reestablished. 1577 The way connection reestablishment is handled depends on how the 1578 client obtains information to contact the floor control server (e.g., 1579 using an offer/answer exchange [13]). Once the TCP connection is 1580 reestablished, the client MAY resend those message it did not get a 1581 response for from the floor control server. 1583 If a floor control server detects that the TCP connection towards one 1584 of the floor participants is lost, it is up to the local policy of 1585 the floor control server what to do with the pending floor requests 1586 of the floor participant. In any case, it is RECOMMENDED that the 1587 floor control server keeps the floor requests (i.e., does not cancel 1588 them) while the TCP connection is reestablished. 1590 If a client wishes to end its BFCP connection with a floor control 1591 server, the client closes (i.e., a graceful close) the TCP connection 1592 towards the floor control server. If a floor control server wishes 1593 to end its BFCP connection with a client (e.g., the Focus of the 1594 conference informs the floor control server that the client has been 1595 kicked out from the conference), the floor control server closes 1596 (i.e., a graceful close) the TCP connection towards the client. 1598 7. Lower-Layer Security 1600 BFCP relies on lower-layer security mechanisms to provide replay and 1601 integrity protection, and confidentiality. BFCP floor control 1602 servers MUST support TLS [4], and BFCP clients (which include both 1603 floor participants and floor chairs) SHOULD support TLS. Any BFCP 1604 entity MAY support other security mechanisms. 1606 BFCP entities that implement TLS MUST support, at a minimum, the TLS 1607 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. 1609 8. Protocol Transactions 1611 In BFCP, there are two types of transactions: client-initiated 1612 transactions and server-initiated transactions (notifications). 1613 Client-initiated transactions consist of a request from a client to a 1614 floor control server and a response from the floor control server to 1615 the client. The request carries a Transaction ID in its common 1616 header which the floor control server copies into the response. 1617 Clients use Transaction ID values to match responses with previously- 1618 issued requests. 1620 Server-initiated transactions consist of a single message from a 1621 floor control server to a client. Since they do not trigger any 1622 response, their Transaction ID is set to 0. 1624 8.1 Client Behavior 1626 A client starting a client-initiated transaction MUST set the 1627 Conference ID in the common header of the message to the Conference 1628 ID for the conference that the client obtained previously. 1630 The client MUST set the Transaction ID value in the common header to 1631 a number which is different to 0 and which MUST NOT be reused in 1632 another message from the client until a response from the server is 1633 received for the transaction. The client uses the Transaction ID 1634 value to match this message with the response from the floor control 1635 server. 1637 8.2 Server Behavior 1639 A floor control server sending a response within a client-initiated 1640 transaction MUST copy the Conference ID, the Transaction ID, and the 1641 User ID from the request received from the client into the response. 1642 Server-initiated transactions MUST contain a Transaction ID equal to 1643 0. 1645 9. Authentication and Authorization 1647 BFCP clients SHOULD authenticate the floor control server before 1648 sending any BFCP message to it. Similarly, floor control servers 1649 SHOULD authenticate a client before accepting any BFCP message from 1650 it. 1652 BFCP supports TLS-based mutual authentication between clients and 1653 floor control servers, as specified in Section 9.1. This is the 1654 RECOMMENDED authentication mechanism in BFCP. 1656 Additionally, BFCP also provides a digest mechanism based on a shared 1657 secret to provide client authentication in situations where TLS is 1658 not used for some reason. This mechanism is described in 1659 Section 9.2. 1661 9.1 TLS-based Mutual Authentication 1663 BFCP supports TLS-based mutual authentication between clients and 1664 floor control servers. Authentication based on both, certificates 1665 signed by a certificate authority and self-signed certificates is 1666 supported. 1668 If a client and a floor control server have certificates signed by a 1669 certificate authority known to both, they can use these certificates 1670 to authenticate each other at TLS establishment time. Otherwise, 1671 BFCP assumes that there is an integrity-protected channel between the 1672 client and the floor control server that can be used to exchange 1673 their self-signed certificates or, more commonly, the fingerprints of 1674 these certificates. These certificates are used at TLS establishment 1675 time. 1677 The implementation of such an integrity-protected channel using 1678 SIP and the offer/answer model is described in [13]. 1680 9.2 Digest-based Client Authentication 1682 BFCP supports digest-based client authentication based on a shared 1683 secret between a client and the floor control server. It is assumed 1684 that an encrypted and integrity-protected channel exists between the 1685 client and the floor control server. This channel is used to 1686 generate a shared secret between them. 1688 The implementation of such an encrypted and integrity-protected 1689 channel using SIP and the offer/answer model is described in [13]. 1691 Digest-based client authentication in BFCP is based on the DIGEST 1692 attribute. This attribute contains an algorithm identifier and a 1693 keyed digest of the of the BFCP message using that algorithm. The 1694 text used as input to the digest algorithm is the BFCP message, 1695 including the common header, up to and including the attribute 1696 preceding the DIGEST attribute. Depending on the algorithm, this 1697 text may need to be padded with zeroes. Section 5.2.7 lists the 1698 algorithms specified in BFCP. 1700 The key used as input to the keyed digest is the secret shared 1701 between the server and the user identified by the User ID in the 1702 common header of the message. 1704 Section 9.2.1 and Section 9.2.2 discuss how to achieve client 1705 authentication using the DIGEST attribute. 1707 9.2.1 Client Behavior 1709 To achieve client authentication, a client needs to prove to the 1710 floor control server that the client can produce a DIGEST attribute 1711 for a message using their shared secret and that the message is fresh 1712 (to avoid replay attacks). Clients prove the freshness of a message 1713 by including a NONCE attribute in the message. The NONCE attribute 1714 is the second to last attribute in the message (the last one is the 1715 DIGEST attribute). 1717 Clients can obtain the digest algorithms supported by the floor 1718 control server in an Error response from the floor control server 1719 with Error Code 3 (DIGEST Attribute Required). A client SHOULD use 1720 the first digest algorithm in the list that it supports. 1722 Additionally, as an optimization, the floor control server and the 1723 client can agree on the algorithm to be used using an out-of-band 1724 mechanism (e.g., using an offer/answer exchange as described in 1725 [13]). This way, the client does not need to generate an initial 1726 BFCP message only to have it rejected by the floor control server 1727 with an Error response containing a list with its supported 1728 algorithms. 1730 If after sending a message with a DIGEST attribute, a client receives 1731 an Error response with Error Code 3 (DIGEST Attribute Required) with 1732 a list of digest algorithms, the client SHOULD re-send the message 1733 using the first digest algorithm in the list that it supports. 1735 The nonce to be placed in the NONCE attribute by the client is 1736 typically provided by the floor control server in an Error response 1737 -- typically with Error Code 3 (DIGEST Attribute Required) or 6 1738 (Invalid Nonce). Additionally, as an optimization, the floor control 1739 server can provide a client with a NONCE to be used in the first 1740 message generated by the client using an out-of-band mechanism (e.g., 1741 using an offer/answer exchange as described in [13]). This way, the 1742 client does not need to generate an initial BFCP message only to have 1743 it rejected by the floor control server with an Error response 1744 containing a nonce. 1746 A client that obtains a nonce out-of-band SHOULD add a NONCE 1747 attribute and a DIGEST attribute to the first message it sends to the 1748 floor control server. Furthermore, if any client generates a message 1749 without a DIGEST attribute and receives an Error response with Error 1750 Code 3 (DIGEST Attribute Required), the client SHOULD re-send the 1751 message with a DIGEST attribute and a NONCE attribute with the nonce 1752 received in the Error response. 1754 If after sending a message with a DIGEST attribute, a client receives 1755 an Error response with Error Code 4 (Invalid Nonce), the client 1756 SHOULD re-send the message using the new nonce received in the Error 1757 response. If the Error Code is 5 (Authentication Failed) instead, 1758 the client MUST NOT send further messages to the floor control server 1759 until it has obtained a different (hopefully valid) shared secret 1760 than the one used in the original message. 1762 If a client receives a nonce in a message from the floor control 1763 server, the client SHOULD add a NONCE attribute with this nonce and a 1764 DIGEST attribute to its next message to the floor control server. 1766 9.2.2 Floor Control Server Behavior 1768 If the floor control server receives a message without DIGEST 1769 attribute from an unauthenticated client, the floor control server 1770 responds with an Error message with Error Code 3 (DIGEST Attribute 1771 Required). The floor control message MUST include a list with the 1772 digest algorithms supported by the floor control server in order of 1773 preference (i.e., the first algorithm is the most preferred) and a 1774 NONCE attribute with a nonce value that is unguessable by attackers. 1776 When a floor control server receives a BFCP message with a DIGEST 1777 attribute, it checks whether the Algorithm identifier in the DIGEST 1778 attribute corresponds to an algorithm that is supported by the floor 1779 control server. If it does not, the floor control server SHOULD 1780 return an Error message with Error Code 3 (DIGEST Attribute Required) 1781 with a list with the digest algorithms supported by the floor control 1782 server. 1784 If the algorithm identifier is valid, the floor control server checks 1785 whether the NONCE attribute carries a nonce which was generated by 1786 the floor control server for this client and which still has not 1787 expired. If the nonce is not valid, authentication is considered to 1788 have failed, in which case the floor control server SHOULD return an 1789 Error message with Error Code 4 (Invalid Nonce) with a new nonce in a 1790 NONCE attribute. 1792 If the nonce is valid, the floor control server calculates the keyed 1793 digest of the message using the algorithm identified by the DIGEST 1794 attribute. The key used as input to the keyed digest is the secret 1795 shared between the server and the user identified by the User ID in 1796 the common header of the message. If the resulting value is the same 1797 as the one in the DIGEST attribute, authentication is considered 1798 successful. 1800 If the resulting value is different than the one in the DIGEST 1801 attribute, authentication is considered to have failed, in which case 1802 the server SHOULD return an Error message, as described in 1803 Section 13.8, with Error Code 5 (Authentication Failed). Messages 1804 from a client that cannot be authenticated MUST NOT be processed 1805 further. 1807 Floor control servers MAY include a NONCE attribute in their 1808 responses to provide the nonce to be used in the next message by the 1809 client. However, when TLS is used, floor control servers typically 1810 authenticate only the first message sent over the TLS connection. 1812 After authenticating a BFCP message, the floor control server checks 1813 whether or not the client is authorized to perform the operation it 1814 is requesting. If the client is not authorized to perform the 1815 operation being requested, the floor control server generates an 1816 Error message, as described in Section 13.8, with an Error code with 1817 a value of 8 (Unauthorized Operation). Messages from a client that 1818 cannot be authorized MUST NOT be processed further. 1820 10. Floor Participant Operations 1822 This section specifies how floor participants can perform different 1823 operations, such as requesting a floor, using the protocol elements 1824 described in earlier sections. Section 11 specifies operations that 1825 are specific to floor chairs, such as instructing the floor control 1826 server to grant or revoke a floor, and Section 12 specifies 1827 operations that can be performed by any client (i.e., both floor 1828 participants and floor chairs). 1830 10.1 Requesting a Floor 1832 A floor participant that wishes to request one or more floors does so 1833 by sending a FloorRequest message to the floor control server. 1835 10.1.1 Sending a FloorRequest Message 1837 The ABNF in Section 5.3.1 describes the attributes that a 1838 FloorRequest message can contain. In addition, the ABNF specifies 1839 normatively which of these attributes are mandatory, and which ones 1840 are optional. 1842 The floor participant sets the Conference ID and the Transaction ID 1843 in the common header following the rules given in Section 8.1. 1844 Additionally, the floor participant follows the rules in Section 9 1845 which relate to the authentication of the message. 1847 The floor participant sets the User ID in the common header to the 1848 floor participant's identifier. This User ID will be used by the 1849 floor control server to authenticate and authorize the request. If 1850 the sender of the FloorRequest message (identified by the User ID) is 1851 not the participant that would eventually get the floor (i.e., a 1852 third party floor request), the sender SHOULD add a BENEFICIARY-ID 1853 attribute to the message identifying the beneficiary of the floor. 1855 Note that the name space for both the User ID and the Beneficiary 1856 ID is the same. That is, a given participant is identified by a 1857 single 16-bit value that can be used in the User ID in the common 1858 header and in several attributes: BENEFICIARY-ID, BENEFICIARY- 1859 INFORMATION, and REQUESTED-BY-INFORMATION. 1861 The floor participant must insert at least one FLOOR-ID attribute in 1862 the FloorRequest message. If the client inserts more than one 1863 FLOOR-ID attributes, the floor control server will treat all the 1864 floor requests as an atomic package. That is, the floor control 1865 server will either grant or deny all the floors in the FloorRequest 1866 message. 1868 The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute 1869 to state the reason why the floor or floors are being requested. The 1870 Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for 1871 human consumption. 1873 The floor participant may request the server to handle the floor 1874 request with a certain priority using a PRIORITY attribute. 1876 10.1.2 Receiving a Response 1878 A message from the floor control server is considered to be a 1879 response to the FloorRequest message if the message from the floor 1880 control server has the same Conference ID, Transaction ID, and User 1881 ID as the FloorRequest message, as described in Section 8.1. 1883 The successful processing of a FloorRequest message at the floor 1884 control server involves generating one or several FloorRequestStatus 1885 messages. The floor participant obtains a Floor Request ID in the 1886 Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in 1887 the first FloorRequestStatus message from the floor control server. 1888 Subsequent FloorRequestStatus messages from the floor control server 1889 regarding the same floor request will carry the same Floor Request ID 1890 in a FLOOR-REQUEST-INFORMATION attribute as the initial 1891 FloorRequestStatus message. This way, the floor participant can 1892 associate subsequent incoming FloorRequestStatus messages with the 1893 ongoing floor request. 1895 The floor participant obtains information about the status of the 1896 floor request in the FLOOR-REQUEST-INFORMATION attribute of each of 1897 the FloorRequestStatus messages received from the floor control 1898 server. This attribute is a grouped attribute and, as such, it 1899 includes a number of attributes that provide information about the 1900 floor request. 1902 The REQUEST-STATUS attribute. If the Request Status value is 1903 Granted, all the floors that were requested in the FloorRequest 1904 message have been granted. If the Request Status value is Denied, 1905 all the floors that were requested in the FloorRequest message have 1906 been denied. A floor request is considered to be ongoing while it is 1907 in the Pending, Accepted, or Granted states. 1909 The STATUS-INFO attribute, if present, provides extra information 1910 which the floor participant MAY display to the user. 1912 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of 1913 the floor request in third-party floor requests. The REQUESTED-BY- 1914 INFORMATION attribute may be not be present in FloorRequestStatus 1915 messages received by the floor participant that requested the floor 1916 because this floor participant is already identified by the User ID 1917 in the common header. 1919 The PRIORITY attribute, when present, contains the priority that was 1920 requested by the generator of the FloorRequest message. 1922 If the response is an Error message, the floor control server could 1923 not process the FloorRequest message for some reason, which is 1924 described in the Error message. 1926 10.2 Cancelling a Floor Request and Releasing a Floor 1928 A floor participant that wishes to cancel an ongoing floor request 1929 does so by sending a FloorRelease message to the floor control 1930 server. The FloorRelease message is also used by floor participants 1931 that hold a floor and would like to release it. 1933 10.2.1 Sending a FloorRelease Message 1935 The ABNF in Section 5.3.2 describes the attributes that a 1936 FloorRelease message can contain. In addition, the ABNF specifies 1937 normatively which of these attributes are mandatory, and which ones 1938 are optional. 1940 The floor participant sets the Conference ID and the Transaction ID 1941 in the common header following the rules given in Section 8.1. 1942 Additionally, the floor participant follows the rules in Section 9 1943 which relate to the authentication of the message. The floor 1944 participant sets the User ID in the common header to the floor 1945 participant's identifier. This User ID will be used by the floor 1946 control server to authenticate and authorize the request. 1948 Note that the FloorRelease message is used to release a floor or 1949 floors that were granted and to cancel ongoing floor requests 1950 (from the protocol perspective both are ongoing floor requests). 1951 Using the same message in both situations helps resolve the race 1952 condition that occurs when the FloorRelease message and the 1953 FloorGrant message cross each other on the wire. 1955 The floor participant uses the FLOOR-REQUEST-ID that was received in 1956 the response to the FloorRequest message that the FloorRelease 1957 message is cancelling. 1959 Note that if the floor participant requested several floors as an 1960 atomic operation (i.e., in a single FloorRequest message), all the 1961 floors are released as an atomic operation as well (i.e., all are 1962 released at the same time). 1964 10.2.2 Receiving a Response 1966 A message from the floor control server is considered to be a 1967 response to the FloorRelease message if the message from the floor 1968 control server has the same Conference ID, Transaction ID, and User 1969 ID as the FloorRequest message, as described in Section 8.1. 1971 If the response is a FloorRequestStatus message, the Request Status 1972 value in the REQUEST-STATUS attribute (within the FLOOR-REQUEST- 1973 INFORMATION grouped attribute) will be Cancelled or Released. 1975 If the response is an Error message, the floor control server could 1976 not process the FloorRequest message for some reason, which is 1977 described in the Error message. 1979 It is possible that the FloorRelease message crosses on the wire with 1980 a FloorRequestStatus message from the server with a Request Status 1981 different from Cancelled or Released. In any case, such a 1982 FloorRequestStatus message will not be a response to the FloorRelease 1983 message, because its Transaction ID will not match that of the 1984 FloorRelease. 1986 11. Chair Operations 1988 This section specifies how floor chairs can instruct the floor 1989 control server to grant or revoke a floor using the protocol elements 1990 described in earlier sections. 1992 Floor chairs that wish to send instructions to a floor control server 1993 do so by sending a ChairAction message. 1995 11.1 Sending a ChairAction Message 1997 The ABNF in Section 5.3.9 describes the attributes that a ChairAction 1998 message can contain. In addition, the ABNF specifies normatively 1999 which of these attributes are mandatory, and which ones are optional. 2001 The floor chair sets the Conference ID and the Transaction ID in the 2002 common header following the rules given in Section 8.1. 2003 Additionally, the floor chair follows the rules in Section 9 which 2004 relate to the authentication of the message. The floor participant 2005 sets the User ID in the common header to the floor participant's 2006 identifier. This User ID will be used by the floor control server to 2007 authenticate and authorize the request. 2009 The ChairAction message contains instructions that apply to one or 2010 more floors within a particular floor request. The floor or floors 2011 are identified by FLOOR-ID attributes and the floor request is 2012 identified by a FLOOR-REQUEST-ID attribute, which are carried in the 2013 ChairAction message. 2015 For example, if a floor request consists of two floors that depend 2016 on different floor chairs, each floor chair will grant its floor 2017 within the floor request. Once both chairs have granted their 2018 floor, the floor control server will grant the floor request as a 2019 whole. On the other hand, if one of the floor chairs denies its 2020 floor, the floor control server will deny the floor request as a 2021 whole, regardless of the other floor chair's decision. 2023 The floor chair provides the new status for one or more floors within 2024 the floor request using a REQUEST-STATUS attribute. If the new 2025 status of the floor request is Accepted, the floor chair MAY use the 2026 Queue Position field to provide a queue position for the floor 2027 request. If the floor chair does not wish to provide a queue 2028 position, all the bits of the Queue Position field SHOULD be set to 2029 zero. The floor chair SHOULD use the Status Revoked to revoke a 2030 floor that was granted (i.e., Granted status) and the Status Denied 2031 to reject floor requests in any other status (e.g., Pending and 2032 Accepted). 2034 Note that a floor request may involve several floors and that a 2035 ChairAction message may only deal with a subset of these floors 2036 (e.g., if a single floor chair is not authorized to manage all the 2037 floors). In this case, the REQUEST-STATUS that the floor chair 2038 provides in the ChairAction message might not be the actual status 2039 that the floor request gets at the server. The floor control 2040 server will combine the instructions received from the different 2041 floor chairs to come up with the actual status of the floor 2042 request. 2044 The floor chair may use a STATUS-INFO attribute to state the reason 2045 why the floor or floors are being accepted, granted, or revoked. The 2046 Text in the STATUS-INFO attribute is intended for human consumption. 2048 11.2 Receiving a Response 2050 A message from the floor control server is considered to be a 2051 response to the ChairAction message if the message from the server 2052 has the same Conference ID, Transaction ID, and User ID as the 2053 ChairAction message, as described in Section 8.1. 2055 A ChairActionAck message from the floor control server confirms that 2056 the floor control server has accepted the ChairAction message. An 2057 Error message indicates that the floor control server could not 2058 process the ChairAction message for some reason, which is described 2059 in the Error message. 2061 12. General Client Operations 2063 This section specifies operations that can be performed by any 2064 client. That is, they are not specific to floor participants or 2065 floor chairs. They can be performed by both. 2067 12.1 Requesting Information about Floors 2069 A client can obtain information about the status of a floor or floors 2070 in different ways, which include using BFCP and using out-of-band 2071 mechanisms. Clients using BFCP to obtain such information use the 2072 procedures described in this section. 2074 Clients request information about the status of one or several floors 2075 by sending a FloorQuery message to the floor control server. 2077 12.1.1 Sending a FloorQuery Message 2079 The ABNF in Section 5.3.7 describes the attributes that a FloorQuery 2080 message can contain. In addition, the ABNF specifies normatively 2081 which of these attributes are mandatory, and which ones are optional. 2083 The client sets the Conference ID and the Transaction ID in the 2084 common header following the rules given in Section 8.1. 2085 Additionally, the client follows the rules in Section 9 which relate 2086 to the authentication and the protection of the integrity of the 2087 message. The client sets the User ID in the common header to the 2088 client's identifier. This User ID will be used by the floor control 2089 server to authenticate and authorize the request. 2091 The client inserts in the message all the Floor IDs it wants to 2092 receive information about. The floor control server will send 2093 periodic information about all these floors. If the client does not 2094 want to receive information about a particular floor any longer, it 2095 sends a new FloorQuery message removing the FLOOR-ID of this floor. 2096 If the client does not want to receive information about any floor 2097 any longer, it sends a FloorQuery message with no FLOOR-ID attribute. 2099 12.1.2 Receiving a Response 2101 A message from the floor control server is considered to be a 2102 response to the FloorQuery message if the message from the floor 2103 control server has the same Conference ID, Transaction ID, and User 2104 ID as the FloorRequest message, as described in Section 8.1. 2106 On reception of the FloorQuery message, the floor control server will 2107 respond with a FloorStatus message or with an Error message. If the 2108 response is a FloorStatus message, it will contain information about 2109 one of the floors the client requested information about. If the 2110 client did not include any FLOOR-ID attribute in its FloorQuery 2111 message (i.e., the client does not want to receive information about 2112 any floor any longer), the FloorStatus message from the floor control 2113 server will not include any FLOOR-ID attribute either. 2115 FloorStatus messages which carry information about a floor contain a 2116 FLOOR-ID attribute that identifies the floor. After this attribute, 2117 FloorStatus messages contain information about existing (one or more) 2118 floor request that relate to that floor. The information about each 2119 particular floor request is encoded in a FLOOR-REQUEST-INFORMATION 2120 attribute. This grouped attribute carries a Floor Request ID that 2121 identifies the floor request followed by a set of attributes that 2122 provide information about the floor request. 2124 After the first FloorStatus, the floor control server will continue 2125 sending FloorStatus messages periodically informing the client about 2126 changes on the floors the client requested information about. 2128 12.2 Requesting Information about Floor Requests 2130 A client can obtain information about the status of one or several 2131 floor requests in different ways, which include using BFCP and using 2132 out-of-band mechanisms. Clients using BFCP to obtain such 2133 information use the procedures described in this section. 2135 Clients request information about the current status of a floor 2136 requests by sending a FloorRequestQuery message to the floor control 2137 server. 2139 Requesting information about a particular floor request is useful in 2140 a number of situations. For example, on reception of a FloorRequest 2141 message, a floor control server may choose to return 2142 FloorRequestStatus messages only when the floor request changes its 2143 state (e.g., from Accepted to Granted), but not when the floor 2144 request advances in its queue. In this situation, if the user 2145 requests it, the floor participant can use a FloorRequestQuery 2146 message to poll the floor control server for the status of the floor 2147 request. 2149 12.2.1 Sending a FloorRequestQuery Message 2151 The ABNF in Section 5.3.3 describes the attributes that a 2152 FloorRequestQuery message can contain. In addition, the ABNF 2153 specifies normatively which of these attributes are mandatory, and 2154 which ones are optional. 2156 The client sets the Conference ID and the Transaction ID in the 2157 common header following the rules given in Section 8.1. 2158 Additionally, the client follows the rules in Section 9 which relate 2159 to the authentication of the message. The client sets the User ID in 2160 the common header to the client's identifier. This User ID will be 2161 used by the floor control server to authenticate and authorize the 2162 request. 2164 The client must insert a FLOOR-REQUEST-ID attribute that identifies 2165 the floor request at the floor control server. 2167 12.2.2 Receiving a Response 2169 A message from the floor control server is considered to be a 2170 response to the FloorRequestQuery message if the message from the 2171 floor control server has the same Conference ID, Transaction ID,a nd 2172 User ID as the FloorRequestQuery message, as described in 2173 Section 8.1. 2175 If the response is a FloorRequestStatus message, the client obtains 2176 information about the status of the FloorRequest the client requested 2177 information about in a FLOOR-REQUEST-INFORMATION attribute. 2179 If the response is an Error message, the floor control server could 2180 not process the FloorRequestQuery message for some reason, which is 2181 described in the Error message. 2183 12.3 Requesting Information about a User 2185 A client can obtain information about a participant and the floor 2186 requests related to this participant in different ways, which include 2187 using BFCP and using out-of-band mechanisms. Clients using BFCP to 2188 obtain such information use the procedures described in this section. 2190 Clients request information about a participant and the floor 2191 requests related to this participant by sending a UserQuery message 2192 to the floor control server. 2194 This functionality may be useful for floor chairs or floor 2195 participants interested in the display name and the URI of a 2196 particular floor participant. In addition, a floor participant may 2197 find it useful to request information about itself. For example, a 2198 floor participant, after experiencing connectivity problems (e.g., 2199 its TCP connection with the floor control server was down for a while 2200 and eventually was re-established), may need to request information 2201 about all the still existing floor requests associated to itself. 2203 12.3.1 Sending a UserQuery Message 2205 The ABNF in Section 5.3.5 describes the attributes that a UserQuery 2206 message can contain. In addition, the ABNF specifies normatively 2207 which of these attributes are mandatory, and which ones are optional. 2209 The client sets the Conference ID and the Transaction ID in the 2210 common header following the rules given in Section 8.1. 2211 Additionally, the client follows the rules in Section 9 which relate 2212 to the authentication of the message. The client sets the User ID in 2213 the common header to the client's identifier. This User ID will be 2214 used by the floor control server to authenticate and authorize the 2215 request. 2217 If the floor participant the client is requesting information about 2218 is not the client issuing the UserQuery message (which is identified 2219 by the User ID in the common header of the message) the client MUST 2220 insert a BENEFICIARY-ID attribute. 2222 12.3.2 Receiving a Response 2224 A message from the floor control server is considered to be a 2225 response to the UserQuery message if the message from the floor 2226 control server has the same Conference ID, Transaction ID, and User 2227 ID as the UserQuery message, as described in Section 8.1. 2229 If the response is a UserStatus message, the client obtains 2230 information about the floor participant in a BENEFICIARY-INFORMATION 2231 grouped attribute and about the status of the floor requests 2232 associated with the floor participant in FLOOR-REQUEST-INFORMATION 2233 attributes. 2235 If the response is an Error message, the floor control server could 2236 not process the UserQuery message for some reason, which is described 2237 in the Error message. 2239 12.4 Obtaining the Capabilities of a Floor Control Server 2241 A client that wishes to obtain the capabilities of a floor control 2242 server does so by sending a Hello message to the floor control 2243 server. 2245 12.4.1 Sending a Hello Message 2247 The ABNF in Section 5.3.11 describes the attributes that a Hello 2248 message can contain. In addition, the ABNF specifies normatively 2249 which of these attributes are mandatory, and which ones are optional. 2251 The client sets the Conference ID and the Transaction ID in the 2252 common header following the rules given in Section 8.1. 2253 Additionally, the client follows the rules in Section 9 which relate 2254 to the authentication and the protection of the integrity of the 2255 message. The client sets the User ID in the common header to the 2256 client's identifier. This User ID will be used by the floor control 2257 server to authenticate and authorize the request. 2259 12.4.2 Receiving Responses 2261 A message from the floor control server is considered a response to 2262 the Hello message by the client if the message from the floor control 2263 server has the same Conference ID, Transaction ID, and User ID as the 2264 Hello message, as described in Section 8.1. 2266 If the response is a HelloAck message, the floor control server could 2267 process successfully the Hello message. The SUPPORTED-ATTRIBUTES 2268 attribute indicates which attributes are supported by the server. 2270 If the response is an Error message, the floor control server could 2271 not process the Hello message for some reason, which is described in 2272 the Error message. 2274 13. Floor Control Server Operations 2276 This section specifies how floor control servers can perform 2277 different operations, such as granting a floor, using the protocol 2278 elements described in earlier sections. 2280 On reception of a message from a client, the floor control server 2281 MUST check whether or not the value of the Conference ID matched an 2282 existing conference. If it does not, the floor control server SHOULD 2283 send an Error message, as described in Section 13.8, with Error code 2284 1 (Conference does not Exist). 2286 On reception of a message from a client, the floor control server 2287 follows the rules in Section 9, which relate to the authentication of 2288 the message. 2290 On reception of a message from a client, the floor control server 2291 MUST check whether or not it understands all the mandatory ( 'M' bit 2292 set) attributes in the message. If the floor control server does not 2293 understand all of them, the floor control server SHOULD send an Error 2294 message, as described in Section 13.8, with Error code 2 2295 (Authentication Failed). The Error message SHOULD list the 2296 attributes that were not understood. 2298 13.1 Reception of a FloorRequest Message 2300 On reception of a FloorRequest message, the floor control server 2301 follows the rules in Section 9 which relate to client authentication 2302 and authorization. If while processing the FloorRequest message, the 2303 floor control server encounters an error, it SHOULD generate an Error 2304 response following the procedures described in Section 13.8 2306 BFCP allows floor participants to have several ongoing floor 2307 requests for the same floor (e.g., the same floor participant can 2308 occupy more than one position in a queue at the same time). A 2309 floor control server that only supports a certain number of 2310 ongoing floor requests per floor participant (e.g., one) can use 2311 Error Code 11 (You have Already Reached the Maximum Number of 2312 Ongoing Floor Requests for this Floor) to inform the floor 2313 participant. 2315 13.1.1 Generating the First FloorRequestStatus Message 2317 The successful processing of a FloorRequest message by a floor 2318 control server involves generating one or several FloorRequestStatus 2319 messages, the first of which SHOULD be generated as soon as possible. 2320 If the floor control server cannot accept, grant, or deny the floor 2321 request right away (e.g., a decision from a chair is needed), it 2322 SHOULD use a Request Status value of Pending in the REQUEST-STATUS 2323 attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of 2324 the first FloorRequestStatus message it generates. 2326 The policy a floor control server follows to grant or deny floors 2327 is outside the scope of this document. A given floor control 2328 server may perform these decisions automatically while another may 2329 contact a human acting as a chair everytime a decision needs to be 2330 made. 2332 The floor control server MUST copy the Conference ID, the Transaction 2333 ID, and the User ID from the FloorRequest into the 2334 FloorRequestStatus, as described in Section 8.2. Additionally, the 2335 floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2336 attribute to the FloorRequestStatus. The attributes contained in 2337 this grouped attribute carry information about the floor request. 2339 The floor control server MUST assign an identitifier that is unique 2340 within the conference to this floor request, and MUST insert it in 2341 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2342 attribute. This identifier will be used by the floor participant (or 2343 by a chair or chairs) to refer to this specific floor request in the 2344 future. 2346 The floor control server MUST copy the FLOOR-ID attributes from the 2347 FloorRequest into the FLOOR-REQUEST-INFORMATION attribute. These 2348 FLOOR-ID attributes identify the floors being requested (i.e., the 2349 floors associated with this particular floor request). 2351 The floor control server SHOULD copy (if present) the contents of the 2352 BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- 2353 INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped 2354 attribute. Additionally, the floor control server MAY provide the 2355 display name and the URI of the beneficiary in this BENEFICIARY- 2356 INFORMATION attribute. 2358 The floor control server MAY provide information about the requester 2359 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2360 FLOOR-REQUEST-INFORMATION grouped attribute. 2362 The floor control server MAY copy (if present) the PRIORITY attribute 2363 from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped 2364 attribute. Note that this attribute carries the priority requested 2365 by the participant. The priority the floor control server assigns to 2366 the floor request depends on the priority requested by the 2367 participant and the rights the participant has according to the 2368 policy of the conference. For example, a participant that is only 2369 allowed to use the Normal priority may request Highest priority for a 2370 floor request. In that case, the floor control server would ignore 2371 the priority requested by the participant. 2373 The floor control server MAY copy (if present) the PARTICIPANT- 2374 PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- 2375 INFO grouped attribute. 2377 13.1.2 Generation of Subsequent FloorRequestStatus Messages 2379 A floor request is considered to be ongoing as long as it is not in 2380 the Cancelled, Released, or Revoked states. If the REQUEST-STATUS 2381 attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of 2382 the first FloorRequestStatus message generated by the floor control 2383 server did not indicate any of these states, the floor control server 2384 will need to send subsequent FloorRequestStatus messages. 2386 When the status of the floor request changes, the floor control 2387 server SHOULD send new FloorRequestStatus messages with the 2388 appropriate Request Status. The floor control server MUST add a 2389 FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to 2390 the one sent in the first FloorRequestStatus message to any new 2391 FloorRequestStatus related to the same floor request. (The Floor 2392 Request ID identifies the floor request the FloorRequestStatus 2393 applies to.) 2395 The floor control server MUST set the Transaction ID of subsequent 2396 FloorRequestStatus messages to 0. 2398 The rate at which the floor control server sends 2399 FloorRequestStatus messages is a matter of local policy. A floor 2400 control server may choose to send a new FloorRequestStatus message 2401 every time the floor request moves in the floor request queue 2402 while another may choose to only send a new FloorRequestStatus 2403 message when the floor request is Granted or Denied. 2405 The floor control server may add a STATUS-INFO attribute to any of 2406 the FloorRequestStatus messages it generates to provide extra 2407 information about its decisions regarding the floor request (e.g., 2408 why it was denied). 2410 Floor participants and floor chairs may request to be informed 2411 about the status of a floor following the procedures in 2412 Section 12.1. If the processing of a floor request changes the 2413 status of a floor (e.g., the floor request is granted and 2414 consequently the floor has a new holder), the floor control server 2415 needs to follow the procedures in Section 13.5 to inform the 2416 clients that have requested that information 2418 The common header and the rest of the attributes are the same as in 2419 the first FloorRequestStatus message. 2421 The floor control server can discard the state information about a 2422 particular floor request when this reaches a status of Cancelled, 2423 Released, or Revoked. 2425 13.2 Reception of a FloorRequestQuery Message 2427 On reception of a FloorRequestQuery message, the floor control server 2428 follows the rules in Section 9 which relate to client authentication 2429 and authorization. If while processing the FloorRequestQuery 2430 message, the floor control server encounters an error, it SHOULD 2431 generate an Error response following the procedures described in 2432 Section 13.8 2434 The successful processing of a FloorRequestQuery message by a floor 2435 control server involves generating a FloorRequestStatus message, 2436 which SHOULD be generated as soon as possible. 2438 The floor control server MUST copy the Conference ID, the Transaction 2439 ID, and the User ID from the FloorRequestQuery message into the 2440 FloorRequestStatus message, as described in Section 8.2. 2441 Additionally, the floor control server MUST add a FLOOR-REQUEST- 2442 INFORMATION grouped attribute to the FloorRequestStatus. The 2443 attributes contained in this grouped attribute carry information 2444 about the floor request. 2446 The floor control server MUST copy the contents of the 2447 FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into 2448 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2449 attribute. 2451 The floor control server MUST add FLOOR-ID attributes to the FLOOR- 2452 REQUEST-INFORMATION grouped attribute identifying the floors being 2453 requested (i.e., the floors associated with the floor request 2454 identified by the FLOOR-REQUEST-ID attribute). 2456 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2457 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2458 beneficiary of the floor request. Additionally, the floor control 2459 server MAY provide the display name and the URI of the beneficiary in 2460 this BENEFICIARY-INFORMATION attribute. 2462 The floor control server MAY provide information about the requester 2463 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2464 FLOOR-REQUEST-INFORMATION grouped attribute. 2466 The floor control server MAY provide the reason why the floor 2467 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2469 The floor control server MAY also add to the FLOOR-REQUEST- 2470 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2471 value requested for the floor request and a STATUS-INFO attribute 2472 with extra information about the floor request. 2474 The floor control server adds a REQUEST-STATUS attribute to the 2475 FLOOR-REQUEST-INFORMATION grouped attribute with the current status 2476 of the floor request. 2478 13.3 Reception of a UserQuery Message 2480 On reception of a UserQuery message, the floor control server follows 2481 the rules in Section 9 which relate to client authentication and 2482 authorization. If while processing the UserQuery message, the floor 2483 control server encounters an error, it SHOULD generate an Error 2484 response following the procedures described in Section 13.8 2485 The successful processing of a UserQuery message by a floor control 2486 server involves generating a UserStatus message, which SHOULD be 2487 generated as soon as possible. 2489 The floor control server MUST copy the Conference ID, the Transaction 2490 ID, and the User ID from the UserQuery message into the USerStatus 2491 message, as described in Section 8.2. 2493 The sender of the UserQuery message is requesting information about 2494 all the floor requests associated to a given participant (i.e., the 2495 floor requests where the participant is either the beneficiary or the 2496 requester). This participant is identified by a BENEFICIARY-ID 2497 attribute or, in the absence of a BENEFICIARY-ID attribute, by a the 2498 User ID in the common header of the UserQuery message. 2500 The floor control server MUST copy, if present, the contents of the 2501 BENEFICIARY-ID attribute from the UserQuery message into a 2502 BENEFICIARY-INFORMATION attribute in the UserStatus message. 2503 Additionally, the floor control server MAY provide the display name 2504 and the URI of the participant the UserStatus message provides 2505 information on in this BENEFICIARY-INFORMATION attribute. 2507 The floor control server SHOULD add to the UserStatus message a 2508 FLOOR-REQUEST-INFORMATION grouped attribute for each floor request 2509 related to the participant the message provides information on (i.e., 2510 the floor requests where the participant is either the beneficiary or 2511 the requester). For each FLOOR-REQUEST-INFORMATION attribute, the 2512 floor control server follows the following steps. 2514 The floor control server MUST identity the floor request the FLOOR- 2515 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2516 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2518 The floor control server MUST add FLOOR-ID attributes to the FLOOR- 2519 REQUEST-INFORMATION grouped attribute identifying the floors being 2520 requested (i.e., the floors associated with the floor request 2521 identified by the FLOOR-REQUEST-ID attribute). 2523 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2524 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2525 beneficiary of the floor request. Additionally, the floor control 2526 server MAY provide the display name and the URI of the beneficiary in 2527 this BENEFICIARY-INFORMATION attribute. 2529 The floor control server MAY provide information about the requester 2530 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2531 FLOOR-REQUEST-INFORMATION grouped attribute. 2533 The floor control server MAY provide the reason why the floor 2534 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2536 The floor control server MAY also add to the FLOOR-REQUEST- 2537 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2538 value requested for the floor request and a STATUS-INFO attribute 2539 with extra information about the floor request. 2541 The floor control server MUST add a REQUEST-STATUS attribute to the 2542 FLOOR-REQUEST-INFORMATION grouped attribute with the current status 2543 of the floor request. 2545 13.4 Reception of a FloorRelease Message 2547 On reception of a FloorRelease message, the floor control server 2548 follows the rules in Section 9 which relate to client authentication 2549 and authorization. If while processing the FloorRelease message, the 2550 floor control server encounters an error, it SHOULD generate an Error 2551 response following the procedures described in Section 13.8 2553 The successful processing of a FloorRelease message by a floor 2554 control server involves generating a FloorRequestStatus message, 2555 which SHOULD be generated as soon as possible. 2557 The floor control server MUST copy the Conference ID, the Transaction 2558 ID, and the User ID from the FloorRelease message into the 2559 FloorRequestStatus message, as described in Section 8.2. 2561 The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2562 attribute to the FloorRequestStatus. The attributes contained in 2563 this grouped attribute carry information about the floor request. 2565 The FloorRelease message identifies the floor request it applies to 2566 using a FLOOR-REQUEST-ID. The floor control server MUST copy the 2567 contents of the FLOOR-REQUEST-ID attribute from the FloorRelease 2568 message into the Floor Request ID field of the FLOOR-REQUEST- 2569 INFORMATION attribute. 2571 The floor control server MUST add FLOOR-ID attributes to the FLOOR- 2572 REQUEST-INFORMATION grouped attribute identifying the floors being 2573 requested (i.e., the floors associated with the floor request 2574 identified by the FLOOR-REQUEST-ID attribute). 2576 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2577 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2578 beneficiary of the floor request. Additionally, the floor control 2579 server MAY provide the display name and the URI of the beneficiary in 2580 this BENEFICIARY-INFORMATION attribute. 2582 The floor control server MAY provide information about the requester 2583 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2584 FLOOR-REQUEST-INFORMATION grouped attribute. 2586 The floor control server MAY provide the reason why the floor 2587 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2589 The floor control server MAY also add to the FLOOR-REQUEST- 2590 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2591 value requested for the floor request and a STATUS-INFO attribute 2592 with extra information about the floor request. 2594 The floor control server MUST add a REQUEST-STATUS attribute to the 2595 FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status 2596 value SHOULD be Released, if the floor (or floors) had been 2597 previously granted, or Cancelled, if the floor (or floors) had not 2598 been previously granted. 2600 13.5 Reception of a FloorQuery Message 2602 On reception of a FloorQuery message, the floor control server 2603 follows the rules in Section 9 which relate to client authentication. 2604 If while processing the FloorRelease message, the floor control 2605 server encounters an error, it SHOULD generate an Error response 2606 following the procedures described in Section 13.8 2608 A floor control server receiving a FloorQuery message from a client 2609 SHOULD keep this client informed about the status of the floors 2610 identified by FLOOR-ID attributes in the FloorQuery message. Floor 2611 Control Servers keep clients informed by using FloorStatus messages. 2613 An individual FloorStatus message carries information about a single 2614 floor. So, when a FloorQuery message requests information about more 2615 than one floor, the floor control server needs to send separate 2616 FloorStatus messages for different floors. 2618 The information FloorQuery messages carry may depend on the user 2619 requesting the information. For example, a chair may be able to 2620 receive information about pending requests while a regular user may 2621 not be authorized to do so. 2623 13.5.1 Generation of the First FloorStatus Message 2625 The successful processing of a FloorQuery message by a floor control 2626 server involves generating one or several FloorStatus messages, the 2627 first of which SHOULD be generated as soon as possible. 2629 The floor control server MUST copy the Conference ID, the Transaction 2630 ID, and the User ID from the FloorQuery message into the FloorStatus 2631 message, as described in Section 8.2. 2633 If the FloorQuery message did not contain any FLOOR-ID attribute, the 2634 floor control server sends the FloorStatus message without adding any 2635 additional attribute and does not send any subsequent FloorStatus 2636 message to the floor participant. 2638 If the FloorQuery message contained one or more FLOOR-ID attributes, 2639 the floor control server chooses one among them and adds this 2640 FLOOR-ID attribute to the FloorStatus message. The floor control 2641 server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for 2642 each floor request associated to the floor. Each FLOOR-REQUEST- 2643 INFORMATION grouped attribute contains a number of attributes which 2644 provide information about the floor request. For each FLOOR-REQUEST- 2645 INFORMATION attribute, the floor control server follows the following 2646 steps. 2648 The floor control server MUST identity the floor request the FLOOR- 2649 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2650 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2652 The floor control server MUST add FLOOR-ID attributes to the FLOOR- 2653 REQUEST-INFORMATION grouped attribute identifying the floors being 2654 requested (i.e., the floors associated with the floor request 2655 identified by the FLOOR-REQUEST-ID attribute). 2657 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2658 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2659 beneficiary of the floor request. Additionally, the floor control 2660 server MAY provide the display name and the URI of the beneficiary in 2661 this BENEFICIARY-INFORMATION attribute. 2663 The floor control server MAY provide information about the requester 2664 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2665 FLOOR-REQUEST-INFORMATION grouped attribute. 2667 The floor control server MAY provide the reason why the floor 2668 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2670 The floor control server MAY also add to the FLOOR-REQUEST- 2671 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2672 value requested for the floor request and a STATUS-INFO attribute 2673 with extra information about the floor request. 2675 The floor control server MUST add a REQUEST-STATUS attribute to the 2676 FLOOR-REQUEST-INFORMATION grouped attribute with the current status 2677 of the floor request. 2679 13.5.2 Generation of Subsequent FloorStatus Messages 2681 If the FloorQuery message carried more than one FLOOR-ID attribute, 2682 the floor control server SHOULD generate a FloorStatus message for 2683 each of them (except for the FLOOR-ID attribute chosen for the first 2684 FloorStatus message) as soon as possible. These FloorStatus messages 2685 are generated following the same rules as for the first FloorStatus 2686 message (see Section 13.5.1, but their Transaction ID is 0. 2688 After generating these messages, the floor control server sends 2689 FloorStatus messages periodically keeping the client informed about 2690 all the floors the client requested information about. The 2691 Transaction ID of these messages MUSt be 0. 2693 The rate at which the floor control server sends FloorStatus 2694 messages is a matter of local policy. A floor control server may 2695 choose to send a new FloorStatus message every time a new floor 2696 request arrives while another may choose to only send a new 2697 FloorStatus message when a new floor request is Granted. 2699 13.6 Reception of a ChairAction Message 2701 On reception of a ChairAction message, the floor control server 2702 follows the rules in Section 9 which relate to client authentication 2703 and authorization. If while processing the ChairAction message, the 2704 floor control server encounters an error, it SHOULD generate an Error 2705 response following the procedures described in Section 13.8 2707 The successful processing of a ChairAction message by a floor control 2708 server involves generating a ChairActionAck message, which SHOULD be 2709 generated as soon as possible. 2711 The floor control server MUST copy the Conference ID, the Transaction 2712 ID, and the User ID from the ChairAction message into the 2713 ChairActionAck message, as described in Section 8.2. 2715 The floor control server needs to take into consideration the 2716 operation requested in the ChairAction message (e.g., granting a 2717 floor), but does not necessarily need to perform it as requested by 2718 the floor chair. The operation that the floor control server 2719 performs depends on the ChairAction message and on the internal state 2720 of the floor control server. 2722 For example, a floor chair may send a ChairAction message granting a 2723 floor which was requested as part of an atomic floor request 2724 operation that involved several floors. Even if the chair 2725 responsible for one of the floors instructs the floor control server 2726 to grant the floor, the floor control server will not grant it until 2727 the chairs responsible for the other floors agree to grant them as 2728 well. 2730 So, the floor control server is ultimately responsible to keep a 2731 coherent floor state using instructions from floor chairs as input to 2732 this state. 2734 If the new Status in the ChairAction message is Accepted and all the 2735 bits of the Queue Position field are zero, the floor chair is 2736 requesting the floor control server to assign a queue position (e.g., 2737 the last in the queue) to the floor request based on the local policy 2738 of the floor control server. (Of course, such a request only applies 2739 in case the floor control server implements a queue.) 2741 13.7 Reception of a Hello Message 2743 On reception of a Hello message, the floor control server follows the 2744 rules in Section 9 which relate to client authentication. If while 2745 processing the Hello message, the floor control server encounters an 2746 error, it SHOULD generate an Error response following the procedures 2747 described in Section 13.8 2749 The successful processing of a Hello message by a floor control 2750 server involves generating a HelloAck message, which SHOULD be 2751 generated as soon as possible. The floor control server MUST copy 2752 the Conference ID, the Transaction ID, and the User ID from the Hello 2753 into the HelloAck, as described in Section 8.2. 2755 The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to 2756 the HelloAck message listing all the primitives (i.e., BFCP messages) 2757 supported by the floor control server. 2759 The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to 2760 the HelloAck message listing all the attributes supported by the 2761 floor control server. 2763 13.8 Error Message Generation 2765 Error messages are always sent in response to a previous message from 2766 the client as part of a client-initiated transaction. The ABNF in 2767 Section 5.3.13 describes the attributes that an Error message can 2768 contain. In addition, the ABNF specifies normatively which of these 2769 attributes are mandatory, and which ones are optional. 2771 The floor control server MUST copy the Conference ID, the Transaction 2772 ID, and the User ID from the message from the client into the Error 2773 message, as described in Section 8.2. 2775 The floor control server MUST add an ERROR-CODE attribute to the 2776 Error message. The ERROR-CODE attribute contains an Error Code from 2777 Table 6. Additionally, the floor control server may add a ERROR-INFO 2778 attribute with extra information about the error. 2780 14. Security Considerations 2782 BFCP can use TLS or message signatures to provide client 2783 authentication. Floor control server authentication is based on TLS, 2784 which also provides replay and integrity protection, and 2785 confidentiality. It is RECOMMENDED that TLS with non-null encryption 2786 is always used and that the first message from an unauthenticated 2787 client over a given TLS connection is signed using the DIGEST 2788 attribute. Clients and floor control servers MAY use other security 2789 mechanisms as long as they provide similar security properties. 2791 The remainder of this Section analyzes some of the threats against 2792 BFCP and how they are addressed. 2794 An attacker may attempt to impersonate a client (a floor participant 2795 or a floor chair) in order to generate forged floor requests or to 2796 grant or deny existing floor requests. Client impersonation is 2797 avoided by having clients sign their messages. A nonce is included 2798 in the signature to ensure the freshness of the message. If the 2799 client is using a TLS connection to communicate with the floor 2800 control server, it is enough that the client signs its first message 2801 over the TLS connection. The floor control server assumes that 2802 attackers cannot hickjack the TLS connection and, therefore, that 2803 subsequent messages over the TLS connection come from the client that 2804 was initially authenticated. If TLS-based client authentication is 2805 used, there is not need for the client to sign BFCP messages over the 2806 connection. 2808 An attacker may attempt to impersonate a floor control server. A 2809 successful attacker would be able to make clients think that they 2810 hold a particular floor so that they would try to access a resource 2811 (e.g., sending media) without having legitimate rights to access it. 2812 Floor control server impersonation is avoided by having floor control 2813 servers present their server certificates or prove that they have a 2814 shared secret with the client at TLS connection establishment time. 2816 Attackers may attempt to modify messages exchanged by a client and a 2817 floor control server. The integrity protection provided by TLS 2818 connections prevents this attack. 2820 An attacker may attempt to fetch a valid message sent by a client to 2821 a floor control server and replay it at a later point. If the 2822 message was signed, the attacker may attempt to establish a new TLS 2823 connection with the floor control server and replay the message over 2824 the new connection. Using TLS confidentiality prevents this attack 2825 because the attacker cannot access the contents of the message in the 2826 first place. Additionally, TLS provides replay protection for a 2827 given connection. Therefore, it is strongly RECOMMENDED that TLS is 2828 used with a non-null encryption algorithm. 2830 Attackers may attempt to pick messages from the network to get access 2831 to confidential information between the floor control server and a 2832 client (e.g., why a floor request was denied). TLS confidentiality 2833 prevents this attack. 2835 15. IANA Considerations 2837 This document instructs the IANA to create a new registry for BFCP 2838 parameters called "Binary Floor Control Protocol (BFCP) Parameters". 2839 This new registry has a number of subregistries, which are described 2840 in the following Sections 2842 15.1 Attribute Subregistry 2844 This Section establishes the Attribute subregistry under the BFCP 2845 Parameters registry. As per the terminology in RFC 2434 [5], the 2846 registration policy for BFCP attributes shall be "Specification 2847 Required". For the purposes of this subregistry, the BFCP attributes 2848 for which IANA registration is requested MUST be defined by a 2849 standards-track RFC. Such RFC MUST specify the attribute's type, 2850 name, format, and semantics. 2852 For each BFCP attribute, the IANA registers its type, its name, and 2853 the reference to the RFC where the attribute is defined. The 2854 following table contains the initial values of this subregistry. 2856 +------+---------------------------+------------+ 2857 | Type | Attribute | Reference | 2858 +------+---------------------------+------------+ 2859 | 1 | BENEFICIARY-ID | [RFC XXXX] | 2860 | 2 | FLOOR-ID | [RFC XXXX] | 2861 | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | 2862 | 4 | NONCE | [RFC XXXX] | 2863 | 5 | PRIORITY | [RFC XXXX] | 2864 | 6 | REQUEST-STATUS | [RFC XXXX] | 2865 | 7 | DIGEST | [RFC XXXX] | 2866 | 8 | ERROR-CODE | [RFC XXXX] | 2867 | 9 | ERROR-INFO | [RFC XXXX] | 2868 | 10 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | 2869 | 11 | STATUS-INFO | [RFC XXXX] | 2870 | 12 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | 2871 | 13 | SUPPORTED-PRIMITIVES | [RFC XXXX] | 2872 | 14 | USER-DISPLAY-NAME | [RFC XXXX] | 2873 | 15 | USER-URI | [RFC XXXX] | 2874 | 16 | BENEFICIARY-INFORMATION | [RFC XXXX] | 2875 | 17 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | 2876 | 18 | REQUESTED-BY-INFORMATION | [RFC XXXX] | 2877 +------+---------------------------+------------+ 2879 Table 7: Initial values of the BFCP Attribute subregistry 2881 15.2 Primitive Subregistry 2883 This Section establishes the Primitive subregistry under the BFCP 2884 Parameters registry. As per the terminology in RFC 2434 [5], the 2885 registration policy for BFCP primitives shall be "Specification 2886 Required". For the purposes of this subregistry, the BFCP primitives 2887 for which IANA registration is requested MUST be defined by a 2888 standards-track RFC. Such RFC MUST specify the primitive's value, 2889 name, format, and semantics. 2891 For each BFCP primitive, the IANA registers its value, its name, and 2892 the reference to the RFC where the primitive is defined. The 2893 following table contains the initial values of this subregistry. 2895 +-------+--------------------+------------+ 2896 | Value | Primitive | Reference | 2897 +-------+--------------------+------------+ 2898 | 1 | FloorRequest | [RFC XXXX] | 2899 | 2 | FloorRelease | [RFC XXXX] | 2900 | 3 | FloorRequestQuery | [RFC XXXX] | 2901 | 4 | FloorRequestStatus | [RFC XXXX] | 2902 | 5 | UserQuery | [RFC XXXX] | 2903 | 6 | UserStatus | [RFC XXXX] | 2904 | 7 | FloorQuery | [RFC XXXX] | 2905 | 8 | FloorStatus | [RFC XXXX] | 2906 | 9 | ChairAction | [RFC XXXX] | 2907 | 10 | ChairActionAck | [RFC XXXX] | 2908 | 11 | Hello | [RFC XXXX] | 2909 | 12 | HelloAck | [RFC XXXX] | 2910 | 13 | Error | [RFC XXXX] | 2911 +-------+--------------------+------------+ 2913 Table 8: Initial values of the BFCP primitive subregistry 2915 15.3 Request Status Subregistry 2917 This Section establishes the Request Status subregistry under the 2918 BFCP Parameters registry. As per the terminology in RFC 2434 [5], 2919 the registration policy for BFCP request status shall be 2920 "Specification Required". For the purposes of this subregistry, the 2921 BFCP request status for which IANA registration is requested MUST be 2922 defined by a standards-track RFC. Such RFC MUST specify the value 2923 and the semantics of the request status. 2925 For each BFCP request status, the IANA registers its value, its 2926 meaning, and the reference to the RFC where the request status is 2927 defined. The following table contains the initial values of this 2928 subregistry. 2930 +-------+-----------+------------+ 2931 | Value | Status | Reference | 2932 +-------+-----------+------------+ 2933 | 1 | Pending | [RFC XXXX] | 2934 | 2 | Accepted | [RFC XXXX] | 2935 | 3 | Granted | [RFC XXXX] | 2936 | 4 | Denied | [RFC XXXX] | 2937 | 5 | Cancelled | [RFC XXXX] | 2938 | 6 | Released | [RFC XXXX] | 2939 | 7 | Revoked | [RFC XXXX] | 2940 +-------+-----------+------------+ 2942 Table 9: Initial values of the Request Status subregistry 2944 15.4 Error Code Subregistry 2946 This Section establishes the Error Code subregistry under the BFCP 2947 Parameters registry. As per the terminology in RFC 2434 [5], the 2948 registration policy for BFCP error codes shall be "Specification 2949 Required". For the purposes of this subregistry, the BFCP error 2950 codes for which IANA registration is requested MUST be defined by a 2951 standards-track RFC. Such RFC MUST specify the value and the 2952 semantics of the error code, and any Error Specific Details that 2953 apply to it. 2955 For each BFCP primitive, the IANA registers its value, its meaning, 2956 and the reference to the RFC where the primitive is defined. The 2957 following table contains the initial values of this subregistry. 2959 +----------------------+----------------------+---------------------+ 2960 | Value | Meaning | Reference | 2961 +----------------------+----------------------+---------------------+ 2962 | 1 | Conference does not | [RFC XXXX] | 2963 | | Exist | | 2964 | 2 | User does not Exist | [RFC XXXX] | 2965 | 3 | DIGEST Attribute | [RFC XXXX] | 2966 | | Required | | 2967 | 4 | Invalid Nonce | [RFC XXXX] | 2968 | 5 | Authentication | [RFC XXXX] | 2969 | | Failed | | 2970 | 6 | Unknown Primitive | [RFC XXXX] | 2971 | 7 | Unknown Mandatory | [RFC XXXX] | 2972 | | Attribute | | 2973 | 8 | Unauthorized | [RFC XXXX] | 2974 | | Operation | | 2975 | 9 | Invalid Floor ID | [RFC XXXX] | 2976 | 10 | Floor Request ID | [RFC XXXX] | 2977 | | Does Not Exist | | 2978 | 11 | You have Already | [RFC XXXX] | 2979 | | Reached the Maximum | | 2980 | | Number of Ongoing | | 2981 | | Floor Requests for | | 2982 | | this Floor | | 2983 +----------------------+----------------------+---------------------+ 2985 Table 10: Initial Values of the Error Code subregistry 2987 15.5 Digest Algorithm Subregistry 2989 This Section establishes the Digest Algorithm subregistry under the 2990 BFCP Parameters registry. As per the terminology in RFC 2434 [5], 2991 the registration policy for BFCP digest algorithms shall be 2992 "Specification Required". For the purposes of this subregistry, the 2993 BFCP error codes for which IANA registration is requested MUST be 2994 defined by a standards-track RFC. Such RFC MUST specify the value 2995 and the semantics of the error code, and any Error Specific Details 2996 that apply to it. 2998 For each BFCP digest algorithm, the IANA registers its numeric 2999 identifier, its name, and the reference to the RFC where the 3000 algorithm is defined. The following table contains the initial 3001 values of this subregistry. 3003 +------------+-----------+-----------+ 3004 | Identifier | Algorithm | Reference | 3005 +------------+-----------+-----------+ 3006 | 0 | HMAC-SHA1 | RFC 2104 | 3007 +------------+-----------+-----------+ 3009 Table 11: Initial values of the Digest Algorithms subregistry 3011 16. Acknowledgments 3013 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 3014 ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, 3015 Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben 3016 Campbell, Dave Morgan, and Oscar Novo provided useful comments. 3018 17. References 3020 17.1 Normative References 3022 [1] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 3023 for Message Authentication", RFC 2104, February 1997. 3025 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3026 Levels", BCP 14, RFC 2119, March 1997. 3028 [3] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3029 Specifications: ABNF", RFC 2234, November 1997. 3031 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 3032 RFC 2246, January 1999. 3034 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 3035 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 3037 [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 3038 Transport Layer Security (TLS)", RFC 3268, June 2002. 3040 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 3041 STD 63, RFC 3629, November 2003. 3043 17.2 Informational References 3045 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 3046 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 3047 Session Initiation Protocol", RFC 3261, June 2002. 3049 [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 3050 Session Description Protocol (SDP)", RFC 3264, June 2002. 3052 [10] Schulzrinne, H., "Requirements for Floor Control Protocol", 3053 draft-ietf-xcon-floor-control-req-03 (work in progress), 3054 January 2005. 3056 [11] Rosenberg, J., "A Framework for Conferencing with the Session 3057 Initiation Protocol", 3058 draft-ietf-sipping-conferencing-framework-05 (work in 3059 progress), May 2005. 3061 [12] Barnes, M. and C. Boulton, "A Framework and Data Model for 3062 Centralized Conferencing", draft-barnes-xcon-framework-02 (work 3063 in progress), February 2005. 3065 [13] Camarillo, G., "Session Description Protocol (SDP) Format for 3066 Binary Floor Control Protocol (BFCP) Streams", 3067 draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005. 3069 Authors' Addresses 3071 Gonzalo Camarillo 3072 Ericsson 3073 Hirsalantie 11 3074 Jorvas 02420 3075 Finland 3077 Email: Gonzalo.Camarillo@ericsson.com 3078 Joerg Ott 3079 Helsinki University of Technology 3080 Department for Electrical and Communications Engineering 3081 Networking Laboratory 3082 Helsinki 3083 Finland 3085 Email: jo@netlab.hut.fi 3087 Keith Drage 3088 Lucent Technologies 3089 Windmill Hill Business Park 3090 Swindon 3091 Wiltshire SN5 6PP 3092 UK 3094 Email: drage@lucent.com 3096 Intellectual Property Statement 3098 The IETF takes no position regarding the validity or scope of any 3099 Intellectual Property Rights or other rights that might be claimed to 3100 pertain to the implementation or use of the technology described in 3101 this document or the extent to which any license under such rights 3102 might or might not be available; nor does it represent that it has 3103 made any independent effort to identify any such rights. Information 3104 on the procedures with respect to rights in RFC documents can be 3105 found in BCP 78 and BCP 79. 3107 Copies of IPR disclosures made to the IETF Secretariat and any 3108 assurances of licenses to be made available, or the result of an 3109 attempt made to obtain a general license or permission for the use of 3110 such proprietary rights by implementers or users of this 3111 specification can be obtained from the IETF on-line IPR repository at 3112 http://www.ietf.org/ipr. 3114 The IETF invites any interested party to bring to its attention any 3115 copyrights, patents or patent applications, or other proprietary 3116 rights that may cover technology that may be required to implement 3117 this standard. Please address the information to the IETF at 3118 ietf-ipr@ietf.org. 3120 Disclaimer of Validity 3122 This document and the information contained herein are provided on an 3123 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3124 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3125 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3126 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3127 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3128 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3130 Copyright Statement 3132 Copyright (C) The Internet Society (2005). This document is subject 3133 to the rights, licenses and restrictions contained in BCP 78, and 3134 except as set forth therein, the authors retain all their rights. 3136 Acknowledgment 3138 Funding for the RFC Editor function is currently provided by the 3139 Internet Society.