idnits 2.17.1 draft-ietf-xcon-bfcp-03.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2501. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (December 31, 2004) is 7049 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 2380 ** 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) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '8') (Obsoleted by RFC 4566) == Outdated reference: A later version (-03) exists of draft-ietf-xcon-floor-control-req-02 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-03 == Outdated reference: A later version (-02) exists of draft-barnes-xcon-framework-00 Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 9 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: July 1, 2005 J. Ott 5 Universitaet Bremen 6 K. Drage 7 Lucent Technologies 8 December 31, 2004 10 The Binary Floor Control Protocol (BFCP) 11 draft-ietf-xcon-bfcp-03.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 1, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 Floor control is a means to manage joint or exclusive access to 47 shared resources in a (multiparty) conferencing environment. 48 Thereby, floor control complements other functions -- such as 49 conference and media session setup, conference policy manipulation, 50 and media control -- that are realized by other protocols. 52 This document specifies the Binary Floor Control Protocol (BFCP). 53 BFCP is used between floor participants and floor control servers, 54 and between floor chairs (i.e., moderators) and floor control 55 servers. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 8 63 3.2 Obtaining Information to Contact a Floor Control Server . 8 64 3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 8 65 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 8 66 3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 9 67 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 9 68 4.1 Floor Participant to Floor Control Server Interface . . . 10 69 4.2 Floor Chair to Floor Control Server Interface . . . . . . 13 70 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 14 71 5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 14 72 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 15 73 5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 17 74 5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 17 75 5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17 76 5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 18 77 5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18 78 5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 18 79 5.2.7 DIGEST . . . . . . . . . . . . . . . . . . . . . . . . 19 80 5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 20 81 5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 21 82 5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 23 83 5.2.11 USER-URI . . . . . . . . . . . . . . . . . . . . . . 23 84 5.2.12 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 23 85 5.2.13 NONCE . . . . . . . . . . . . . . . . . . . . . . . 23 86 5.2.14 SUPPORTED-TLVS . . . . . . . . . . . . . . . . . . . 24 87 5.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 24 88 5.3.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . 24 89 5.3.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . 25 90 5.3.3 FloorRequestInfoWanted . . . . . . . . . . . . . . . . 25 91 5.3.4 FloorRequestInfo . . . . . . . . . . . . . . . . . . . 26 92 5.3.5 FloorInfoWanted . . . . . . . . . . . . . . . . . . . 26 93 5.3.6 FloorInfo . . . . . . . . . . . . . . . . . . . . . . 27 94 5.3.7 ChairAction . . . . . . . . . . . . . . . . . . . . . 27 95 5.3.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . 28 96 5.3.9 Hello . . . . . . . . . . . . . . . . . . . . . . . . 28 97 5.3.10 HelloAck . . . . . . . . . . . . . . . . . . . . . . 28 98 5.3.11 Error . . . . . . . . . . . . . . . . . . . . . . . 29 99 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 30 101 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . 30 102 8.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 103 8.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 31 104 9. Authentication and Authorization . . . . . . . . . . . . . . 31 105 9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 106 9.2 Floor Control Server Behavior . . . . . . . . . . . . . . 32 107 10. Floor Participant Operations . . . . . . . . . . . . . . . . 33 108 10.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 33 109 10.1.1 Sending a FloorRequest Message . . . . . . . . . . . 33 110 10.1.2 Receiving a Response . . . . . . . . . . . . . . . . 34 111 10.2 Cancelling a Floor Request and Releasing a Floor . . . . 35 112 10.2.1 Sending a FloorRelease Message . . . . . . . . . . . 35 113 10.2.2 Receiving a Response . . . . . . . . . . . . . . . . 36 114 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 36 115 11.1 Sending a ChairAction Message . . . . . . . . . . . . . 36 116 11.2 Receiving a Response . . . . . . . . . . . . . . . . . . 37 117 12. General Client Operations . . . . . . . . . . . . . . . . . 38 118 12.1 Requesting Information about Floors . . . . . . . . . . 38 119 12.1.1 Sending a FloorInfoWanted Message . . . . . . . . . 38 120 12.1.2 Receiving a Response . . . . . . . . . . . . . . . . 38 121 12.2 Requesting Information about Floor Requests . . . . . . 39 122 12.2.1 Sending a FloorRequestInfoWanted Message . . . . . . 40 123 12.2.2 Receiving a Response . . . . . . . . . . . . . . . . 40 124 12.3 Obtaining the Capabilities of a Floor Control Server . . 41 125 12.3.1 Sending a Hello Message . . . . . . . . . . . . . . 41 126 12.3.2 Receiving Responses . . . . . . . . . . . . . . . . 41 127 13. Floor Control Server Operations . . . . . . . . . . . . . . 41 128 13.1 Reception of a FloorRequest Message . . . . . . . . . . 42 129 13.1.1 Generating the First FloorRequestInfo Message . . . 42 130 13.1.2 Generation of Subsequent FloorRequestInfo Messages . 43 131 13.2 Reception of a FloorRequestInfoWanted Message . . . . . 44 132 13.2.1 Information on a Single Floor Request . . . . . . . 44 133 13.2.2 Information on the Floor Requests Associated to a 134 Participant . . . . . . . . . . . . . . . . . . . . 45 135 13.3 Reception of a FloorRelease Message . . . . . . . . . . 45 136 13.4 Reception of a FloorInfoWanted Message . . . . . . . . . 46 137 13.4.1 Generation of the First FloorInfo Message . . . . . 47 138 13.4.2 Generation of Subsequent FloorInfo Messages . . . . 47 139 13.5 Reception of a ChairAction Message . . . . . . . . . . . 48 140 13.6 Reception of a Hello Message . . . . . . . . . . . . . . 49 141 13.7 Error Message Generation . . . . . . . . . . . . . . . . 49 142 14. Security Considerations . . . . . . . . . . . . . . . . . . 49 143 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 51 144 15.1 Attribute Subregistry . . . . . . . . . . . . . . . . . 51 145 15.2 Primitive Subregistry . . . . . . . . . . . . . . . . . 51 146 15.3 Request Status Subregistry . . . . . . . . . . . . . . . 52 147 15.4 Error Code Subregistry . . . . . . . . . . . . . . . . . 53 148 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54 149 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 150 17.1 Normative References . . . . . . . . . . . . . . . . . . . 54 151 17.2 Informational References . . . . . . . . . . . . . . . . . 55 152 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56 153 Intellectual Property and Copyright Statements . . . . . . . 57 155 1. Introduction 157 Within a conference, some applications need to manage the access to a 158 set of shared resources, such as the right to send media over a 159 particular media stream. Floor control enables such applications to 160 provide users with coordinated (shared or exclusive) access to these 161 resources. 163 The Requirements for Floor Control Protocol [11] list a set of 164 requirements that need to be met by floor control protocols. The 165 Binary Floor Control Protocol (BFCP), which is specified in this 166 document, meets these requirements. 168 In addition, BFCP has been designed so that it can be used in 169 low-bandwidth environments. The binary encoding used by BFCP 170 achieves a small message size (when message signatures are not used) 171 that keeps the time it takes to transmit delay-sensitive BFCP 172 messages at minimum. Delay-sensitive BFCP messages include 173 FloorRequest, FloorRelease, FloorRequestInfo, and ChairAction. It is 174 expected that future extensions to these messages do not increase the 175 size of these messages in a significant way. 177 The remainder of this document is organized as follows. Section 2 178 defines the terminology used throughout this document and Section 3 179 discusses the scope of BFCP (i.e., which tasks fall within the scope 180 of BFCP and which ones are performed using different mechanisms). 181 Section 4 provides a non-normative overview of BFCP operation and 182 subsequent sections provide the normative specification of BFCP. 184 2. Terminology 186 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 187 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 188 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 189 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 190 compliant implementations. 192 Media Participant: An entity that has access to the media resources 193 of a conference (e.g., it can receive a media stream). In 194 floor-controlled conferences, a given media participant is typically 195 co-located with a floor participant, but does not need to. 196 Third-party floor requests consist of having a floor participant 197 request a floor for a media participant when they are not colocated. 198 The protocol between a floor participant and a media participant 199 (that are not colocated) is outside the scope of this document. 201 Client: a floor participant or a floor chair that communicate with a 202 floor control server using BFCP. 204 Conference Policy: The complete set of rules for a particular 205 conference. It includes the membership policy, the media policy, and 206 policies related to floors and the use of floor control protocols. 207 There is an instance of conference policy for each conference. 209 Floor: A permission to temporarily access or manipulate a specific 210 shared resource or set of resources. 212 Floor Chair: A logical entity that manages one floor (grants, denies, 213 or revokes a floor). An entity that assumes the logical role of a 214 floor chair for a given transaction may assume a different role 215 (e.g., floor participant) for a different transaction. The roles of 216 floor chair and floor participant are defined on a 217 transaction-by-transaction basis. BFCP transactions are defined in 218 Section 8. 220 Floor Control: A mechanism that enables applications or users to gain 221 safe and mutually exclusive or non-exclusive input access to the 222 shared object or resource. 224 Floor Control Server: A logical entity that maintains the state of 225 the floor(s) including which floors exists, who the floor chairs are, 226 who holds a floor, etc. Requests to manipulate a floor are directed 227 at the floor control server. The floor control server of a 228 conference may perform other logical roles (e.g., floor participant) 229 in another conference. 231 Floor Participant: A logical entity that requests floors, and 232 possibly information about them, from a floor control server. An 233 entity that assumes the logical role of a floor participant for a 234 given transaction may assume a different role (e.g., a floor chair) 235 for a different transaction. The roles of floor participant and 236 floor chair are defined on a transaction-by-transaction basis. BFCP 237 transactions are defined in Section 8. In floor-controlled 238 conferences, a given floor participant is typically co-located with a 239 media participant, but does not need to. Third-party floor requests 240 consist of having a floor participant request a floor for a media 241 participant when they are not co-located. 243 Participant: An entity that acts as a floor participant, as a media 244 participant, or as both. 246 3. Scope 248 As stated earlier, BFCP is a protocol to coordinate access to shared 249 resources in a conference following the requirements defined in [11]. 250 Floor control complements other functions defined in the conferencing 251 framework [12]. In particular, it is the conference policy that 252 defines which media streams and applications are floor-controlled, 253 who is/are the respective floor chair(s), and how access to the floor 254 is managed. Furthermore, it is up to the media policy to define 255 which (if any) impact on media stream handling (e.g. switching or 256 mixing) assignment of a floor to a media participant has. 258 The floor control protocol BFCP defined in this document only 259 specifies a means to arbitrate access to floors. The rules and 260 constraints for floor arbitration and the results of floor 261 assignments are outside the scope of this document and defined by 262 other protocols [13]. 264 Figure 1 shows the tasks that BFCP can perform. 266 +---------+ 267 | Floor | 268 | Chair | 269 | | 270 +---------+ 271 ^ | 272 | | 273 Notification | | Decision 274 | | 275 | | 276 Floor | v 277 +-------------+ Request +---------+ +-------------+ 278 | Floor |----------->| Floor | Notification | Floor | 279 | Participant | | Control |------------->| Participant | 280 | |<-----------| Server | | | 281 +-------------+ Granted or +---------+ +-------------+ 282 Denied 284 Figure 1: Functionality provided by BFCP 286 BFCP provides a means: 288 o for floor participants to send floor requests to floor control 289 servers. 290 o for floor control servers to grant or deny requests to access a 291 given resource from floor participants. 292 o for floor chairs to send floor control servers decisions regarding 293 floor requests. 294 o for floor control servers to keep floor participants and floor 295 chairs informed about the status of a given floor or a given floor 296 request. 298 Even though tasks that do not belong to the previous list are outside 299 the scope of BFCP, some of these out-of-scope tasks relate to floor 300 control and are essential to create floors and to establish BFCP 301 connections between different entities. In the following 302 subsections, we discuss some of these tasks and mechanisms to perform 303 them. 305 3.1 Floor Creation 307 The association of a given floor with a resource or a set of 308 resources (e.g., media streams) is out of the scope of BFCP as 309 described in [13]. The conference policy for a particular conference 310 contains the floors of the conference and the resource or resources 311 associated with each floor. For example, a conference may have two 312 floors: one controlling who can talk at a particular time and another 313 controlling who can write on a shared whiteboard. 315 Floor creation and termination are also outside the scope of BFCP and 316 are aspects of the conference policy as well. Consequently, the 317 floor control server needs to stay up to date on changes on the 318 conference policy (e.g., when a new floor is created). 320 3.2 Obtaining Information to Contact a Floor Control Server 322 A client needs a set of data in order to establish a BFCP connection 323 to a floor control server. These data include the transport address 324 of the server, the conference identifier, and the user identifier. 326 Clients can obtain this information in different ways. One is to use 327 an offer/answer [10] exchange. How to use an SDP [8] offer/answer 328 [10] exchange to obtain this information is described in [14]. 330 3.3 Generating a Shared Secret 332 Authentication in BFCP is based on a shared secret between the client 333 and the floor control server. So, there is a need for a mechanism to 334 generate such a shared secret. However, such mechanism is outside 335 the scope of BFCP. 337 Shared secrets can also be generated and exchanged using out-of-band 338 means. For example, when the floor participant or the floor chair 339 obtains the information needed to contact the BFCP floor control 340 server over a secure channel (e.g., an offer/answer [10] exchange 341 using SIP [9] protected using S/MIME), they can get the shared secret 342 using the same channel. 344 3.4 Obtaining Floor-Resource Associations 346 Floors are associated with resources. For example, a floor that 347 controls who talks at a given time has a particular audio stream as 348 its associated resource. Associations between floors and resources 349 are part of the conference policy. 351 Floor participants and floor chairs need to know which resources are 352 associated with which floors. They can obtain this information using 353 different mechanisms, such as an offer/answer [10] exchange. How to 354 use an offer/answer exchange to obtain these associations is 355 described in [14]. 357 Note that floor participants perform offer/answer exchanges with 358 the SIP focus of the conference. So, the SIP focus needs to 359 obtain information about associations between floors and resources 360 in order to be able to provide this information to a floor 361 participant in an offer/answer exchange. 363 3.5 Policy Enforcement 365 A participant whose floor request is granted has the right to use (in 366 a certain way) the resource or resources associated with the floor 367 that was requested. For example, the participant may have the right 368 to send media over a particular audio stream. 370 Nevertheless, holding a floor does not imply that others will not be 371 able to use its associated resources at the same time, even if they 372 do not have the right to do so. According to the definition in 373 Section 2, the conference policy determines which media participants 374 can actually use the resources in the conference. 376 So, if the policy of a conference is to enforce floor control 377 decisions, every change in the status of any floor needs to be 378 reflected in the conference policy of the conference. For example, 379 the mixer only accepts media from the user who holds the floor. 381 4. Overview of Operation 383 This section provides a non-normative description of BFCP operations. 384 Section 4.1 describes the interface between floor participants and 385 floor control servers and Section 4.2 describes the interface between 386 floor chairs and floor control servers 388 BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 389 consist of a common header followed by a set of TLVs. The common 390 header contains, among other information, a 32-bit conference 391 identifier. Floor participants, media participants, and floor chairs 392 are identified by a 16-bit user identifier, which is carried in a 393 TLV. 395 There are two types of transactions in BFCP: client-initiated 396 transactions and server-initiated transactions. Client-initiated 397 transactions consist of a message from a client to the floor control 398 server and a response from the floor control server to the client. 399 Both messages can be related because they carry the same 400 TRANSACTION-ID TLV. Server-initiated transactions consist of a 401 single message, which has no TRANSACTION-ID TLV, from the floor 402 control server to a client. 404 4.1 Floor Participant to Floor Control Server Interface 406 Floor participants request a floor by sending a FloorRequest message 407 to the floor control server. BFCP supports third-party floor 408 requests. That is, the floor participant sending the floor request 409 need not be co-located with the media participant that will get the 410 floor once the floor request is granted. FloorRequest messages carry 411 the identity of the requester in a USER-ID TLV, and the identity of 412 the beneficiary of the floor, in third party floor requests, in a 413 BENEFICIARY-ID TLV. 415 Third party floor requests can be sent, for example, by floor 416 participants that have a BFCP connection to the floor control 417 server but that are not media participants (i.e., they do not 418 handle any media). 420 FloorRequest messages identify the floor or floors being requested by 421 carrying their 16-bit floor identifiers in FLOOR-ID TLVs. If a 422 FloorRequest message carries more than one floor identifier, the 423 floor control server treats all the floor requests as an atomic 424 package. That is, the floor control server either grants or denies 425 all the floors in the FloorRequest message. 427 Floor control servers respond to FloorRequest messages with 428 FloorRequestInfo messages, which provide information about the status 429 of the floor request. The first FloorRequestInfo message is the 430 response to the FloorRequest message from the client, and therefore 431 carries the same TRANSACTION-ID TLV as the FloorRequest. 433 Additionally, the first FloorRequestInfo message carries a 434 FLOOR-REQUEST-ID TLV. Subsequent FloorRequestInfo messages related 435 to the same floor request will carry the same FLOOR-REQUEST-ID TLV. 436 This way, the floor participant can associate them with the 437 appropriate floor request. 439 Messages from the floor participant related to a particular floor 440 request also use the same FLOOR-REQUEST-ID TLV as the first 441 FloorRequestInfo Message from the floor control server. 443 Figure 2 shows how a floor participant requests a floor, obtains it, 444 and, at a later time, releases it. This figure illustrates the use, 445 among other TLVs, of the TRANSACTION-ID and the FLOOR-REQUEST-ID 446 TLVs. 448 Floor Participant Floor Control 449 Server 450 |(1) FloorRequest | 451 |TRANSACTION-ID: 123 | 452 |USER-ID: 234 | 453 |FLOOR-ID: 543 | 454 |---------------------------------------------->| 455 |(2) FloorRequestInfo | 456 |TRANSACTION-ID: 123 | 457 |USER-ID: 234 | 458 |FLOOR-REQUEST-ID: 789 | 459 |FLOOR-ID: 543 | 460 |REQUEST-STATUS: Pending | 461 |<----------------------------------------------| 462 |(3) FloorRequestInfo | 463 |USER-ID: 234 | 464 |FLOOR-REQUEST-ID: 789 | 465 |FLOOR-ID: 543 | 466 |REQUEST-STATUS: Accepted (1st in Queue) | 467 |<----------------------------------------------| 468 |(4) FloorRequestInfo | 469 |USER-ID: 234 | 470 |FLOOR-REQUEST-ID: 789 | 471 |FLOOR-ID: 543 | 472 |REQUEST-STATUS: Granted | 473 |<----------------------------------------------| 474 |(5) FloorRelease | 475 |TRANSACTION-ID: 154 | 476 |USER-ID: 234 | 477 |FLOOR-REQUEST-ID: 789 | 478 |---------------------------------------------->| 479 |(6) FloorRequestInfo | 480 |TRANSACTION-ID: 154 | 481 |USER-ID: 234 | 482 |FLOOR-REQUEST-ID: 789 | 483 |FLOOR-ID: 543 | 484 |REQUEST-STATUS: Released | 485 |<----------------------------------------------| 487 Figure 2: Requesting and releasing a floor 489 Figure 2 shows how a floor participant requests to be informed on the 490 status of a floor. The first FloorInfo message from the floor 491 control server is the response to the FloorInfoWanted message, and as 492 such, carries the same TRANSACTION-ID TLV as the FloorInfoWanted 493 message. 495 Subsequent FloorInfo messages consist of server-initiated 496 transactions, and therefore carry no TRANSACTION-ID TLV. FloorInfo 497 message (2) indicates that there are currently two floor requests for 498 the floor whose Floor ID is 543. FloorInfo message (3) indicates 499 that the floor requests with Floor Request ID 764 has been granted, 500 while the floor request with Floor Request ID 635 is the first in the 501 queue. FloorInfo message (4) indicates that the floor request with 502 Floor Request ID 635 has been granted. 504 Floor Participant Floor Control 505 Server 506 |(1) FloorInfoWanted | 507 |TRANSACTION-ID: 257 | 508 |USER-ID: 234 | 509 |FLOOR-ID: 543 | 510 |---------------------------------------------->| 511 |(2) FloorInfo | 512 |TRANSACTION-ID: 257 | 513 |USER-ID: 234 | 514 |FLOOR-ID:543 | 515 |FLOOR-REQUEST-ID: 764 | 516 |FLOOR-ID: 543 | 517 |BENEFICIARY-ID: 124 | 518 |REQUEST-STATUS: Accepted (1st in Queue) | 519 |FLOOR-REQUEST-ID: 635 | 520 |BENEFICIARY-ID: 154 | 521 |FLOOR-ID: 543 | 522 |REQUEST-STATUS: Accepted (2nd in Queue) | 523 |<----------------------------------------------| 524 |(3) FloorInfo | 525 |USER-ID: 234 | 526 |FLOOR-ID:543 | 527 |FLOOR-REQUEST-ID: 764 | 528 |FLOOR-ID: 543 | 529 |BENEFICIARY-ID: 124 | 530 |REQUEST-STATUS: Granted | 531 |FLOOR-REQUEST-ID: 635 | 532 |BENEFICIARY-ID: 154 | 533 |FLOOR-ID: 543 | 534 |REQUEST-STATUS: Accepted (1st in Queue) | 535 |<----------------------------------------------| 536 |(4) FloorInfo | 537 |USER-ID: 234 | 538 |FLOOR-ID:543 | 539 |FLOOR-REQUEST-ID: 635 | 540 |BENEFICIARY-ID: 154 | 541 |FLOOR-ID: 543 | 542 |REQUEST-STATUS: Granted | 543 |<----------------------------------------------| 545 Figure 3: Obtaining status information about a floor 547 FloorInfo messages contain information about the floor requests they 548 carry. For example, FloorInfo message (4) indicates that the floor 549 request with Floor Request ID 635 has as the beneficiary (i.e., the 550 participant that holds the floor when a particular floor request is 551 granted) the participant whose User ID is 154. The floor request 552 applies only to the floor whose Floor ID is 543. That is, this is 553 not a multi-floor floor request. 555 4.2 Floor Chair to Floor Control Server Interface 557 Figure 4 shows a floor chair instructing a floor control server to 558 grant a floor. Note, however, that although the floor control server 559 needs to take into consideration the instructions received in 560 ChairAction messages (e.g., granting a floor), it does not 561 necessarily need to perform them exactly as requested by the floor 562 chair. The operation that the floor control server performs depends 563 on the ChairAction message and on the internal state of the floor 564 control server. 566 For example, a floor chair may send a ChairAction message granting a 567 floor which was requested as part of an atomic floor request 568 operation that involved several floors. Even if the chair 569 responsible for one of the floors instructs the floor control server 570 to grant the floor, the floor control server will not grant it until 571 the chairs responsible for the other floors agree to grant them as 572 well. In another example, a floor chair may instruct the floor 573 control server to grant a floor to a participant. The floor control 574 server needs to revoke the floor from its current holder before 575 granting it to the new participant. 577 So, the floor control server is ultimately responsible to keep a 578 coherent floor state using instructions from floor chairs as input to 579 this state. 581 Floor Chair Floor Control 582 Server 583 |(1) ChairAction | 584 |TRANSACTION-ID: 769 | 585 |USER-ID: 357 | 586 |FLOOR-ID: 543 | 587 |FLOOR-REQUEST-ID: 635 | 588 |REQUEST-STATUS: Granted | 589 |---------------------------------------------->| 590 |(2) ChairActionAck | 591 |TRANSACTION-ID: 769 | 592 |USER-ID: 357 | 593 |<----------------------------------------------| 595 Figure 4: Chair instructing the floor control server 597 5. Packet Format 599 BFCP packets consist of an 8-byte fixed header followed by 600 attributes. All the protocol values MUST be sent in network byte 601 order. 603 5.1 FIXED-HEADER Format 605 The following is the FIXED-HEADER format. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Ver |Reserved | Primitive | Payload Length | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Conference ID | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 5: FIXED-HEADER format 617 Ver: the 3-bit version field MUST be set to 1 to indicate this 618 version of BFCP. 620 Reserved: at this point, the 5 bits in the reserved field SHOULD be 621 set to zero by the sender of the message and MUST be ignored by the 622 receiver. 624 Primitive: this 8-bit field identifies the main purpose of the 625 message. The following primitive values are defined: 627 +-------+------------------------+-----------------------+ 628 | Value | Primitive | Direction | 629 +-------+------------------------+-----------------------+ 630 | 0 | FloorRequest | P -> S | 631 | 1 | FloorRelease | P -> S | 632 | 2 | FloorRequestInfoWanted | P -> S ; Ch -> S | 633 | 3 | FloorRequestInfo | P <- S ; Ch <- S | 634 | 4 | FloorInfoWanted | P -> S ; Ch -> S | 635 | 5 | FloorInfo | P <- S ; Ch <- S | 636 | 6 | ChairAction | Ch -> S | 637 | 7 | ChairActionAck | Ch <- S | 638 | 8 | Hello | P -> S ; Ch -> S | 639 | 9 | HelloAck | P <- S ; Ch <- S | 640 | 10 | Error | P <- S ; Ch <- S | 641 +-------+------------------------+-----------------------+ 643 S: Floor Control Server 644 P: Floor Participant 645 Ch: Floor Chair 647 Table 1: BFCP primitives 649 Payload Length: this 16-bit field contains length of the message in 650 4-byte units excluding the fixed header. 652 Conference ID: this 32-bit identifies the conference the message 653 belongs to. 655 5.2 Attribute Format 657 BFCP attributes are encoded in TLV (Type-Length-Value) format. TLVs 658 are 32-bit aligned. 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Type |M| Length | | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 665 | | 666 / Attribute Contents / 667 / / 668 | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Figure 6: TLV format 673 Type: this 7-bit field contains the type of the attribute. The 674 following attribute types are defined: 676 +------+---------------------+ 677 | Type | Attribute | 678 +------+---------------------+ 679 | 0 | FLOOR-ID | 680 | 1 | USER-ID | 681 | 2 | BENEFICIARY-ID | 682 | 3 | TRANSACTION-ID | 683 | 4 | FLOOR-REQUEST-ID | 684 | 5 | HUMAN-READABLE-INFO | 685 | 6 | DIGEST | 686 | 7 | REQUEST-STATUS | 687 | 8 | ERROR-CODE | 688 | 9 | USER-DISPLAY-NAME | 689 | 10 | USER-URI | 690 | 11 | PRIORITY | 691 | 12 | NONCE | 692 | 13 | SUPPORTED-TLVS | 693 +------+---------------------+ 695 Table 2: BFCP attributes 697 M: the 'M' bit, known as the Mandatory bit, indicates whether support 698 of the attribute is required. If an unrecognized attribute with the 699 'M' bit set is received, the message is rejected. 701 Length: this 8-bit field contains the length of the attribute in 702 bytes, excluding any padding defined for specific attributes. The 703 Type, 'M' bit, and Length fields are included. 705 Attribute Contents: the contents of the different TLVs are defined in 706 the following sections. 708 5.2.1 FLOOR-ID 710 The following is the format of the FLOOR-ID attribute. 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 |0 0 0 0 0 0 0|M|0 0 0 0 0 1 0 0| Floor ID | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 Figure 7: FLOOR-ID format 720 Floor ID: this field contains a 16-bit value that uniquely identifies 721 a floor within a conference. 723 5.2.2 USER-ID 725 The following is the format of the USER-ID attribute. 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| User ID | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Figure 8: USER-ID format 735 User ID: this field contains a 16-bit value that uniquely identifies 736 a user within a conference. 738 5.2.3 BENEFICIARY-ID 740 The following is the format of the BENEFICIARY-ID attribute. 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Beneficiary ID | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 Figure 9: BENEFICIARY-ID format 750 Beneficiary ID: this field contains a 16-bit value that uniquely 751 identifies a user within a conference. 753 5.2.4 TRANSACTION-ID 755 The following is the format of the TRANSACTION-ID attribute. 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Transaction ID | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Figure 10: TRANSACTION-ID format 765 Transaction ID: this field contains a 16-bit value that allows users 766 to match a given message with its response. 768 5.2.5 FLOOR-REQUEST-ID 770 The following is the format of the FLOOR-REQUEST-ID attribute. 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0| Floor Request ID | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Figure 11: FLOOR-REQUEST-ID format 780 Floor Request ID: this field contains a 16-bit value that indentifies 781 a floor request at the floor control server. 783 5.2.6 HUMAN-READABLE-INFO 785 The following is the format of the HUMAN-READABLE-INFO attribute. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 |0 0 0 0 1 0 1|M| Length | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 792 | | 793 / Text / 794 / +-+-+-+-+-+-+-+-+ 795 | | Padding | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Figure 12: HUMAN-READABLE-INFO format 800 Text: this field contains UTF-8 [7] encoded text. 802 In some situations, the contents of the Text field may be generated 803 by an automaton. If such automaton has information about the 804 preferred language of the receiver of a particular 805 HUMAN-READABLE-INFO TLV, it MAY use this language to generate the 806 Text field. 808 Padding: one, two, or three bytes of padding added so that the 809 contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned. The 810 Padding bits SHOULD be set to zero by the sender and MUST be ignored 811 by the receiver. If the TLV is already 32-bit aligned, no padding is 812 needed. 814 5.2.7 DIGEST 816 The following is the format of the DIGEST attribute. 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |0 0 0 0 1 1 0|M|0 0 0 1 1 0 0 0| | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 823 | | 824 + + 825 | | 826 + HMAC-SHA1 + 827 | | 828 + + 829 | | 830 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | | Padding | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Figure 13: DIGEST format 836 HMAC-SHA1: this 20-byte field contains an HMAC-SHA1 [1] of the BFCP 837 message. Its calculation is described in Section 9. 839 Padding: two bytes of padding added so that the contents of the 840 HMAC-SHA1 TLV is 32-bit aligned. The Padding bits SHOULD be set to 841 zero by the sender and MUST be ignored by the receiver. 843 5.2.8 REQUEST-STATUS 845 The following is the format of the REQUEST-STATUS attribute. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 |0 0 0 0 1 1 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 Figure 14: REQUEST-STATUS format 855 Request Status: this 8-bit field contains the status of the request, 856 as described in the following table. 858 +-------+-----------+ 859 | Value | Status | 860 +-------+-----------+ 861 | 0 | Pending | 862 | 1 | Accepted | 863 | 2 | Granted | 864 | 3 | Denied | 865 | 4 | Cancelled | 866 | 5 | Released | 867 | 6 | Revoked | 868 +-------+-----------+ 870 Table 3: Request Status values 872 Queue Position: this 8-bit field contains, when applicable, the 873 position of the floor request in the floor request queue at the 874 server. If the Request Status value is different from Accepted, the 875 floor control server does not implement a floor request queue, or the 876 floor control server does not want to provide the client with this 877 information, all the bits of this field SHOULD be set to zero. 879 A floor request is in Pending state if the floor control server needs 880 to contact a floor chair in order to accept the floor request, but 881 has not done it yet. Once the floor control chair accepts the floor 882 request, the floor request is moved to the Accepted state. 884 5.2.9 ERROR-CODE 886 The following is the format of the ERROR-CODE attribute. 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 |0 0 0 1 0 0 0|M| Length | Error Code | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | | 894 | Error Specific Details | 895 / / 896 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | | Padding | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Figure 15: ERROR-CODE format 902 Error Code: this 16-bit field contains an error code from the 903 following table. 905 +---------------------------------+---------------------------------+ 906 | Value | Meaning | 907 +---------------------------------+---------------------------------+ 908 | 0 | Conference does not Exist | 909 | 1 | Authentication Failed | 910 | 2 | Unknown Mandatory TLV | 911 | 3 | Floor Request ID Does Not Exist | 912 | 4 | Unauthorized Operation | 913 | 5 | User does not Exist | 914 | 6 | Invalid Nonce | 915 | 7 | DIGEST TLV Required | 916 | 8 | Invalid Floor ID | 917 | 9 | You have Already Reached the | 918 | | Maximum Number of Ongoing Floor | 919 | | Requests for this Floor | 920 +---------------------------------+---------------------------------+ 922 Table 4: Error Code meaning 924 Error Specific Details: Present only for certain Error Codes. In 925 this document, only for Error Code 2 (Unknown Mandatory TLV). For 926 Error Code 2, this field contains the Types of the TLVs (which were 927 present in the message that triggered the Error message) that were 928 unknown to the receiver, encoded as follows. 930 0 1 2 3 931 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 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Unknown TLV Type | Unknown TLV Type | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | | 936 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | | Unknown TLV Type | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Unknown TLV Type | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Figure 16: Unknown TLVs format 944 Padding: one, two, or three bytes of padding added so that the 945 contents of the ERROR-CODE TLV is 32-bit aligned. If the TLV is 946 already 32-bit aligned, no padding is needed. 948 The Padding bits SHOULD be set to zero by the sender and MUST be 949 ignored by the receiver. Note all the Error Codes defined in this 950 document but Error Code 2, result in a TLV which is already 32-bit 951 aligned (i.e., no need of padding). Error Code 2 results in a TLV 952 that may need 2 bytes of padding. 954 5.2.10 USER-DISPLAY-NAME 956 The format of the USER-DISPLAY-NAME attribute is the same as the 957 HUMAN-READABLE-INFO attribute (still, they have different attribute 958 types). The Text field in the USER-DISPLAY-NAME attribute contains 959 the name of the user. 961 5.2.11 USER-URI 963 The format of the USER-URI attribute is the same as the 964 HUMAN-READABLE-INFO attribute (still, they have different attribute 965 types). The Text field in the USER-URI attribute contains the URI of 966 the user. 968 5.2.12 PRIORITY 970 The following is the format of the PRIORITY attribute. 972 0 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 |0 0 0 1 0 1 1|M|0 0 0 0 0 1 0 0| Priority | Reserved | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 Figure 17: PRIORITY format 980 Priority: the higher the 8-bit value, the more priority is requested 981 for a given floor request. 983 Reserved: at this point, the 8 bits in the reserved field SHOULD be 984 set to zero by the sender of the message and MUST be ignored by the 985 receiver. 987 5.2.13 NONCE 989 The following is the format of the NONCE attribute. 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 |0 0 0 1 1 0 0|M| Length | Nonce Value | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 Figure 18: NONCE format 999 Nonce Value: this 16-bit field contains a nonce. 1001 5.2.14 SUPPORTED-TLVS 1003 The following is the format of the SUPPORTED-TLVS attribute. 1005 0 1 2 3 1006 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 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 |0 0 0 1 1 0 1|M| Length | Supported TLV | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Supported TLV | Supported TLV | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | | 1013 / / 1014 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | | Padding | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 Figure 19: SUPPORTED-TLVS format 1020 Supported TLV: these fields contain the Types of the TLVs that are 1021 supported by the floor control server. 1023 Padding: two bytes of padding added so that the contents of the 1024 SUPPORTED-TLVS TLV is 32-bit aligned. If the TLV is already 32-bit 1025 aligned, no padding is needed. 1027 The Padding bits SHOULD be set to zero by the sender and MUST be 1028 ignored by the receiver. 1030 5.3 Message Format 1032 This section contains the normative ABNF [3] of the BFCP messages. 1034 5.3.1 FloorRequest 1036 Floor participants request a floor by sending a FloorRequest message 1037 to the floor control server. The following is the format of the 1038 FloorRequest message: 1040 FloorRequest = (FIXED-HEADER) 1041 (TRANSACTION-ID) 1042 (USER-ID) 1043 [BENEFICIARY-ID] 1044 *(FLOOR-ID) 1045 [HUMAN-READABLE-INFO] 1046 [PRIORITY] 1047 [NONCE] 1048 [DIGEST] 1050 Figure 20: FloorRequest format 1052 5.3.2 FloorRelease 1054 Floor participants release a floor by sending a FloorRelease message 1055 to the floor control server. Floor participants also use the 1056 FloorRelease message to cancel pending floor requests. The following 1057 is the format of the FloorRelease message: 1059 FloorRelease = (FIXED-HEADER) 1060 (TRANSACTION-ID) 1061 (USER-ID) 1062 (FLOOR-REQUEST-ID) 1063 [NONCE] 1064 [DIGEST] 1066 Figure 21: FloorRelease format 1068 5.3.3 FloorRequestInfoWanted 1070 Floor participants and floor chairs request information about a floor 1071 request by sending a FloorRequestInfoWanted message to the floor 1072 control server. The following is the format of the 1073 FloorRequestInfoWanted message: 1075 FloorRequestInfoWanted = (FIXED-HEADER) 1076 (TRANSACTION-ID) 1077 (USER-ID) 1078 [BENEFICIARY-ID] 1079 [FLOOR-REQUEST-ID] 1080 [NONCE] 1081 [DIGEST] 1083 Figure 22: FloorRequestInfoWanted format 1085 5.3.4 FloorRequestInfo 1087 The floor control server informs floor participants and floor chairs 1088 about the status of their floor requests by sending them 1089 FloorRequestInfo messages. The following is the format of the 1090 FloorRequestInfo message: 1092 FloorRequestInfo = (FIXED-HEADER) 1093 (TRANSACTION-ID) 1094 (USER-ID) 1095 [BENEFICIARY-ID] 1096 [USER-DISPLAY-NAME] 1097 [USER-URI] 1098 1*( (FLOOR-REQUEST-ID) 1099 1*(FLOOR-ID) 1100 [HUMAN-READABLE-INFO] 1101 [PRIORITY] 1102 (REQUEST-STATUS) ) 1103 [NONCE] 1105 Figure 23: FloorRequestInfo format 1107 5.3.5 FloorInfoWanted 1109 Floor participants and floor chairs request information about a floor 1110 or floors by sending a FloorInfoWanted message to the floor control 1111 server. The following is the format of the FloorRequest message: 1113 FloorInfoWanted = (FIXED-HEADER) 1114 (TRANSACTION-ID) 1115 (USER-ID) 1116 *(FLOOR-ID) 1117 [NONCE] 1118 [DIGEST] 1120 Figure 24: FloorInfoWanted format 1122 5.3.6 FloorInfo 1124 The floor control server informs floor participants and floor chairs 1125 about the status (e.g., the current holder) of a floor by sending 1126 them FloorInfo messages. The following is the format of the 1127 FloorInfo message: 1129 FloorInfo = (FIXED-HEADER) 1130 [TRANSACTION-ID] 1131 (USER-ID) 1132 [FLOOR-ID] 1133 *( (FLOOR-REQUEST-ID) 1134 [BENEFICIARY-ID] 1135 [USER-DISPLAY-NAME] 1136 [USER-URI] 1137 *(FLOOR-ID) 1138 [HUMAN-READABLE-INFO] 1139 [PRIORITY] 1140 (REQUEST-STATUS) ) 1141 [NONCE] 1143 Figure 25: FloorInfo format 1145 5.3.7 ChairAction 1147 Floor chairs send instructions to floor control servers by sending 1148 ChairAction messages. The following is the format of the ChairAction 1149 message: 1151 ChairAction = (FIXED-HEADER) 1152 (TRANSACTION-ID) 1153 (USER-ID) 1154 1*(FLOOR-ID) 1155 (FLOOR-REQUEST-ID) 1156 (REQUEST-STATUS) 1157 [HUMAN-READABLE-INFO] 1158 [NONCE] 1159 [DIGEST] 1161 Figure 26: ChairAction format 1163 5.3.8 ChairActionAck 1165 Floor control servers confirm that they have accepted a ChairAction 1166 message by sending a ChairActionAck message. The following is the 1167 format of the ChairActionAck message: 1169 ChairActionAck = (FIXED-HEADER) 1170 (TRANSACTION-ID) 1171 (USER-ID) 1172 [NONCE] 1174 Figure 27: ChairActionAck format 1176 5.3.9 Hello 1178 Floor participants and floor chairs check the liveness of floor 1179 control servers by sending a Hello message. The following is the 1180 format of the Hello message: 1182 Hello = (FIXED-HEADER) 1183 (TRANSACTION-ID) 1184 (USER-ID) 1185 [NONCE] 1186 [DIGEST] 1188 Figure 28: Hello format 1190 5.3.10 HelloAck 1192 Floor control servers confirm that they are alive on reception of a 1193 Hello message by sending a HelloAck message. The following is the 1194 format of the HelloAck message: 1196 HelloAck = (FIXED-HEADER) 1197 (TRANSACTION-ID) 1198 (USER-ID) 1199 (SUPPORTED-TLVS) 1200 [NONCE] 1202 Figure 29: HelloAck format 1204 5.3.11 Error 1206 Floor control servers inform floor participants and floor chairs 1207 about errors processing requests by sending them Error messages. The 1208 following is the format of the Error message: 1210 Error = (FIXED-HEADER) 1211 (TRANSACTION-ID) 1212 (USER-ID) 1213 (ERROR-CODE) 1214 [NONCE] 1215 [HUMAN-READABLE-INFO] 1217 Figure 30: Error format 1219 6. Transport 1221 BFCP entities exchange BFCP messages using TCP connections. TCP 1222 provides an in-order reliable delivery of a stream of bytes. 1223 Consequently, message framing is implemented in the application 1224 layer. BFCP implements application-layer framing using TLVs. 1226 A client MUST NOT use more than one TCP connection to communicate 1227 with a given floor control server within a conference. Nevertheless, 1228 if the same physical box handles different clients (e.g., a floor 1229 chair and a floor participant), which are identified by different 1230 User IDs, a separate connection per client is allowed. 1232 If a BFCP entity (a client or a floor control server) receives data 1233 from TCP that cannot be parsed the entity MUST close the TCP 1234 connection using a RESET call (send a TCP RST bit) and the connection 1235 SHOULD be reestablished. Similarly, if a TCP connection cannot 1236 deliver a BFCP message and times out, the TCP connection SHOULD be 1237 reestablished. 1239 The way connection reestablishment is handled depends on how the 1240 client obtains information to contact the floor control server (e.g., 1241 using an offer/answer exchange [14]). Once the TCP connection is 1242 reestablished, the client MAY resend those message it did not get a 1243 response for from the floor control server. 1245 If a floor control server detects that the TCP connection towards one 1246 of the floor participants is lost, it is up to the local policy of 1247 the floor control server what to do with the pending floor requests 1248 of the floor participant. In any case, it is RECOMMENDED that the 1249 floor control server keeps the floor requests (i.e., does not cancel 1250 them) while the TCP connection is reestablished. 1252 If a client wishes to end its BFCP connection with a floor control 1253 server, the client closes (i.e., a graceful close) the TCP connection 1254 towards the floor control server. If a floor control server wishes 1255 to end its BFCP connection with a client (e.g., the focus of the 1256 conference informs the floor control server that the client has been 1257 kicked out from the conference), the floor control server closes 1258 (i.e., a graceful close) the TCP connection towards the client. 1260 7. Lower-Layer Security 1262 BFCP relies on lower-layer security mechanisms to provide replay and 1263 integrity protection, and confidentiality. BFCP floor control 1264 servers MUST support TLS [4], and BFCP clients (which include both 1265 floor participants and floor chairs) SHOULD support TLS. Any BFCP 1266 entity MAY support other security mechanisms. 1268 BFCP entities that implement TLS MUST support, at a minimum, the TLS 1269 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. 1271 8. Protocol Transactions 1273 In BFCP, there are two types of transactions: client-initiated 1274 transactions and server-initiated transactions (notifications). 1275 Client-initiated transactions consist of a request from a client to a 1276 floor control server and a response from the floor control server to 1277 the client. The request carries a TRANSACTION-ID TLV which the floor 1278 control server copies into the response. Clients use Transaction ID 1279 values to match responses with previously-issued requests. 1281 Server-initiated transactions consist of a single message from a 1282 floor control server to a client. Since they do not trigger any 1283 response, server-initiated transactions do not have Transaction IDs 1284 associated with them. 1286 8.1 Client Behavior 1288 A client starting a client-initiated transaction MUST set the 1289 Conference ID in the FIXED-HEADER of the message to the Conference ID 1290 for the conference that the client obtained previously. 1292 The client MUST set the Transaction ID value in the TRANSACTION-ID 1293 TLV to a number which MUST NOT be reused in another message from the 1294 client until a response from the server is received for the 1295 transaction. The client uses the Transaction ID value to match this 1296 message with the response from the floor control server. 1298 8.2 Server Behavior 1300 A floor control server sending a response within a client-initiated 1301 transaction MUST copy the Conference ID, the TRANSACTION-ID TLV, and 1302 the USER-ID TLV from the request received from the client into the 1303 response. Server-initiated transactions MUST NOT contain a 1304 TRANSACTION-ID TLV. 1306 9. Authentication and Authorization 1308 BFCP uses the DIGEST TLV to provide client authentication. The 1309 DIGEST TLV contains an HMAC-SHA1 [1] of the BFCP message. The use of 1310 SHA1 implies that the length of the HMAC is 20 bytes. The text used 1311 as input to HMAC is the BFCP message, including the FIXED-HEADER, up 1312 to and including the TLV preceding the DIGEST TLV. This text is then 1313 padded with zeroes so as to be a multiple of 64 bytes. As a result, 1314 the DIGEST TLV MUST be the last attribute in any BFCP message. The 1315 key used as input to HMAC is the secret shared between the server and 1316 the user identified by the USER-ID TLV in the message. 1318 9.1 Client Behavior 1320 Clients can authenticate floor control servers by checking the floor 1321 control server's certificate when the TLS connection is established 1322 between them. 1324 To achieve client authentication, a client needs to prove to the 1325 floor control server that the client can produce a DIGEST TLV for a 1326 message using their shared secret and that the message is fresh (to 1327 avoid replay attacks). Clients prove the freshness of a message by 1328 including a NONCE TLV in the message. The NONCE TLV is the second to 1329 last TLV in the message (the last one is the DIGEST TLV). 1331 The nonce to be places in the NONCE TLV by the client is typically 1332 provided by the floor control server in an Error response -- 1333 typically with Error Code 7 (DIGEST TLV Required) or 6 (Invalid 1334 Nonce). Additionally, as an optimization, the floor control server 1335 can provide a client with a NONCE to be used in the first message 1336 generated by the client using an out-of-band mechanism (e.g., using 1337 an offer/answer exchange as described in [14]). This way, the client 1338 does not need to generate an initial BFCP message only to have it 1339 rejected by the floor control server with an Error response 1340 containing a nonce. 1342 A client that obtains a nonce out-of-band SHOULD add a NONCE TLV and 1343 a DIGEST TLV to the first message it sends to the floor control 1344 server. Furthermore, if any client generates a message without a 1345 DIGEST TLV and receives an Error response with Error Code 7 (DIGEST 1346 TLV Required), the client SHOULD re-send the message with a DIGEST 1347 TLV and a NONCE TLV with the nonce received in the Error response. 1349 If after sending a message with a DIGEST TLV, a client receives an 1350 Error response with Error Code 6 (Invalid Nonce), the client SHOULD 1351 re-send the message using the new nonce received in the Error 1352 response. If the Error Code is 1 (Authentication Failed) instead, 1353 the client MUST NOT send further messages to the floor control server 1354 until it has obtained a different (hopefully valid) shared secret 1355 than the one used in the original message. 1357 If a client receives a nonce in a message from the floor control 1358 server, the client SHOULD add a NONCE TLV with this nonce and a 1359 DIGEST TLV to its next message to the floor control server. 1361 9.2 Floor Control Server Behavior 1363 Before accepting any BFCP message, the floor control server SHOULD 1364 authenticate the client. If the floor control server receives a 1365 message without DIGEST TLV from an unauthenticated client, the floor 1366 control server responds with an Error message with Error Code 7 1367 (DIGEST TLV Required). The floor control message MUST include a 1368 NONCE TLV with a nonce value that is unguessable by attackers. 1370 When a floor control server receives a BFCP message with a DIGEST 1371 TLV, it checks whether the NONCE TLV carries a nonce which was 1372 generated by the floor control server for this client and which still 1373 has not expired. If the nonce is not valid, authentication is 1374 considered to have failed, in which case the floor control server 1375 SHOULD return an Error message with Error Code 6 (Invalid Nonce) with 1376 a new nonce in a NONCE TLV. 1378 If the nonce is valid, the floor control server calculates the 1379 HMAC-SHA1 [1] of the message excluding the DIGEST TLV. The key used 1380 as input to HMAC is the secret shared between the server and the user 1381 identified by the USER-ID TLV in the message. If the resulting value 1382 is the same as the one in the DIGEST TLV, authentication is 1383 considered successful. 1385 If the resulting value is different than the one in the DIGEST TLV, 1386 authentication is considered to have failed, in which case the server 1387 SHOULD return an Error message, as described in Section 13.7, with 1388 Error Code 1 (Authentication Failed). Messages from a client that 1389 cannot be authenticated MUST NOT be processed further. 1391 Floor control servers may include a NONCE TLV in their responses to 1392 provide the nonce to be used in the next message by the client. 1393 However, when TLS is used, floor control servers typically 1394 authenticate only the first message sent over the TLS connection. 1396 After authenticating a BCFP message, the floor control server checks 1397 whether or not the client is authorized to perform the operation it 1398 is requesting. If the client is not authorized to perform the 1399 operation being requested, the floor control server generates an 1400 Error message, as described in Section 13.7, with an Error code with 1401 a value of 4 (Unauthorized Operation). Messages from a client that 1402 cannot be authorized MUST NOT be processed further. 1404 10. Floor Participant Operations 1406 This section specifies how floor participants can perform different 1407 operations, such as requesting a floor, using the protocol elements 1408 described in earlier sections. Section 11 specifies operations that 1409 are specific to floor chairs, such as instructing the floor control 1410 server to grant or revoke a floor, and Section 12 specifies 1411 operations that can be performed by any client (i.e., both floor 1412 participants and floor chairs). 1414 10.1 Requesting a Floor 1416 A floor participant that wishes to request one or more floors does so 1417 by sending a FloorRequest message to the floor control server. 1419 10.1.1 Sending a FloorRequest Message 1421 The ABNF in Section 5.3.1 describes the TLVs that a FloorRequest 1422 message can contain. In addition, the ABNF specifies normatively 1423 which of these TLVs are mandatory, and which ones are optional. 1425 The floor participant sets the Conference ID in the FIXED-HEADER and 1426 the TRANSACTION-ID TLV following the rules given in Section 8.1. 1427 Additionally, the floor participant follows the rules in Section 9.1 1428 which relate to the authentication of the message (i.e., to the 1429 DIGEST TLV). 1431 The floor participant must insert a USER-ID TLV, which will be used 1432 by the floor control server to authenticate and authorize the 1433 request. If the sender of the FloorRequest message (identified by 1434 the USER-ID TLV) is not the participant that would eventually get the 1435 floor (i.e., a third party floor request), the sender SHOULD add a 1436 BENEFICIARY-ID TLV to the message identifying the beneficiary of the 1437 floor. 1439 Note that the name space for both the User ID and the Beneficiary 1440 ID is the same. That is, a given participant is identified by a 1441 single 16-bit value that can be used in USER-ID and in 1442 BENEFICIARY-ID TLVs. 1444 The floor participant must insert at least one FLOOR-ID TLV in the 1445 FloorRequest message. If the client inserts more than one FLOOR-ID 1446 TLVs, the floor control server will treat all the floor requests as 1447 an atomic package. That is, the floor control server will either 1448 grant or deny all the floors in the FloorRequest message. 1450 The floor participant may use a HUMAN-READABLE-INFO TLV to state the 1451 reason why the floor or floors are being requested. The Text field 1452 in the HUMAN-READABLE-INFO TLV is intended for human consumption. 1454 The floor participant may request the server to handle the floor 1455 request with a certain priority using a PRIORITY TLV. 1457 10.1.2 Receiving a Response 1459 A message from the floor control server is considered to be a 1460 response to the FloorRequest message if the message from the floor 1461 control server has the same Conference ID, Transaction ID, and User 1462 ID as the FloorRequest message, as described in Section 8.1. 1464 The successful processing of a FloorRequest message at the floor 1465 control server involves generating one or several FloorRequestInfo 1466 messages. The floor participant obtains a Floor Request ID in a 1467 FLOOR-REQUEST-ID TLV in the first FloorRequestInfo message from the 1468 floor control server. Subsequent FloorRequestInfo messages from the 1469 floor control server regarding the same floor request will carry the 1470 same Floor Request ID as the initial FloorRequestInfo message. This 1471 way, the floor participant can associate subsequent incoming 1472 FloorRequestInfo messages with the ongoing floor request. 1474 The floor participant obtains information about the status of the 1475 floor request in the REQUEST-STATUS TLV of each of the 1476 FloorRequestInfo messages received from the floor control server. If 1477 the Request Status value is Granted, all the floors that were 1478 requested in the FloorRequest message have been granted. If the 1479 Request Status value is Denied, all the floors that were requested in 1480 the FloorRequest message have been denied. The HUMAN-READABLE-INFO 1481 TLV, if present, provides extra information which the floor 1482 participant MAY display to the user. 1484 A floor request is considered to be ongoing while it is in the 1485 Pending, Accepted, or Granted states. 1487 If the response is an Error message, the floor control server could 1488 not process the FloorRequest message for some reason, which is 1489 described in the Error message. 1491 10.2 Cancelling a Floor Request and Releasing a Floor 1493 A floor participant that wishes to cancel an ongoing floor request 1494 does so by sending a FloorRelease message to the floor control 1495 server. The FloorRelease message is also used by floor participants 1496 that hold a floor and would like to release it. 1498 10.2.1 Sending a FloorRelease Message 1500 The ABNF in Section 5.3.2 describes the TLVs that a FloorRelease 1501 message can contain. In addition, the ABNF specifies normatively 1502 which of these TLVs are mandatory, and which ones are optional. 1504 The floor participant sets the Conference ID in the FIXED-HEADER and 1505 the TRANSACTION-ID TLV following the rules given in Section 8.1. 1506 Additionally, the floor participant follows the rules in Section 9.1 1507 which relate to the authentication of the message (i.e., to the 1508 DIGEST TLV). The floor participant must insert a USER-ID TLV, which 1509 will be used by the floor control server to authenticate and 1510 authorize the request. 1512 Note that the FloorRelease message is used to release a floor or 1513 floors that were granted and to cancel ongoing floor requests 1514 (from the protocol perspective both are ongoing floor requests). 1515 Using the same message in both situations helps resolve the race 1516 condition that occurs when the FloorRelease message and the 1517 FloorGrant message cross each other on the wire. 1519 The floor participant uses the FLOOR-REQUEST-ID that was received in 1520 the response to the FloorRequest message that the FloorRelease 1521 message is cancelling. 1523 Note that if the floor participant requested several floors as an 1524 atomic operation (i.e., in a single FloorRequest message), all the 1525 floors are released as an atomic operation as well (i.e., all are 1526 released at the same time). 1528 10.2.2 Receiving a Response 1530 A message from the floor control server is considered to be a 1531 response to the FloorRelease message if the message from the floor 1532 control server has the same Conference ID, Transaction ID, and User 1533 ID as the FloorRequest message, as described in Section 8.1. 1535 If the response is a FloorRequestInfo message, the Request Status 1536 value in the REQUEST-STATUS-TLV will be Cancelled or Released. 1538 If the response is an Error message, the floor control server could 1539 not process the FloorRequest message for some reason, which is 1540 described in the Error message. 1542 It is possible that the FloorRelease message crosses on the wire with 1543 a FloorRequestInfo message from the server with a Request Status 1544 different from Cancelled or Released. In any case, such a 1545 FloorRequestInfo message will not be a response to the FloorRelease 1546 message, because its Transaction ID will not match that of the 1547 FloorRelease. 1549 11. Chair Operations 1551 This section specifies how floor chairs can instruct the floor 1552 control server to grant or revoke a floor using the protocol elements 1553 described in earlier sections. 1555 Floor chairs that wish to send instructions to a floor control server 1556 do so by sending a ChairAction message. 1558 11.1 Sending a ChairAction Message 1560 The ABNF in Section 5.3.7 describes the TLVs that a ChairAction 1561 message can contain. In addition, the ABNF specifies normatively 1562 which of these TLVs are mandatory, and which ones are optional. 1564 The floor chair sets the Conference ID in the FIXED-HEADER and the 1565 TRANSACTION-ID TLV following the rules given in Section 8.1. 1566 Additionally, the floor chair follows the rules in Section 9.1 which 1567 relate to the authentication of the message (i.e., to the DIGEST 1568 TLV). The floor chair must insert a USER-ID TLV, which will be used 1569 by the floor control server to authenticate and authorize the 1570 request. 1572 The ChairAction message contains instructions that apply to one or 1573 more floors within a particular floor request. The floor or floors 1574 are identified by FLOOR-ID TLVs and the floor request is identified 1575 by a FLOOR-REQUEST-ID TLV, which are carried in the ChairAction 1576 message. 1578 For example, if a floor request consists of two floors that depend 1579 on different floor chairs, each floor chair will grant its floor 1580 within the floor request. Once both chairs have granted their 1581 floor, the floor control server will grant the floor request as a 1582 whole. On the other hand, if one of the floor chairs denies its 1583 floor, the floor control server will deny the floor request as a 1584 whole, regardless of the other floor chair's decision. 1586 The floor chair provides the new status for one or more floors within 1587 the floor request using a REQUEST-STATUS TLV. If the new status of 1588 the floor request is Accepted, the floor chair MAY use the Queue 1589 Position field to provide a queue position for the floor request. If 1590 the floor chair does not wish to provide a queue position, all the 1591 bits of the Queue Position field SHOULD be set to zero. The floor 1592 chair SHOULD use the Status Revoked to revoke a floor that was 1593 granted (i.e., Granted status) and the Status Denied to reject floor 1594 requests in any other status (e.g., Pending and Accepted). 1596 Note that a floor request may involve several floors and that a 1597 ChairAction message may only deal with a subset of these floors 1598 (e.g., if a single floor chair is not authorized to manage all the 1599 floors). In this case, the REQUEST-STATUS that the floor chair 1600 provides in the ChairAction message might not be the actual status 1601 that the floor request gets at the server. The floor control 1602 server will combine the instructions received from the different 1603 floor chairs to come up with the actual status of the floor 1604 request. 1606 The floor chair may use a HUMAN-READABLE-INFO TLV to state the reason 1607 why the floor or floors are being accepted, granted, or revoked. The 1608 Text in the HUMAN-READABLE-INFO TLV is intended for human 1609 consumption. 1611 11.2 Receiving a Response 1613 A message from the floor control server is considered to be a 1614 response to the ChairAction message if the message from the server 1615 has the same Conference ID, Transaction ID, and User ID as the 1616 ChairAction message, as described in Section 8.1. 1618 A ChairActionAck message from the floor control server confirms that 1619 the floor control server has accepted the ChairAction message. An 1620 Error message indicates that the floor control server could not 1621 process the ChairAction message for some reason, which is described 1622 in the Error message. 1624 12. General Client Operations 1626 This section specifies operations that can be performed by any 1627 client. That is, they are not specific to floor participants or 1628 floor chairs. They can be performed by both. 1630 12.1 Requesting Information about Floors 1632 A client can obtain information about the status of a floor or floors 1633 in different ways, which include using BFCP and using out-of-band 1634 mechanisms. Clients using BFCP to obtain such information use the 1635 procedures described in this section. 1637 Clients request information about the status of one or several floors 1638 by sending a FloorInfoWanted message to the floor control server. 1640 12.1.1 Sending a FloorInfoWanted Message 1642 The ABNF in Section 5.3.5 describes the TLVs that a FloorInfoWanted 1643 message can contain. In addition, the ABNF specifies normatively 1644 which of these TLVs are mandatory, and which ones are optional. 1646 The client sets the Conference ID in the FIXED-HEADER and the 1647 TRANSACTION-ID TLV following the rules given in Section 8.1. 1648 Additionally, the client follows the rules in Section 9.1 which 1649 relate to the authentication and the protection of the integrity of 1650 the message (i.e., to the DIGEST TLV). The client must insert a 1651 USER-ID TLV, which will be used by the floor control server to 1652 authenticate and authorize the request. 1654 The client inserts in the message all the Floor IDs it wants to 1655 receive information about. The floor control server will send 1656 periodic information about all these floors. If the client does not 1657 want to receive information about a particular floor any longer, it 1658 sends a new FloorInfoWanted message removing the FLOOR-ID of this 1659 floor. If the client does not want to receive information about any 1660 floor any longer, it sends a FloorInfoWanted message with no FLOOR-ID 1661 TLV. 1663 12.1.2 Receiving a Response 1665 A message from the floor control server is considered to be a 1666 response to the FloorInfoWanted message if the message from the floor 1667 control server has the same Conference ID, Transaction ID, and User 1668 ID as the FloorRequest message, as described in Section 8.1. 1670 On reception of the FloorInfoWanted message, the floor control server 1671 will respond with a FloorInfo message or with an Error message. If 1672 the response is a FloorInfo message, it will contain information 1673 about one of the floors the client requested information about. If 1674 the client did not include any FLOOR-ID TLV in its FloorInfoWanted 1675 message, the FloorInfo message from the floor control server will not 1676 include any either. 1678 FloorInfo messages which carry information about a floor contain a 1679 FLOOR-ID TLV that identifies the floor. After this TLV, FloorInfo 1680 messages contain information about existing (one or more) floor 1681 request that relate to that floor. The information about each 1682 particular floor request consist of a FLOOR-REQUEST-ID TLV that 1683 identifies the floor request followed by a set of TLVs that provide 1684 information about the floor request. 1686 After the first FloorInfo, the floor control server will continue 1687 sending FloorInfo messages periodically informing the client about 1688 changes on the floors the client requested information about. 1690 12.2 Requesting Information about Floor Requests 1692 A client can obtain information about the status of one or several 1693 floor requests in different ways, which include using BFCP and using 1694 out-of-band mechanisms. Clients using BFCP to obtain such 1695 information use the procedures described in this section. 1697 Clients request information about the current status of one or 1698 several floor requests by sending a FloorRequestInfoWanted message to 1699 the floor control server. 1701 Requesting information about a particular floor request is useful 1702 in a number of situations. For example, on reception of a 1703 FloorRequest message, a floor control server may choose to return 1704 FloorRequestInfo messages only when the floor request changes its 1705 state (e.g., from Accepted to Granted), but not when the floor 1706 request advances in its queue. In this situation, if the user 1707 requests it, the floor participant can use a 1708 FloorRequestInfoWanted message to poll the floor control server 1709 for the status of the floor request. 1710 FloorRequestInfoWanted messages can also be used to request 1711 information on all the floor requests associated with a floor 1712 participant. For example, a floor participant, after experiencing 1713 connectivity problems (e.g., its TCP connection with the floor 1714 control server was down for a while and eventually was 1715 re-established), may need to request information about all the 1716 still existing floor requests associated to the floor participant. 1718 12.2.1 Sending a FloorRequestInfoWanted Message 1720 The ABNF in Section 5.3.3 describes the TLVs that a 1721 FloorRequestInfoWanted message can contain. In addition, the ABNF 1722 specifies normatively which of these TLVs are mandatory, and which 1723 ones are optional. 1725 The client sets the Conference ID in the FIXED-HEADER and the 1726 TRANSACTION-ID TLV following the rules given in Section 8.1. 1727 Additionally, the client follows the rules in Section 9.1 which 1728 relate to the authentication of the message (i.e., to the DIGEST 1729 TLV). The client must insert a USER-ID TLV, which will be used by 1730 the floor control server to authenticate and authorize the request. 1732 If the client wants to request the status of a single floor request, 1733 it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor 1734 request at the floor control server. 1736 The client can also request information about all the ongoing floor 1737 requests associated with a particular participant. In this case, the 1738 client MUST NOT insert a FLOOR-REQUEST-ID TLV. If the beneficiary of 1739 the floor requests the client is requesting information about is not 1740 the client issuing the FloorRequestInfoWanted message (which is 1741 identified by the USER-ID TLV in the message) the client MUST insert 1742 a BENEFICIARY-ID TLV. 1744 12.2.2 Receiving a Response 1746 A message from the floor control server is considered to be a 1747 response to the FloorRequestInfoWanted message if the message from 1748 the floor control server has the same Conference ID, Transaction ID,a 1749 nd User ID as the FloorRequestInfoWanted message, as described in 1750 Section 8.1. 1752 If the response is a FloorRequestInfo message, the client obtains 1753 information about the status of the FloorRequest the client requested 1754 information about in a REQUEST-STATUS TLVs. If the client requested 1755 information about several floor requests, the FloorRequestInfo 1756 message will carry several FLOOR-REQUEST-ID TLVs. Each 1757 FLOOR-REQUEST-ID TLV will be followed by TLVs (which will include a 1758 REQUEST-STATUS TLV) providing information about the floor request 1759 identified by the FLOOR-REQUEST-ID TLV. 1761 If the response is an Error message, the floor control server could 1762 not process the FloorRequestInfoWanted message for some reason, which 1763 is described in the Error message. 1765 12.3 Obtaining the Capabilities of a Floor Control Server 1767 A client that wishes to obtain the capabilities of a floor control 1768 server does so by sending a Hello message to the floor control 1769 server. 1771 12.3.1 Sending a Hello Message 1773 The ABNF in Section 5.3.9 describes the TLVs that a Hello message can 1774 contain. In addition, the ABNF specifies normatively which of these 1775 TLVs are mandatory, and which ones are optional. 1777 The client sets the Conference ID in the FIXED-HEADER and the 1778 TRANSACTION-ID TLV following the rules given in Section 8.1. 1779 Additionally, the client follows the rules in Section 9.1 which 1780 relate to the authentication and the protection of the integrity of 1781 the message (i.e., to the DIGEST TLV). The client must insert a 1782 USER-ID TLV, which will be used by the floor control server to 1783 authenticate and authorize the request. 1785 12.3.2 Receiving Responses 1787 A message from the floor control server is considered a response to 1788 the Hello message by the client if the message from the floor control 1789 server has the same Conference ID, Transaction ID, and User ID as the 1790 Hello message, as described in Section 8.1. 1792 If the response is a HelloAck message, the floor control server could 1793 process successfully the Hello message. The SUPPORTED-TLVS TLV 1794 indicates which TLVs are supported by the server. 1796 If the response is an Error message, the floor control server could 1797 not process the Hello message for some reason, which is described in 1798 the Error message. 1800 13. Floor Control Server Operations 1802 This section specifies how floor control servers can perform 1803 different operations, such as granting a floor, using the protocol 1804 elements described in earlier sections. 1806 On reception of a message from a client, the floor control server 1807 MUST check whether or not the value of the Conference ID matched an 1808 existing conference. If it does not, the floor control server SHOULD 1809 send an Error message, as described in Section 13.7, with Error code 1810 0 (Conference does not Exist). 1812 On reception of a message from a client, the floor control server 1813 follows the rules in Section 9.2, which relate to the authentication 1814 of the message. 1816 On reception of a message from a client, the floor control server 1817 MUST check whether or not it understands all the mandatory ( 'M' bit 1818 set) TLVs in the message. If the floor control server does not 1819 understand all of them, the floor control server SHOULD send an Error 1820 message, as described in Section 13.7, with Error code 2 1821 (Authentication Failed). The Error message SHOULD list the TLVs that 1822 were not understood. 1824 13.1 Reception of a FloorRequest Message 1826 On reception of a FloorRequest message, the floor control server 1827 follows the rules in Section 9.2 which relate to client 1828 authentication and authorization. If while processing the 1829 FloorRequest message, the floor control server encounters an error, 1830 it SHOULD generate an Error response following the procedures 1831 described in Section 13.7 1833 BFCP allows floor participants to have several ongoing floor 1834 requests for the same floor (e.g., the same floor participant can 1835 occupy more than one position in a queue at the same time). A 1836 floor control server that only supports a certain number of 1837 ongoing floor requests per floor participant (e.g., one) can use 1838 Error Code 9 (You have Already Reached the Maximum Number of 1839 Ongoing Floor Requests for this Floor) to inform the floor 1840 participant. 1842 13.1.1 Generating the First FloorRequestInfo Message 1844 The successful processing of a FloorRequest message by a floor 1845 control server involves generating one or several FloorRequestInfo 1846 messages, the first of which SHOULD be generated as soon as possible. 1847 If the floor control server cannot accept, grant, or deny the floor 1848 request right away (e.g., a decision from a chair is needed), it 1849 SHOULD use a Request Status value of Pending in the REQUEST-STATUS 1850 TLV of the first FloorRequestInfo message it generates. 1852 The policy a floor control server follows to grant or deny floors 1853 is outside the scope of this document. A given floor control 1854 server may perform these decisions automatically while another may 1855 contact a human acting as a chair everytime a decision needs to be 1856 made. 1858 The floor control server copies the Conference ID, the 1859 TRANSACTION-ID, and the USER-ID TLVs from the FloorRequest into the 1860 FloorRequestInfo, as described in Section 8.2. Additionally, the 1861 floor control server copies (if present) the BENEFICIARY-ID TLV from 1862 the FloorRequest into the FloorRequestInfo. 1864 The floor control server MUST assign an identitifier that is unique 1865 within the conference to this floor request, and insert it in a 1866 FLOOR-REQUEST-ID TLV into the FloorRequestInfo message. This 1867 indentifier will be used by the floor participant (or by a chair or 1868 chairs) to refer to this specific floor request in the future. 1870 The floor control server copies the FLOOR-ID TLVs from the 1871 FloorRequest into the FloorRequestInfo. These FLOOR-ID TLVs identify 1872 the floors being requested (i.e., the floors associated with this 1873 particular floor request). 1875 The floor control server also copies (if present) the PRIORITY TLV 1876 from the FloorRequest into the FloorRequestInfo. The Priority value 1877 requested by the floor participant is only a hint, and does not 1878 necessarily need to be taken into consideration to decide whether to 1879 grant or not the floor request. 1881 13.1.2 Generation of Subsequent FloorRequestInfo Messages 1883 A floor request is considered to be ongoing as long as it is not in 1884 the Cancelled, Released, or Revoked states. If the REQUEST-STATUS 1885 TLV of the first FloorRequestInfo message generated by the floor 1886 control server did not indicate any of these states, the floor 1887 control server will need to send subsequent FloorRequestInfo 1888 messages. 1890 When the status of the floor request changes, the floor control floor 1891 control server SHOULD send new FloorRequestInfo messages with the 1892 appropriate Request Status. These FloorRequestInfo messages MUST 1893 contain a FLOOR-REQUEST-ID TLV equal to the one sent in the first 1894 FloorRequestInfo message, but MUST NOT contain any TRANSACTION-ID 1895 TLV. (The Floor Request ID identifies the floor request the 1896 FloorRequestInfo applies to.) 1898 The FIXED-HEADER and the rest of the TLVs (except for the 1899 HUMAN-READABLE-INFO TLV) are the same as in the first 1900 FloorRequestInfo message. 1902 The rate at which the floor control server sends FloorRequestInfo 1903 messages is a matter of local policy. A floor control server may 1904 choose to send a new FloorRequestInfo message every time the floor 1905 request moves in the floor request queue while another may choose 1906 to only send a new FloorRequestInfo message when the floor request 1907 is Granted or Denied. 1909 The floor control server may add a HUMAN-READABLE-INFO TLV to any of 1910 the FloorRequestInfo messages it generates to provide extra 1911 information about its decisions regarding the floor request (e.g., 1912 why it was denied). 1914 Floor participants and floor chairs may request to be informed 1915 about the status of a floor following the procedures in Section 1916 12.1. If the processing of a floor request changes the status of 1917 a floor (e.g., the floor request is granted and consequently the 1918 floor has a new holder), the floor control server needs to follow 1919 the procedures in Section 13.4 to inform the clients that have 1920 requested that information 1922 The floor control server can discard the state information about a 1923 particular floor request when this reaches a status of Cancelled, 1924 Released, or Revoked. 1926 13.2 Reception of a FloorRequestInfoWanted Message 1928 On reception of a FloorRequestInfoWanted message, the floor control 1929 server follows the rules in Section 9.2 which relate to client 1930 authentication and authorization. If while processing the 1931 FloorRequestInfoWanted message, the floor control server encounters 1932 an error, it SHOULD generate an Error response following the 1933 procedures described in Section 13.7 1935 The successful processing of a FloorRequestInfoWanted message by a 1936 floor control server involves generating a FloorRequestInfo message, 1937 which SHOULD be generated as soon as possible. 1939 The floor control server copies the Conference ID, the 1940 TRANSACTION-ID, and the USER-ID TLVs from the FloorRequestInfoWanted 1941 message into the FloorRequestInfo message, as described in Section 1942 8.2. 1944 13.2.1 Information on a Single Floor Request 1946 If the FloorRequestInfoWanted message carries a FLOOR-REQUEST-ID, the 1947 sender of the message is requesting information about the floor 1948 request identified by the FLOOR-REQUEST-ID TLV. The floor control 1949 server copies the FLOOR-REQUEST-ID TLV from the 1950 FloorRequestInfoWanted message into the FloorRequestInfo message. 1952 The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo 1953 message identifying the floors being requested (i.e., the floors 1954 associated with the floor request identified by the FLOOR-REQUEST-ID 1955 TLV). 1957 The floor control server may also add a PRIORITY TLV with the 1958 Priority value requested for the floor request and a 1959 HUMAN-READABLE-INFO TLV with extra information about the floor 1960 request. 1962 The floor control server adds a REQUEST-STATUS TLV with the current 1963 status of the floor request. 1965 13.2.2 Information on the Floor Requests Associated to a Participant 1967 If the FloorRequestInfoWanted message does not carry a 1968 FLOOR-REQUEST-ID TLV, the sender of the message is requesting 1969 information about all the floor requests from a given participant. 1970 This participant is identified by a BENEFICIARY-ID TLV or, in the 1971 absence of a BENEFICIARY-ID TLV, by a USER-ID TLV. 1973 The floor control server copies (if present) the BENEFICIARY-ID TLV 1974 from the FloorRequestInfoWanted message into the FloorRequestInfo 1975 message. Additionally, the floor control server may provide extra 1976 information about the participant by adding a USER-DISPLAY-NAME TLV, 1977 a USER-URI TLV, or both to the FloorRequestInfo message. 1979 The floor control server adds a FLOOR-REQUEST-ID TLV for each floor 1980 request associated to the participant. Each FLOOR-REQUEST-ID TLV is 1981 followed by a number of TLVs which provide information about the 1982 floor request. The floor control server generates the TLVs that 1983 follow each FLOOR-REQUEST-ID following the rules in Section 13.2.1 1985 13.3 Reception of a FloorRelease Message 1987 On reception of a FloorRelease message, the floor control server 1988 follows the rules in Section 9.2 which relate to client 1989 authentication and authorization. If while processing the 1990 FloorRelease message, the floor control server encounters an error, 1991 it SHOULD generate an Error response following the procedures 1992 described in Section 13.7 1994 The successful processing of a FloorRelease message by a floor 1995 control server involves generating a FloorRequestInfo message, which 1996 SHOULD be generated as soon as possible. 1998 The floor control server copies the Conference ID, the 1999 TRANSACTION-ID, and the USER-ID TLVs from the FloorRelease message 2000 into the FloorRequestInfo message, as described in Section 8.2. 2002 The FloorRelease message identifies the floor request it applies to 2003 using a FLOOR-REQUEST-ID. If the beneficiary of the floor request is 2004 not the participant identified by the USER-ID TLV in the FloorRelease 2005 message, the floor control server adds a BENEFICIARY-ID TLV to the 2006 FloorRequestInfo message identifying the beneficiary of the floor 2007 request. Additionally, the floor control server may provide extra 2008 information about the beneficiary of the floor request by adding a 2009 USER-DISPLAY-NAME TLV, a USER-URI TLV, or both to the 2010 FloorRequestInfo message. 2012 The floor control server copies the FLOOR-REQUEST-ID TLV from the 2013 FloorRelease message into the FloorRequestInfo message. 2015 The floor control server adds FLOOR-ID TLVs to the FloorRequestInfo 2016 message identifying the floors being requested (i.e., the floors 2017 associated with the floor request identified by the FLOOR-REQUEST-ID 2018 TLV). 2020 The floor control server may also add a PRIORITY TLV with the 2021 Priority value requested for the floor request and a 2022 HUMAN-READABLE-INFO TLV with extra information about the floor 2023 request. 2025 The floor control server adds a REQUEST-STATUS TLV to the 2026 FloorRequestInfo message. The Request Status value SHOULD be 2027 Released, if the floor (or floors) had been previously granted, or of 2028 Cancelled, if the floor (or floors) had not been previously granted. 2030 13.4 Reception of a FloorInfoWanted Message 2032 On reception of a FloorInfoWanted message, the floor control server 2033 follows the rules in Section 9.2 which relate to client 2034 authentication. If while processing the FloorRelease message, the 2035 floor control server encounters an error, it SHOULD generate an Error 2036 response following the procedures described in Section 13.7 2038 A floor control server receiving a FloorInfoWanted message from a 2039 client SHOULD keep this client informed about the status of the 2040 floors identified by FLOOR-ID TLVs in the FloorInfoWanted message. 2041 Floor Control Servers keep clients informed by using FloorInfo 2042 messages. 2044 An individual FloorInfo message carries information about a single 2045 floor. So, when a FloorInfoWanted message requests information about 2046 more than one floor, the floor control server needs to send separate 2047 FloorInfo messages for different floors. 2049 The information FloorInfoWanted messages carry may depend on the user 2050 requesting the information. For example, a chair may be able to 2051 receive information about pending requests while a regular user may 2052 not be authorized to do so. 2054 13.4.1 Generation of the First FloorInfo Message 2056 The successful processing of a FloorInfoWanted message by a floor 2057 control server involves generating one or several FloorInfo messages, 2058 the first of which SHOULD be generated as soon as possible. 2060 The floor control server copies the Conference ID, the 2061 TRANSACTION-ID, and the USER-ID TLVs from the FloorInfoWanted message 2062 into the FloorInfo message, as described in Section 8.2. 2064 If the FloorInfoWanted message did not contain any FLOOR-ID TLV, the 2065 floor control server sends the FloorInfo message without adding any 2066 additional TLV and does not send any subsequent FloorInfo message to 2067 the floor participant. 2069 If the FloorInfoWanted message contained one or more FLOOR-ID TLVs, 2070 the floor control server chooses one among them and adds this 2071 FLOOR-ID TLV to the FloorInfo message. The floor control server adds 2072 a FLOOR-REQUEST-ID TLV for each floor request associated to the 2073 floor. Each FLOOR-REQUEST-ID TLV is followed by a number of TLVs 2074 which provide information about the floor request. 2076 For each FLOOR-REQUEST-ID TLV, the floor control server may add a 2077 BENEFICIARY-ID TLV identifying the requester of the floor and a 2078 USER-DISPLAY-NAME TLV, a USER-URI TLV, or both providing information 2079 about the requester. Additionally, the floor control server adds 2080 FLOOR-ID TLVs to the FloorInfo message identifying the floors being 2081 requested (i.e., the floors associated with the floor request 2082 identified by the FLOOR-REQUEST-ID TLV). 2084 The floor control server may also add a PRIORITY TLV with the 2085 Priority value requested for the floor request and a 2086 HUMAN-READABLE-INFO TLV with extra information about the floor 2087 request. 2089 The floor control server adds a REQUEST-STATUS TLV with the current 2090 status of the floor request. 2092 13.4.2 Generation of Subsequent FloorInfo Messages 2094 If the FloorInfoWanted message carried more than one FLOOR-ID TLV, 2095 the floor control server SHOULD generate a FloorInfo message for each 2096 of them (except for the FLOOR-ID TLV chosen for the first FloorInfo 2097 message) as soon as possible. These FloorInfo messages are generated 2098 following the same rules as for the first FloorInfo message (see 2099 Section 13.4.1, but without adding a TRANSACTION TLV. 2101 After generating these messages, the floor control server sends 2102 FloorInfo messages periodically keeping the client informed about all 2103 the floors the client requested information about. These messages 2104 MUST NOT carry a TRANSACTION-ID TLV. 2106 The rate at which the floor control server sends FloorInfo 2107 messages is a matter of local policy. A floor control server may 2108 choose to send a new FloorInfo message every time a new floor 2109 request arrives while another may choose to only send a new 2110 FloorInfo message when a new floor request is Granted. 2112 13.5 Reception of a ChairAction Message 2114 On reception of a ChairAction message, the floor control server 2115 follows the rules in Section 9.2 which relate to client 2116 authentication and authorization. If while processing the 2117 ChairAction message, the floor control server encounters an error, it 2118 SHOULD generate an Error response following the procedures described 2119 in Section 13.7 2121 The successful processing of a ChairAction message by a floor control 2122 server involves generating a ChairActionAck message, which SHOULD be 2123 generated as soon as possible. 2125 The floor control server copies the Conference ID, the 2126 TRANSACTION-ID, and the USER-ID TLVs from the ChairAction message 2127 into the ChairActionAck message, as described in Section 8.2. 2129 The floor control server needs to take into consideration the 2130 operation requested in the ChairAction message (e.g., granting a 2131 floor), but does not necessarily need to perform it as requested by 2132 the floor chair. The operation that the floor control server 2133 performs depends on the ChairAction message and on the internal state 2134 of the floor control server. 2136 For example, a floor chair may send a ChairAction message granting a 2137 floor which was requested as part of an atomic floor request 2138 operation that involved several floors. Even if the chair 2139 responsible for one of the floors instructs the floor control server 2140 to grant the floor, the floor control server will not grant it until 2141 the chairs responsible for the other floors agree to grant them as 2142 well. 2144 So, the floor control server is ultimately responsible to keep a 2145 coherent floor state using instructions from floor chairs as input to 2146 this state. 2148 If the new Status in the ChairAction message is Accepted and all the 2149 bits of the Queue Position field are zero, the floor chair is 2150 requesting the floor control server to assign a queue position (e.g., 2151 the last in the queue) to the floor request based on the local policy 2152 of the floor control server. (Of course, such a request only applies 2153 in case the floor control server implements a queue.) 2155 13.6 Reception of a Hello Message 2157 On reception of a Hello message, the floor control server follows the 2158 rules in Section 9.2 which relate to client authentication. If while 2159 processing the Hello message, the floor control server encounters an 2160 error, it SHOULD generate an Error response following the procedures 2161 described in Section 13.7 2163 The successful processing of a Hello message by a floor control 2164 server involves generating a HelloAck message, which SHOULD be 2165 generated as soon as possible. The floor control server copies the 2166 Conference ID, the TRANSACTION-ID, and the USER-ID TLVs from the 2167 Hello into the HelloAck, as described in Section 8.2. 2169 The floor control server adds a SUPPORTED-TLVS TLV to the HelloAck 2170 message listing all the TLVs supported by the floor control server. 2172 13.7 Error Message Generation 2174 Error messages are always sent in response to a previous message from 2175 the client as part of a client-initiated transaction. The ABNF in 2176 Section 5.3.11 describes the TLVs that an Error message can contain. 2177 In addition, the ABNF specifies normatively which of these TLVs are 2178 mandatory, and which ones are optional. 2180 The floor control server copies the Conference ID, the 2181 TRANSACTION-ID, and the USER-ID TLVs from the message from the client 2182 into the Error message, as described in Section 8.2. 2184 The floor control server adds an ERROR-CODE TLV to the Error message. 2185 The ERROR-CODE TLV contains an Error Code from Table 4. 2186 Additionally, the floor control server may add a HUMAN-READABLE-INFO 2187 TLV with extra information about the error. 2189 14. Security Considerations 2191 BFCP uses message signatures to provide client authentication and TLS 2192 to provide floor control server authentication, replay and integrity 2193 protection, and confidentiality. It is RECOMMENDED that TLS with 2194 non-null encryption is always used and that the first message from a 2195 client over a given TLS connection is signed using the DIGEST TLV. 2196 In any case, clients and floor control servers MAY use other security 2197 mechanisms as long as they provide similar security properties. 2199 The remainder of this Section analyzes some of the threats against 2200 BFCP and how they are addressed. 2202 An attacker may attempt to impersonate a client (a floor participant 2203 or a floor chair) in order to generate forged floor requests or to 2204 grant or deny existing floor requests. Client impersonation is 2205 avoided by having clients sign their messages. A nonce is included 2206 in the signature to ensure the freshness of the message. If the 2207 client is using a TLS connection to communicate with the floor 2208 control server, it is enough that the client signs its first message 2209 over the TLS connection. The floor control server assumes that 2210 attackers cannot hickjack the TLS connection and, therefore, that 2211 subsequent messages over the TLS connection come from the client that 2212 was initially authenticated. 2214 An attacker may attempt to impersonate a floor control server. A 2215 successful attacker would be able to make clients think that they 2216 hold a particular floor so that they would try to access a resource 2217 (e.g., sending media) without having legitimate rights to access it. 2218 Floor control server impersonation is avoided by having floor control 2219 servers present their server certificates at TLS connection 2220 establishment time. 2222 Attackers may attempt to modify messages exchanged by a client and a 2223 floor control server. The integrity protection provided by TLS 2224 connections prevents this attack. 2226 An attacker may attempt to fetch a valid message sent by a client to 2227 a floor control server and replay it at a later point. If the 2228 attacker attempts to replay it over the TLS connection between the 2229 client and the floor control server, TLS mechanisms discard it at the 2230 receiver side. Still, if the message was signed, the attacker may 2231 attempt to establish a new TLS connection with the floor control 2232 server and replay the message over the new connection. Using TLS 2233 confidentiality prevents this attack because the attacker cannot 2234 access the contents of the message in the first place. Additionally, 2235 if the attacker attempts to replay the encrypted message over the new 2236 connection, TLS mechanisms would discard it at the receiver side. 2237 Therefore, it is strongly RECOMMENDED that TLS is used with a 2238 non-null encryption algorithm. 2240 Attackers may attempt to pick messages from the network to get access 2241 to confidential information between the floor control server and a 2242 client (e.g., why a floor request was denied). TLS confidentiality 2243 prevents this attack. 2245 15. IANA Considerations 2247 This document instructs the IANA to create a new registry for BFCP 2248 parameters called "Binary Floor Control Protocol (BFCP) Parameters". 2249 This new registry has a number of subregistries, which are described 2250 in the following Sections 2252 15.1 Attribute Subregistry 2254 This Section establishes the Attribute subregistry under the BFCP 2255 Parameters registry. As per the terminology in RFC 2434 [5], the 2256 registration policy for BFCP attributes shall be "Specification 2257 Required". For the purposes of this subregistry, the BFCP attributes 2258 for which IANA registration is requested MUST be defined by a 2259 standards-track RFC. Such RFC MUST specify the attribute's type, 2260 name, format, and semantics. 2262 For each BFCP attribute, the IANA registers its type, its name, and 2263 the reference to the RFC where the attribute is defined. The 2264 following table contains the initial values of this subregistry. 2266 +------+---------------------+------------+ 2267 | Type | Attribute | Reference | 2268 +------+---------------------+------------+ 2269 | 0 | FLOOR-ID | [RFC XXXX] | 2270 | 1 | USER-ID | [RFC XXXX] | 2271 | 2 | BENEFICIARY-ID | [RFC XXXX] | 2272 | 3 | TRANSACTION-ID | [RFC XXXX] | 2273 | 4 | FLOOR-REQUEST-ID | [RFC XXXX] | 2274 | 5 | HUMAN-READABLE-INFO | [RFC XXXX] | 2275 | 6 | DIGEST | [RFC XXXX] | 2276 | 7 | REQUEST-STATUS | [RFC XXXX] | 2277 | 8 | ERROR-CODE | [RFC XXXX] | 2278 | 9 | USER-DISPLAY-NAME | [RFC XXXX] | 2279 | 10 | USER-URI | [RFC XXXX] | 2280 | 11 | PRIORITY | [RFC XXXX] | 2281 | 12 | NONCE | [RFC XXXX] | 2282 | 13 | SUPPORTED-TLVS | [RFC XXXX] | 2283 +------+---------------------+------------+ 2285 Table 5: Initial values of the BFCP Attribute subregistry 2287 15.2 Primitive Subregistry 2289 This Section establishes the Primitive subregistry under the BFCP 2290 Parameters registry. As per the terminology in RFC 2434 [5], the 2291 registration policy for BFCP primitives shall be "Specification 2292 Required". For the purposes of this subregistry, the BFCP primitives 2293 for which IANA registration is requested MUST be defined by a 2294 standards-track RFC. Such RFC MUST specify the primitive's value, 2295 name, format, and semantics. 2297 For each BFCP primitive, the IANA registers its value, its name, and 2298 the reference to the RFC where the primitive is defined. The 2299 following table contains the initial values of this subregistry. 2301 +-------+------------------------+------------+ 2302 | Value | Primitive | Reference | 2303 +-------+------------------------+------------+ 2304 | 0 | FloorRequest | [RFC XXXX] | 2305 | 1 | FloorRelease | [RFC XXXX] | 2306 | 2 | FloorRequestInfoWanted | [RFC XXXX] | 2307 | 3 | FloorRequestInfo | [RFC XXXX] | 2308 | 4 | FloorInfoWanted | [RFC XXXX] | 2309 | 5 | FloorInfo | [RFC XXXX] | 2310 | 6 | ChairAction | [RFC XXXX] | 2311 | 7 | ChairActionAck | [RFC XXXX] | 2312 | 8 | Hello | [RFC XXXX] | 2313 | 9 | HelloAck | [RFC XXXX] | 2314 | 10 | Error | [RFC XXXX] | 2315 +-------+------------------------+------------+ 2317 Table 6: Initial values of the BFCP primitive subregistry 2319 15.3 Request Status Subregistry 2321 This Section establishes the Request Status subregistry under the 2322 BFCP Parameters registry. As per the terminology in RFC 2434 [5], 2323 the registration policy for BFCP request status shall be 2324 "Specification Required". For the purposes of this subregistry, the 2325 BFCP request status for which IANA registration is requested MUST be 2326 defined by a standards-track RFC. Such RFC MUST specify the value 2327 and the semantics of the request status. 2329 For each BFCP request status, the IANA registers its value, its 2330 meaning, and the reference to the RFC where the request status is 2331 defined. The following table contains the initial values of this 2332 subregistry. 2334 +-------+-----------+------------+ 2335 | Value | Status | Reference | 2336 +-------+-----------+------------+ 2337 | 0 | Pending | [RFC XXXX] | 2338 | 1 | Accepted | [RFC XXXX] | 2339 | 2 | Granted | [RFC XXXX] | 2340 | 3 | Denied | [RFC XXXX] | 2341 | 4 | Cancelled | [RFC XXXX] | 2342 | 5 | Released | [RFC XXXX] | 2343 | 6 | Revoked | [RFC XXXX] | 2344 +-------+-----------+------------+ 2346 Table 7: Initial values of the Request Status subregistry 2348 15.4 Error Code Subregistry 2350 This Section establishes the Error Code subregistry under the BFCP 2351 Parameters registry. As per the terminology in RFC 2434 [5], the 2352 registration policy for BFCP error codes shall be "Specification 2353 Required". For the purposes of this subregistry, the BFCP error 2354 codes for which IANA registration is requested MUST be defined by a 2355 standards-track RFC. Such RFC MUST specify the value and the 2356 semantics of the error code, and any Error Specific Details that 2357 apply to it. 2359 For each BFCP primitive, the IANA registers its value, its meaning, 2360 and the reference to the RFC where the primitive is defined. The 2361 following table contains the initial values of this subregistry. 2363 +----------------------+----------------------+---------------------+ 2364 | Value | Meaning | Reference | 2365 +----------------------+----------------------+---------------------+ 2366 | 0 | Conference does not | [RFC XXXX] | 2367 | | Exist | | 2368 | 1 | Authentication | [RFC XXXX] | 2369 | | Failed | | 2370 | 2 | Unknown Mandatory | [RFC XXXX] | 2371 | | TLV | | 2372 | 3 | Floor Request ID | [RFC XXXX] | 2373 | | Does Not Exist | | 2374 | 4 | Unauthorized | [RFC XXXX] | 2375 | | Operation | | 2376 | 5 | User does not Exist | [RFC XXXX] | 2377 | 6 | Invalid Nonce | [RFC XXXX] | 2378 | 7 | DIGEST TLV Required | [RFC XXXX] | 2379 | 8 | Invalid Floor ID | [RFC XXXX] | 2380 | 9 | You have Already | [RFC XXXX] | 2381 | | Reached the Maximum | | 2382 | | Number of Ongoing | | 2383 | | Floor Requests for | | 2384 | | this Floor | | 2385 +----------------------+----------------------+---------------------+ 2387 Table 8: Initial Values of the Error Code subregistry 2389 16. Acknowledgments 2391 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 2392 ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, 2393 Jonathan Rosenberg, and Miguel A. Garcia-Martin provided useful 2394 comments. 2396 17. References 2398 17.1 Normative References 2400 [1] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 2401 for Message Authentication", RFC 2104, February 1997. 2403 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2404 Levels", BCP 14, RFC 2119, March 1997. 2406 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2407 Specifications: ABNF", RFC 2234, November 1997. 2409 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2410 2246, January 1999. 2412 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2413 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2415 [6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 2416 Transport Layer Security (TLS)", RFC 3268, June 2002. 2418 [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 2419 63, RFC 3629, November 2003. 2421 17.2 Informational References 2423 [8] Handley, M. and V. Jacobson, "SDP: Session Description 2424 Protocol", RFC 2327, April 1998. 2426 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2427 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 2428 Session Initiation Protocol", RFC 3261, June 2002. 2430 [10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2431 Session Description Protocol (SDP)", RFC 3264, June 2002. 2433 [11] Schulzrinne, H., "Requirements for Floor Control Protocol", 2434 draft-ietf-xcon-floor-control-req-02 (work in progress), 2435 October 2004. 2437 [12] Rosenberg, J., "A Framework for Conferencing with the Session 2438 Initiation Protocol", 2439 draft-ietf-sipping-conferencing-framework-03 (work in 2440 progress), October 2004. 2442 [13] Barnes, M. and C. Boulton, "A Framework for Centralized 2443 Conferencing", draft-barnes-xcon-framework-00 (work in 2444 progress), October 2004. 2446 [14] Camarillo, G., "Session Description Protocol (SDP) Format for 2447 Binary Floor Control Protocol (BFCP) Streams", 2448 draft-camarillo-mmusic-sdp-bfcp-00 (work in progress), April 2449 2005. 2451 Authors' Addresses 2453 Gonzalo Camarillo 2454 Ericsson 2455 Hirsalantie 11 2456 Jorvas 02420 2457 Finland 2459 EMail: Gonzalo.Camarillo@ericsson.com 2461 Joerg Ott 2462 Universitaet Bremen 2463 MZH 5180 2464 Bibliothekstr. 1 2465 Bremen D-28359 2466 Germany 2468 EMail: jo@tzi.org 2470 Keith Drage 2471 Lucent Technologies 2472 Windmill Hill Business Park 2473 Swindon 2474 Wiltshire SN5 6PP 2475 UK 2477 EMail: drage@lucent.com 2479 Intellectual Property Statement 2481 The IETF takes no position regarding the validity or scope of any 2482 Intellectual Property Rights or other rights that might be claimed to 2483 pertain to the implementation or use of the technology described in 2484 this document or the extent to which any license under such rights 2485 might or might not be available; nor does it represent that it has 2486 made any independent effort to identify any such rights. Information 2487 on the procedures with respect to rights in RFC documents can be 2488 found in BCP 78 and BCP 79. 2490 Copies of IPR disclosures made to the IETF Secretariat and any 2491 assurances of licenses to be made available, or the result of an 2492 attempt made to obtain a general license or permission for the use of 2493 such proprietary rights by implementers or users of this 2494 specification can be obtained from the IETF on-line IPR repository at 2495 http://www.ietf.org/ipr. 2497 The IETF invites any interested party to bring to its attention any 2498 copyrights, patents or patent applications, or other proprietary 2499 rights that may cover technology that may be required to implement 2500 this standard. Please address the information to the IETF at 2501 ietf-ipr@ietf.org. 2503 Disclaimer of Validity 2505 This document and the information contained herein are provided on an 2506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2508 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2509 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2510 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2513 Copyright Statement 2515 Copyright (C) The Internet Society (2004). This document is subject 2516 to the rights, licenses and restrictions contained in BCP 78, and 2517 except as set forth therein, the authors retain all their rights. 2519 Acknowledgment 2521 Funding for the RFC Editor function is currently provided by the 2522 Internet Society.