idnits 2.17.1 draft-ietf-xcon-bfcp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2831. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 29, 2005) is 6716 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 2681 ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3268 (ref. '5') (Obsoleted by RFC 5246) == Outdated reference: A later version (-03) exists of draft-ietf-mmusic-sdp-bfcp-02 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XCON Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: June 2, 2006 J. Ott 5 Helsinki University of Technology 6 K. Drage 7 Lucent Technologies 8 November 29, 2005 10 The Binary Floor Control Protocol (BFCP) 11 draft-ietf-xcon-bfcp-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 2, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 Floor control is a means to manage joint or exclusive access to 45 shared resources in a (multiparty) conferencing environment. 46 Thereby, floor control complements other functions -- such as 47 conference and media session setup, conference policy manipulation, 48 and media control -- that are realized by other protocols. 50 This document specifies the Binary Floor Control Protocol (BFCP). 51 BFCP is used between floor participants and floor control servers, 52 and between floor chairs (i.e., moderators) and floor control 53 servers. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Floor Creation . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2. Obtaining Information to Contact a Floor Control Server . 8 62 3.3. Obtaining Floor-Resource Associations . . . . . . . . . . 8 63 3.4. Privileges of Floor Control . . . . . . . . . . . . . . . 8 64 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Floor Participant to Floor Control Server Interface . . . 9 66 4.2. Floor Chair to Floor Control Server Interface . . . . . . 13 67 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 14 68 5.1. COMMON-HEADER Format . . . . . . . . . . . . . . . . . . . 14 69 5.2. Attribute Format . . . . . . . . . . . . . . . . . . . . . 16 70 5.2.1. BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 17 71 5.2.2. FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 18 72 5.2.3. FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 18 73 5.2.4. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . 18 74 5.2.5. REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 19 75 5.2.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 20 76 5.2.7. ERROR-INFO . . . . . . . . . . . . . . . . . . . . . . 22 77 5.2.8. PARTICIPANT-PROVIDED-INFO . . . . . . . . . . . . . . 22 78 5.2.9. STATUS-INFO . . . . . . . . . . . . . . . . . . . . . 23 79 5.2.10. SUPPORTED-ATTRIBUTES . . . . . . . . . . . . . . . . . 24 80 5.2.11. SUPPORTED-PRIMITIVES . . . . . . . . . . . . . . . . . 24 81 5.2.12. USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 25 82 5.2.13. USER-URI . . . . . . . . . . . . . . . . . . . . . . . 26 83 5.2.14. BENEFICIARY-INFORMATION . . . . . . . . . . . . . . . 26 84 5.2.15. FLOOR-REQUEST-INFORMATION . . . . . . . . . . . . . . 27 85 5.2.16. REQUESTED-BY-INFORMATION . . . . . . . . . . . . . . . 28 86 5.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 28 87 5.3.1. FloorRequest . . . . . . . . . . . . . . . . . . . . . 29 88 5.3.2. FloorRelease . . . . . . . . . . . . . . . . . . . . . 29 89 5.3.3. FloorRequestQuery . . . . . . . . . . . . . . . . . . 29 90 5.3.4. FloorRequestStatus . . . . . . . . . . . . . . . . . . 29 91 5.3.5. UserQuery . . . . . . . . . . . . . . . . . . . . . . 30 92 5.3.6. UserStatus . . . . . . . . . . . . . . . . . . . . . . 30 93 5.3.7. FloorQuery . . . . . . . . . . . . . . . . . . . . . . 30 94 5.3.8. FloorStatus . . . . . . . . . . . . . . . . . . . . . 31 95 5.3.9. ChairAction . . . . . . . . . . . . . . . . . . . . . 31 96 5.3.10. ChairActionAck . . . . . . . . . . . . . . . . . . . . 31 97 5.3.11. Hello . . . . . . . . . . . . . . . . . . . . . . . . 32 98 5.3.12. HelloAck . . . . . . . . . . . . . . . . . . . . . . . 32 99 5.3.13. Error . . . . . . . . . . . . . . . . . . . . . . . . 32 100 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 33 102 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 34 103 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 34 104 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 34 105 9. Authentication and Authorization . . . . . . . . . . . . . . . 34 106 9.1. TLS-based Mutual Authentication . . . . . . . . . . . . . 35 107 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 36 108 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 36 109 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 36 110 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 37 111 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 38 112 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 38 113 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 39 114 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 39 115 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 39 116 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 40 117 12. General Client Operations . . . . . . . . . . . . . . . . . . 41 118 12.1. Requesting Information about Floors . . . . . . . . . . . 41 119 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 41 120 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 41 121 12.2. Requesting Information about Floor Requests . . . . . . . 42 122 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 42 123 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 43 124 12.3. Requesting Information about a User . . . . . . . . . . . 43 125 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 44 126 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 44 127 12.4. Obtaining the Capabilities of a Floor Control Server . . . 44 128 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 44 129 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 45 130 13. Floor Control Server Operations . . . . . . . . . . . . . . . 45 131 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 46 132 13.1.1. Generating the First FloorRequestStatus Message . . . 46 133 13.1.2. Generation of Subsequent FloorRequestStatus 134 Messages . . . . . . . . . . . . . . . . . . . . . . . 47 135 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 48 136 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 49 137 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 51 138 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 52 139 13.5.1. Generation of the First FloorStatus Message . . . . . 52 140 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 54 141 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 54 142 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 55 143 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 55 144 14. Security Considerations . . . . . . . . . . . . . . . . . . . 56 145 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 146 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 57 147 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 58 148 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 58 149 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 59 150 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 151 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60 152 17.1. Normative References . . . . . . . . . . . . . . . . . . . 60 153 17.2. Informational References . . . . . . . . . . . . . . . . . 60 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 155 Intellectual Property and Copyright Statements . . . . . . . . . . 63 157 1. Introduction 159 Within a conference, some applications need to manage the access to a 160 set of shared resources, such as the right to send media over a 161 particular media stream. Floor control enables such applications to 162 provide users with coordinated (shared or exclusive) access to these 163 resources. 165 The Requirements for Floor Control Protocol [10] list a set of 166 requirements that need to be met by floor control protocols. The 167 Binary Floor Control Protocol (BFCP), which is specified in this 168 document, meets these requirements. 170 In addition, BFCP has been designed so that it can be used in low- 171 bandwidth environments. The binary encoding used by BFCP achieves a 172 small message size (when message signatures are not used) that keeps 173 the time it takes to transmit delay-sensitive BFCP messages at 174 minimum. Delay-sensitive BFCP messages include FloorRequest, 175 FloorRelease, FloorRequestStatus, and ChairAction. It is expected 176 that future extensions to these messages do not increase the size of 177 these messages in a significant way. 179 The remainder of this document is organized as follows: Section 2 180 defines the terminology used throughout this document, Section 3 181 discusses the scope of BFCP (i.e., which tasks fall within the scope 182 of BFCP and which ones are performed using different mechanisms), 183 Section 4 provides a non-normative overview of BFCP operation, and 184 subsequent sections provide the normative specification of BFCP. 186 2. Terminology 188 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 189 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 190 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 191 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 192 compliant implementations. 194 Media Participant: An entity that has access to the media resources 195 of a conference (e.g., it can receive a media stream). In floor- 196 controlled conferences, a given media participant is typically co- 197 located with a floor participant, but does not need to. Third-party 198 floor requests consist of having a floor participant request a floor 199 for a media participant when they are not colocated. The protocol 200 between a floor participant and a media participant (that are not 201 colocated) is outside the scope of this document. 203 Client: a floor participant or a floor chair that communicate with a 204 floor control server using BFCP. 206 Floor: A permission to temporarily access or manipulate a specific 207 shared resource or set of resources. 209 Floor Chair: A logical entity that manages one floor (grants, denies, 210 or revokes a floor). An entity that assumes the logical role of a 211 floor chair for a given transaction may assume a different role 212 (e.g., floor participant) for a different transaction. The roles of 213 floor chair and floor participant are defined on a transaction-by- 214 transaction basis. BFCP transactions are defined in Section 8. 216 Floor Control: A mechanism that enables applications or users to gain 217 safe and mutually exclusive or non-exclusive input access to the 218 shared object or resource. 220 Floor Control Server: A logical entity that maintains the state of 221 the floor(s) including which floors exists, who the floor chairs are, 222 who holds a floor, etc. Requests to manipulate a floor are directed 223 at the floor control server. The floor control server of a 224 conference may perform other logical roles (e.g., floor participant) 225 in another conference. 227 Floor Participant: A logical entity that requests floors, and 228 possibly information about them, from a floor control server. An 229 entity that assumes the logical role of a floor participant for a 230 given transaction may assume a different role (e.g., a floor chair) 231 for a different transaction. The roles of floor participant and 232 floor chair are defined on a transaction-by-transaction basis. BFCP 233 transactions are defined in Section 8. In floor-controlled 234 conferences, a given floor participant is typically co-located with a 235 media participant, but does not need to. Third-party floor requests 236 consist of having a floor participant request a floor for a media 237 participant when they are not co-located. 239 Participant: An entity that acts as a floor participant, as a media 240 participant, or as both. 242 3. Scope 244 As stated earlier, BFCP is a protocol to coordinate access to shared 245 resources in a conference following the requirements defined in [10]. 246 Floor control complements other functions defined in the XCON 247 conferencing framework [12] and is compatible with the SIPPING 248 conferencing framework [11]. The floor control protocol BFCP defined 249 in this document only specifies a means to arbitrate access to 250 floors. The rules and constraints for floor arbitration and the 251 results of floor assignments are outside the scope of this document 252 and defined by other protocols [12]. 254 Figure 1 shows the tasks that BFCP can perform. 256 +---------+ 257 | Floor | 258 | Chair | 259 | | 260 +---------+ 261 ^ | 262 | | 263 Notification | | Decision 264 | | 265 | | 266 Floor | v 267 +-------------+ Request +---------+ +-------------+ 268 | Floor |----------->| Floor | Notification | Floor | 269 | Participant | | Control |------------->| Participant | 270 | |<-----------| Server | | | 271 +-------------+ Granted or +---------+ +-------------+ 272 Denied 274 Figure 1: Functionality provided by BFCP 276 BFCP provides a means: 278 o for floor participants to send floor requests to floor control 279 servers. 280 o for floor control servers to grant or deny requests to access a 281 given resource from floor participants. 282 o for floor chairs to send floor control servers decisions regarding 283 floor requests. 284 o for floor control servers to keep floor participants and floor 285 chairs informed about the status of a given floor or a given floor 286 request. 288 Even though tasks that do not belong to the previous list are outside 289 the scope of BFCP, some of these out-of-scope tasks relate to floor 290 control and are essential to create floors and to establish BFCP 291 connections between different entities. In the following 292 subsections, we discuss some of these tasks and mechanisms to perform 293 them. 295 3.1. Floor Creation 297 The association of a given floor with a resource or a set of 298 resources (e.g., media streams) is out of the scope of BFCP as 299 described in [12]. Floor creation and termination are also outside 300 the scope of BFCP; these aspects are handled using the conference 301 control protocol for manipulating the conference object. 302 Consequently, the floor control server needs to stay up to date on 303 changes to the conference object (e.g., when a new floor is created). 305 3.2. Obtaining Information to Contact a Floor Control Server 307 A client needs a set of data in order to establish a BFCP connection 308 to a floor control server. These data include the transport address 309 of the server, the conference identifier, and a user identifier. 311 Clients can obtain this information in different ways. One is to use 312 an offer/answer [9] exchange, which is described in [7]. Other 313 mechanisms are also described in the XCON framework (and other 314 related documents). 316 3.3. Obtaining Floor-Resource Associations 318 Floors are associated with resources. For example, a floor that 319 controls who talks at a given time has a particular audio stream as 320 its associated resource. Associations between floors and resources 321 are part of the conference object. 323 Floor participants and floor chairs need to know which resources are 324 associated with which floors. They can obtain this information using 325 different mechanisms, such as an offer/answer [9] exchange. How to 326 use an offer/answer exchange to obtain these associations is 327 described in [7]. 329 Note that floor participants perform offer/answer exchanges with 330 the SIP [8] Focus of the conference. So, the SIP Focus needs to 331 obtain information about associations between floors and resources 332 in order to be able to provide this information to a floor 333 participant in an offer/answer exchange. 335 Other mechanisms for obtaining this information, including discussion 336 of how the information is made available to a (SIP) Focus, are 337 described in the XCON framework (and other related documents). 339 3.4. Privileges of Floor Control 341 A participant whose floor request is granted has the right to use (in 342 a certain way) the resource or resources associated with the floor 343 that was requested. For example, the participant may have the right 344 to send media over a particular audio stream. 346 Nevertheless, holding a floor does not imply that others will not be 347 able to use its associated resources at the same time, even if they 348 do not have the right to do so. Determination of which media 349 participants can actually use the resources in the conference is 350 discussed in the XCON Framework. 352 4. Overview of Operation 354 This section provides a non-normative description of BFCP operations. 355 Section 4.1 describes the interface between floor participants and 356 floor control servers and Section 4.2 describes the interface between 357 floor chairs and floor control servers 359 BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 360 consist of a common header followed by a set of attributes. The 361 common header contains, among other information, a 32-bit conference 362 identifier. Floor participants, media participants, and floor chairs 363 are identified by 16-bit user identifiers. 365 BFCP supports nested attributes (i.e., attributes that contain 366 attributes). These are referred to as grouped attributes. 368 There are two types of transactions in BFCP: client-initiated 369 transactions and server-initiated transactions. Client-initiated 370 transactions consist of a message from a client to the floor control 371 server and a response from the floor control server to the client. 372 Both messages can be related because they carry the same Transaction 373 ID value in their common headers. Server-initiated transactions 374 consist of a single message, whose Transaction ID is 0, from the 375 floor control server to a client. 377 4.1. Floor Participant to Floor Control Server Interface 379 Floor participants request a floor by sending a FloorRequest message 380 to the floor control server. BFCP supports third-party floor 381 requests. That is, the floor participant sending the floor request 382 need not be co-located with the media participant that will get the 383 floor once the floor request is granted. FloorRequest messages carry 384 the identity of the requester in the User ID field of the common 385 header, and the identity of the beneficiary of the floor (in third 386 party floor requests) in a BENEFICIARY-ID attribute. 388 Third party floor requests can be sent, for example, by floor 389 participants that have a BFCP connection to the floor control 390 server but that are not media participants (i.e., they do not 391 handle any media). 393 FloorRequest messages identify the floor or floors being requested by 394 carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a 395 FloorRequest message carries more than one floor identifier, the 396 floor control server treats all the floor requests as an atomic 397 package. That is, the floor control server either grants or denies 398 all the floors in the FloorRequest message. 400 Floor control servers respond to FloorRequest messages with 401 FloorRequestStatus messages, which provide information about the 402 status of the floor request. The first FloorRequestStatus message is 403 the response to the FloorRequest message from the client, and 404 therefore has the same Transaction ID as the FloorRequest. 406 Additionally, the first FloorRequestStatus message carries the Floor 407 Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent 408 FloorRequestStatus messages related to the same floor request will 409 carry the same Floor Request ID. This way, the floor participant can 410 associate them with the appropriate floor request. 412 Messages from the floor participant related to a particular floor 413 request also use the same Floor Request ID as the first 414 FloorRequestStatus Message from the floor control server. 416 Figure 2 shows how a floor participant requests a floor, obtains it, 417 and, at a later time, releases it. This figure illustrates the use, 418 among other things, of the Transaction ID and the FLOOR-REQUEST-ID 419 attribute. 421 Floor Participant Floor Control 422 Server 423 |(1) FloorRequest | 424 |Transaction ID: 123 | 425 |User ID: 234 | 426 |FLOOR-ID: 543 | 427 |---------------------------------------------->| 428 | | 429 |(2) FloorRequestStatus | 430 |Transaction ID: 123 | 431 |User ID: 234 | 432 |FLOOR-REQUEST-INFORMATION | 433 | Floor Request ID: 789 | 434 | FLOOR-ID: 543 | 435 | REQUEST-STATUS: Pending | 436 |<----------------------------------------------| 437 | | 438 |(3) FloorRequestStatus | 439 |Transaction ID: 0 | 440 |User ID: 234 | 441 |FLOOR-REQUEST-INFORMATION | 442 | Floor Request ID: 789 | 443 | FLOOR-ID: 543 | 444 | REQUEST-STATUS: Accepted (1st in Queue) | 445 |<----------------------------------------------| 446 | | 447 |(4) FloorRequestStatus | 448 |Transaction ID: 0 | 449 |User ID: 234 | 450 |FLOOR-REQUEST-INFORMATION | 451 | Floor Request ID: 789 | 452 | FLOOR-ID: 543 | 453 | REQUEST-STATUS: Granted | 454 |<----------------------------------------------| 455 | | 456 |(5) FloorRelease | 457 |Transaction ID: 154 | 458 |User ID: 234 | 459 |FLOOR-REQUEST-ID: 789 | 460 |---------------------------------------------->| 461 | | 462 |(6) FloorRequestStatus | 463 |Transaction ID: 154 | 464 |User ID: 234 | 465 |FLOOR-REQUEST-INFORMATION | 466 | Floor Request ID: 789 | 467 | FLOOR-ID: 543 | 468 | REQUEST-STATUS: Released | 469 |<----------------------------------------------| 471 Figure 2: Requesting and releasing a floor 473 Figure 3 shows how a floor participant requests to be informed on the 474 status of a floor. The first FloorStatus message from the floor 475 control server is the response to the FloorQuery message, and as 476 such, has the same Transaction ID as the FloorQuery message. 478 Subsequent FloorStatus messages consist of server-initiated 479 transactions, and therefore their Transaction ID is 0. FloorStatus 480 message (2) indicates that there are currently two floor requests for 481 the floor whose Floor ID is 543. FloorStatus message (3) indicates 482 that the floor requests with Floor Request ID 764 has been granted, 483 while the floor request with Floor Request ID 635 is the first in the 484 queue. FloorStatus message (4) indicates that the floor request with 485 Floor Request ID 635 has been granted. 487 Floor Participant Floor Control 488 Server 489 |(1) FloorQuery | 490 |Transaction ID: 257 | 491 |User ID: 234 | 492 |FLOOR-ID: 543 | 493 |---------------------------------------------->| 494 | | 495 |(2) FloorStatus | 496 |Transaction ID: 257 | 497 |User ID: 234 | 498 |FLOOR-ID:543 | 499 |FLOOR-REQUEST-INFORMATION | 500 | Floor Request ID: 764 | 501 | FLOOR-ID: 543 | 502 | BENEFICIARY-INFORMATION | 503 | Beneficiary ID: 124 | 504 | REQUEST-STATUS: Accepted (1st in Queue) | 505 |FLOOR-REQUEST-INFORMATION | 506 | Floor Request ID: 635 | 507 | FLOOR-ID: 543 | 508 | BENEFICIARY-INFORMATION | 509 | Beneficiary ID: 154 | 510 | REQUEST-STATUS: Accepted (2nd in Queue) | 511 |<----------------------------------------------| 512 | | 513 |(3) FloorStatus | 514 |Transaction ID: 0 | 515 |User ID: 234 | 516 |FLOOR-ID:543 | 517 |FLOOR-REQUEST-INFORMATION | 518 | Floor Request ID: 764 | 519 | FLOOR-ID: 543 | 520 | BENEFICIARY-INFORMATION | 521 | Beneficiary ID: 124 | 522 | REQUEST-STATUS: Granted | 523 |FLOOR-REQUEST-INFORMATION | 524 | Floor Request ID: 635 | 525 | FLOOR-ID: 543 | 526 | BENEFICIARY-INFORMATION | 527 | Beneficiary ID: 154 | 528 | REQUEST-STATUS: Accepted (1st in Queue) | 529 |<----------------------------------------------| 530 | | 531 |(4) FloorStatus | 532 |Transaction ID: 0 | 533 |User ID: 234 | 534 |FLOOR-ID:543 | 535 |FLOOR-REQUEST-INFORMATION | 536 | Floor Request ID: 635 | 537 | FLOOR-ID: 543 | 538 | BENEFICIARY-INFORMATION | 539 | Beneficiary ID: 154 | 540 | REQUEST-STATUS: Granted | 541 |<----------------------------------------------| 543 Figure 3: Obtaining status information about a floor 545 FloorStatus messages contain information about the floor requests 546 they carry. For example, FloorStatus message (4) indicates that the 547 floor request with Floor Request ID 635 has as the beneficiary (i.e., 548 the participant that holds the floor when a particular floor request 549 is granted) the participant whose User ID is 154. The floor request 550 applies only to the floor whose Floor ID is 543. That is, this is 551 not a multi-floor floor request. 553 A multi-floor floor request applies to more than one floor (e.g., 554 a participant wants to be able to speak and write on the 555 whiteboard at the same time). The floor control server treats a 556 multi-floor floor request as an atomic package. That is, the 557 floor control server either grants the request for all floors or 558 denies the request for all the floors. 560 4.2. Floor Chair to Floor Control Server Interface 562 Figure 4 shows a floor chair instructing a floor control server to 563 grant a floor. Note, however, that although the floor control server 564 needs to take into consideration the instructions received in 565 ChairAction messages (e.g., granting a floor), it does not 566 necessarily need to perform them exactly as requested by the floor 567 chair. The operation that the floor control server performs depends 568 on the ChairAction message and on the internal state of the floor 569 control server. 571 For example, a floor chair may send a ChairAction message granting a 572 floor which was requested as part of an atomic floor request 573 operation that involved several floors. Even if the chair 574 responsible for one of the floors instructs the floor control server 575 to grant the floor, the floor control server will not grant it until 576 the chairs responsible for the other floors agree to grant them as 577 well. In another example, a floor chair may instruct the floor 578 control server to grant a floor to a participant. The floor control 579 server needs to revoke the floor from its current holder before 580 granting it to the new participant. 582 So, the floor control server is ultimately responsible to keep a 583 coherent floor state using instructions from floor chairs as input to 584 this state. 586 Floor Chair Floor Control 587 Server 588 |(1) ChairAction | 589 |Transaction ID: 769 | 590 |User ID: 357 | 591 |FLOOR-ID: 543 | 592 |FLOOR-REQUEST-ID: 635 | 593 |REQUEST-STATUS: Granted | 594 |---------------------------------------------->| 595 | | 596 |(2) ChairActionAck | 597 |Transaction ID: 769 | 598 |User ID: 357 | 599 |<----------------------------------------------| 601 Figure 4: Chair instructing the floor control server 603 5. Packet Format 605 BFCP packets consist of a 12-octet common header followed by 606 attributes. All the protocol values MUST be sent in network byte 607 order. 609 5.1. COMMON-HEADER Format 611 The following is format of the common header. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Ver |Reserved | Primitive | Payload Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Conference ID | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Transaction ID | User ID | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 Figure 5: COMMON-HEADER format 624 Ver: the 3-bit version field MUST be set to 1 to indicate this 625 version of BFCP. 627 Reserved: at this point, the 5 bits in the reserved field SHOULD be 628 set to zero by the sender of the message and MUST be ignored by the 629 receiver. 631 Primitive: this 8-bit field identifies the main purpose of the 632 message. The following primitive values are defined: 634 +-------+--------------------+------------------+ 635 | Value | Primitive | Direction | 636 +-------+--------------------+------------------+ 637 | 1 | FloorRequest | P -> S | 638 | 2 | FloorRelease | P -> S | 639 | 3 | FloorRequestQuery | P -> S ; Ch -> S | 640 | 4 | FloorRequestStatus | P <- S ; Ch <- S | 641 | 5 | UserQuery | P -> S ; Ch -> S | 642 | 6 | UserStatus | P <- S ; Ch <- S | 643 | 7 | FloorQuery | P -> S ; Ch -> S | 644 | 8 | FloorStatus | P <- S ; Ch <- S | 645 | 9 | ChairAction | Ch -> S | 646 | 10 | ChairActionAck | Ch <- S | 647 | 11 | Hello | P -> S ; Ch -> S | 648 | 12 | HelloAck | P <- S ; Ch <- S | 649 | 13 | Error | P <- S ; Ch <- S | 650 +-------+--------------------+------------------+ 652 S: Floor Control Server 653 P: Floor Participant 654 Ch: Floor Chair 656 Table 1: BFCP primitives 658 Payload Length: this 16-bit field contains length of the message in 659 4-octet units excluding the common header. 661 Conference ID: this 32-bit field identifies the conference the 662 message belongs to. 664 Transaction ID: this field contains a 16-bit value that allows users 665 to match a given message with its response. The value of the 666 Transaction ID in server-initiated transactions is 0 (see Section 8). 668 User ID: this field contains a 16-bit value that uniquely identifies 669 a participant within a conference. 671 The identity used by a participant in BFCP, which is carried in 672 the User ID field, is generally mapped to the identity used by the 673 same participant in the session establishment protocol (e.g., in 674 SIP). The way this mapping is performed is outside the scope of 675 this specification. 677 5.2. Attribute Format 679 BFCP attributes are encoded in TLV (Type-Length-Value) format. 680 Attributes are 32-bit aligned. 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Type |M| Length | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 687 | | 688 / Attribute Contents / 689 / / 690 | | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 Figure 6: Attribute format 695 Type: this 7-bit field contains the type of the attribute. Each 696 attribute, identified by its type, has a particular format. The 697 attribute formats defined are: 699 Unsigned16: the contents of the attribute consist of a 16-bit 700 unsigned integer. 702 OctetString16: the contents of the attribute consist of 16 bits of 703 arbitrary data. 705 OctetString: the contents of the attribute consist of arbitrary 706 data of variable length. 708 Grouped: the contents of the attribute consist of a sequence of 709 attributes. 711 Note that extension attributes defined in the future may define new 712 attribute formats. 714 The following attribute types are defined: 716 +------+---------------------------+---------------+ 717 | Type | Attribute | Format | 718 +------+---------------------------+---------------+ 719 | 1 | BENEFICIARY-ID | Unsigned16 | 720 | 2 | FLOOR-ID | Unsigned16 | 721 | 3 | FLOOR-REQUEST-ID | Unsigned16 | 722 | 4 | PRIORITY | OctetString16 | 723 | 5 | REQUEST-STATUS | OctetString16 | 724 | 6 | ERROR-CODE | OctetString | 725 | 7 | ERROR-INFO | OctetString | 726 | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | 727 | 9 | STATUS-INFO | OctetString | 728 | 10 | SUPPORTED-ATTRIBUTES | OctetString | 729 | 11 | SUPPORTED-PRIMITIVES | OctetString | 730 | 12 | USER-DISPLAY-NAME | OctetString | 731 | 13 | USER-URI | OctetString | 732 | 14 | BENEFICIARY-INFORMATION | Grouped | 733 | 15 | FLOOR-REQUEST-INFORMATION | Grouped | 734 | 16 | REQUESTED-BY-INFORMATION | Grouped | 735 +------+---------------------------+---------------+ 737 Table 2: BFCP attributes 739 M: the 'M' bit, known as the Mandatory bit, indicates whether support 740 of the attribute is required. If an unrecognized attribute with the 741 'M' bit set is received, the message is rejected. 743 Length: this 8-bit field contains the length of the attribute in 744 octets, excluding any padding defined for specific attributes. The 745 Type, 'M' bit, and Length fields are included. The Length in grouped 746 attributes is the length of the grouped attribute itself (including 747 Type, 'M' bit, and Length fields) plus the total length (including 748 padding) of all the included attributes. 750 Attribute Contents: the contents of the different attributes are 751 defined in the following sections. 753 5.2.1. BENEFICIARY-ID 755 The following is the format of the BENEFICIARY-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 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Figure 7: BENEFICIARY-ID format 765 Beneficiary ID: this field contains a 16-bit value that uniquely 766 identifies a user within a conference. 768 Note that although the formats of the Beneficiary ID and of the User 769 ID field in the common header are similar, their semantics are 770 different. The Beneficiary ID is used in third-party floor requests 771 and to request information about a particular participant. 773 5.2.2. FLOOR-ID 775 The following is the format of the FLOOR-ID attribute. 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 Figure 8: FLOOR-ID format 785 Floor ID: this field contains a 16-bit value that uniquely identifies 786 a floor within a conference. 788 5.2.3. FLOOR-REQUEST-ID 790 The following is the format of the FLOOR-REQUEST-ID attribute. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Figure 9: FLOOR-REQUEST-ID format 800 Floor Request ID: this field contains a 16-bit value that identifies 801 a floor request at the floor control server. 803 5.2.4. PRIORITY 805 The following is the format of the PRIORITY attribute. 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 Figure 10: PRIORITY format 815 Prio: this field contains a 3-bit priority value as shown in Table 3. 816 Senders SHOULD NOT use values higher than 4 in this field. Receivers 817 MUST treat values higher than 4 as if the value received had been 4 818 (Highest). The default priority value when the PRIORITY attribute is 819 missing is 2 (Normal). 821 +-------+----------+ 822 | Value | Priority | 823 +-------+----------+ 824 | 0 | Lowest | 825 | 1 | Low | 826 | 2 | Normal | 827 | 3 | High | 828 | 4 | Highest | 829 +-------+----------+ 831 Table 3: Priority values 833 Reserved: at this point, the 13 bits in the reserved field SHOULD be 834 set to zero by the sender of the message and MUST be ignored by the 835 receiver. 837 5.2.5. REQUEST-STATUS 839 The following is the format of the REQUEST-STATUS attribute. 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Figure 11: REQUEST-STATUS format 849 Request Status: this 8-bit field contains the status of the request, 850 as described in the following table. 852 +-------+-----------+ 853 | Value | Status | 854 +-------+-----------+ 855 | 1 | Pending | 856 | 2 | Accepted | 857 | 3 | Granted | 858 | 4 | Denied | 859 | 5 | Cancelled | 860 | 6 | Released | 861 | 7 | Revoked | 862 +-------+-----------+ 864 Table 4: Request Status values 866 Queue Position: this 8-bit field contains, when applicable, the 867 position of the floor request in the floor request queue at the 868 server. If the Request Status value is different from Accepted, the 869 floor control server does not implement a floor request queue, or the 870 floor control server does not want to provide the client with this 871 information, all the bits of this field SHOULD be set to zero. 873 A floor request is in Pending state if the floor control server needs 874 to contact a floor chair in order to accept the floor request, but 875 has not done it yet. Once the floor control chair accepts the floor 876 request, the floor request is moved to the Accepted state. 878 5.2.6. ERROR-CODE 880 The following is the format of the ERROR-CODE attribute. 882 0 1 2 3 883 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 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 |0 0 0 0 1 1 0|M| Length | Error Code | | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 887 | | 888 | Error Specific Details | 889 / / 890 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | | Padding | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Figure 12: ERROR-CODE format 896 Error Code: this 8-bit field contains an error code from the 897 following table. 899 +-------+-----------------------------------------------------------+ 900 | Value | Meaning | 901 +-------+-----------------------------------------------------------+ 902 | 1 | Conference does not Exist | 903 | 2 | User does not Exist | 904 | 3 | Unknown Primitive | 905 | 4 | Unknown Mandatory Attribute | 906 | 5 | Unauthorized Operation | 907 | 6 | Invalid Floor ID | 908 | 7 | Floor Request ID Does Not Exist | 909 | 8 | You have Already Reached the Maximum Number of Ongoing | 910 | | Floor Requests for this Floor | 911 | 9 | Use TLS | 912 +-------+-----------------------------------------------------------+ 914 Table 5: Error Code meaning 916 Error Specific Details: Present only for certain Error Codes. In 917 this document, only for Error Code 4 (Unknown Mandatory Attribute). 918 See Section 5.2.6.1 for its definition. 920 Padding: one, two, or three octets of padding added so that the 921 contents of the ERROR-CODE attribute is 32-bit aligned. If the 922 attribute is already 32-bit aligned, no padding is needed. 924 The Padding bits SHOULD be set to zero by the sender and MUST be 925 ignored by the receiver. 927 5.2.6.1. Error Specific Details for Error Code 4 929 The following is the format of the Error Specific Details field for 930 Error Code 4. 932 0 1 2 3 933 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 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | | 938 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | | Unknown Type|R| Unknown Type|R| 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Unknown Type|R| Unknown Type|R| 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Figure 13: Unknown attributes format 945 Unknown Type: these 7-bit fields contain the Types of the attributes 946 (which were present in the message that triggered the Error message) 947 that were unknown to the receiver 949 R: at this point, this bit is reserved. It SHOULD be set to zero by 950 the sender of the message and MUST be ignored by the receiver. 952 5.2.7. ERROR-INFO 954 The following is the format of the ERROR-INFO attribute. 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 |0 0 0 0 1 1 1|M| Length | | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 961 | | 962 / Text / 963 / +-+-+-+-+-+-+-+-+ 964 | | Padding | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 14: ERROR-INFO format 969 Text: this field contains UTF-8 [6] encoded text. 971 In some situations, the contents of the Text field may be generated 972 by an automaton. If such automaton has information about the 973 preferred language of the receiver of a particular ERROR-INFO 974 attribute, it MAY use this language to generate the Text field. 976 Padding: one, two, or three octets of padding added so that the 977 contents of the ERROR-INFO attribute is 32-bit aligned. The Padding 978 bits SHOULD be set to zero by the sender and MUST be ignored by the 979 receiver. If the attribute is already 32-bit aligned, no padding is 980 needed. 982 5.2.8. PARTICIPANT-PROVIDED-INFO 984 The following is the format of the PARTICIPANT-PROVIDED-INFO 985 attribute. 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 |0 0 0 1 0 0 0|M| Length | | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 992 | | 993 / Text / 994 / +-+-+-+-+-+-+-+-+ 995 | | Padding | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 Figure 15: PARTICIPANT-PROVIDED-INFO format 1000 Text: this field contains UTF-8 [6] encoded text. 1002 Padding: one, two, or three octets of padding added so that the 1003 contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit 1004 aligned. The Padding bits SHOULD be set to zero by the sender and 1005 MUST be ignored by the receiver. If the attribute is already 32-bit 1006 aligned, no padding is needed. 1008 5.2.9. STATUS-INFO 1010 The following is the format of the STATUS-INFO attribute. 1012 0 1 2 3 1013 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 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 |0 0 0 1 0 0 1|M| Length | | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1017 | | 1018 / Text / 1019 / +-+-+-+-+-+-+-+-+ 1020 | | Padding | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 Figure 16: STATUS-INFO format 1025 Text: this field contains UTF-8 [6] encoded text. 1027 In some situations, the contents of the Text field may be generated 1028 by an automaton. If such automaton has information about the 1029 preferred language of the receiver of a particular STATUS-INFO 1030 attribute, it MAY use this language to generate the Text field. 1032 Padding: one, two, or three octets of padding added so that the 1033 contents of the STATUS-INFO attribute is 32-bit aligned. The Padding 1034 bits SHOULD be set to zero by the sender and MUST be ignored by the 1035 receiver. If the attribute is already 32-bit aligned, no padding is 1036 needed. 1038 5.2.10. SUPPORTED-ATTRIBUTES 1040 The following is the format of the SUPPORTED-ATTRIBUTES attribute. 1042 0 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 |0 0 0 1 0 1 0|M| Length | Supported Attribute | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Supported Attribute | Supported Attribute | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | | 1050 / / 1051 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | | Padding | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 Figure 17: SUPPORTED-ATTRIBUTES format 1057 Supported Attribute: these fields contain the Types of the attributes 1058 that are supported by the floor control server. 1060 Padding: two octets of padding added so that the contents of the 1061 SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute 1062 is already 32-bit aligned, no padding is needed. 1064 The Padding bits SHOULD be set to zero by the sender and MUST be 1065 ignored by the receiver. 1067 5.2.11. SUPPORTED-PRIMITIVES 1069 The following is the format of the SUPPORTED-PRIMITIVES attribute. 1071 0 1 2 3 1072 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 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Primitive | Primitive | Primitive | Primitive | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | | 1079 / / 1080 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | | Padding | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 Figure 18: SUPPORTED-PRIMITIVES format 1086 Primitive: these fields contain the types of the BFCP messages that 1087 are supported by the floor control server. See Table 1 for the list 1088 of BFCP primitives. 1090 Padding: one, two, or three octets of padding added so that the 1091 contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If 1092 the attribute is already 32-bit aligned, no padding is needed. 1094 The Padding bits SHOULD be set to zero by the sender and MUST be 1095 ignored by the receiver. 1097 5.2.12. USER-DISPLAY-NAME 1099 The following is the format of the USER-DISPLAY-NAME attribute. 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 |0 0 0 1 1 0 0|M| Length | | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1106 | | 1107 / Text / 1108 / +-+-+-+-+-+-+-+-+ 1109 | | Padding | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 Figure 19: USER-DISPLAY-NAME format 1114 Text: this field contains the UTF-8 encoded name of the user. 1116 Padding: one, two, or three octets of padding added so that the 1117 contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The 1118 Padding bits SHOULD be set to zero by the sender and MUST be ignored 1119 by the receiver. If the attribute is already 32-bit aligned, no 1120 padding is needed. 1122 5.2.13. USER-URI 1124 The following is the format of the USER-URI attribute. 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 |0 0 0 1 1 0 1|M| Length | | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1131 | | 1132 / Text / 1133 / +-+-+-+-+-+-+-+-+ 1134 | | Padding | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 Figure 20: USER-URI format 1139 Text: this field contains the UTF-8 encoded user's contact URI. That 1140 is, the URI used by the user to set up the resources (e.g., media 1141 streams) that are controlled by BFCP. For example, in the context of 1142 a conference set up by SIP, the USER-URI attribute would carry the 1143 SIP URI of the user. 1145 Messages containing a user's URI in a USER-URI attribute also 1146 contain the user's User ID. This way, a client receiving such a 1147 message can correlate the user's URI (e.g., the SIP URI the user 1148 used to join a conference) with the user's User ID. 1150 Padding: one, two, or three octets of padding added so that the 1151 contents of the USER-URI attribute is 32-bit aligned. The Padding 1152 bits SHOULD be set to zero by the sender and MUST be ignored by the 1153 receiver. If the attribute is already 32-bit aligned, no padding is 1154 needed. 1156 5.2.14. BENEFICIARY-INFORMATION 1158 The BENEFICIARY-INFORMATION attribute is a grouped attribute that 1159 consists of a header, which is referred to as BENEFICIARY- 1160 INFORMATION-HEADER, followed by a sequence of attributes. The 1161 following is the format of the BENEFICIARY-INFORMATION-HEADER: 1163 0 1 2 3 1164 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 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 |0 0 0 1 1 1 0|M| Length | Beneficiary ID | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 Figure 21: BENEFICIARY-INFORMATION-HEADER format 1171 Beneficiary ID: this field contains a 16-bit value that uniquely 1172 identifies a user within a conference. 1174 The following is the ABNF (Augmented Backus-Naur Form) [2] of the 1175 BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE 1176 refers to extension attributes that may be defined in the future.) 1178 BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) 1179 [USER-DISPLAY-NAME] 1180 [USER-URI] 1181 *[EXTENSION-ATTRIBUTE] 1183 Figure 22: BENEFICIARY-INFORMATION format 1185 5.2.15. FLOOR-REQUEST-INFORMATION 1187 The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that 1188 consists of a header, which is referred to as FLOOR-REQUEST- 1189 INFORMATION-HEADER, followed by a sequence of attributes. The 1190 following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: 1192 0 1 2 3 1193 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 |0 0 0 1 1 1 1|M| Length | Floor Request ID | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format 1200 Floor Request ID: this field contains a 16-bit value that identifies 1201 a floor request at the floor control server. 1203 The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped 1204 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1205 may be defined in the future.) 1206 FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) 1207 (REQUEST-STATUS) 1208 1*(FLOOR-ID) 1209 [BENEFICIARY-INFORMATION] 1210 [REQUESTED-BY-INFORMATION] 1211 [PRIORITY] 1212 [PARTICIPANT-PROVIDED-INFO] 1213 [STATUS-INFO] 1214 *[EXTENSION-ATTRIBUTE] 1216 Figure 24: FLOOR-REQUEST-INFORMATION format 1218 5.2.16. REQUESTED-BY-INFORMATION 1220 The REQUESTED-BY-INFORMATION attribute is a grouped attribute that 1221 consists of a header, which is referred to as REQUESTED-BY- 1222 INFORMATION-HEADER, followed by a sequence of attributes. The 1223 following is the format of the REQUESTED-BY-INFORMATION-HEADER: 1225 0 1 2 3 1226 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 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 |0 0 1 0 0 0 0|M| Length | Requested-by ID | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 Figure 25: REQUESTED-BY-INFORMATION-HEADER format 1233 Requested-by ID: this field contains a 16-bit value that uniquely 1234 identifies a user within a conference. 1236 The following is the ABNF of the REQUESTED-BY-INFORMATION grouped 1237 attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that 1238 may be defined in the future.) 1240 REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) 1241 [USER-DISPLAY-NAME] 1242 [USER-URI] 1243 *[EXTENSION-ATTRIBUTE] 1245 Figure 26: REQUESTED-BY-INFORMATION format 1247 5.3. Message Format 1249 This section contains the normative ABNF (Augmented Backus-Naur Form) 1250 [2] of the BFCP messages. Extension attributes that may be defined 1251 in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. 1253 5.3.1. FloorRequest 1255 Floor participants request a floor by sending a FloorRequest message 1256 to the floor control server. The following is the format of the 1257 FloorRequest message: 1259 FloorRequest = (COMMON-HEADER) 1260 *(FLOOR-ID) 1261 [BENEFICIARY-ID] 1262 [PARTICIPANT-PROVIDED-INFO] 1263 [PRIORITY] 1264 *[EXTENSION-ATTRIBUTE] 1266 Figure 27: FloorRequest format 1268 5.3.2. FloorRelease 1270 Floor participants release a floor by sending a FloorRelease message 1271 to the floor control server. Floor participants also use the 1272 FloorRelease message to cancel pending floor requests. The following 1273 is the format of the FloorRelease message: 1275 FloorRelease = (COMMON-HEADER) 1276 (FLOOR-REQUEST-ID) 1277 *[EXTENSION-ATTRIBUTE] 1279 Figure 28: FloorRelease format 1281 5.3.3. FloorRequestQuery 1283 Floor participants and floor chairs request information about a floor 1284 request by sending a FloorRequestQuery message to the floor control 1285 server. The following is the format of the FloorRequestQuery 1286 message: 1288 FloorRequestQuery = (COMMON-HEADER) 1289 (FLOOR-REQUEST-ID) 1290 *[EXTENSION-ATTRIBUTE] 1292 Figure 29: FloorRequestQuery format 1294 5.3.4. FloorRequestStatus 1296 The floor control server informs floor participants and floor chairs 1297 about the status of their floor requests by sending them 1298 FloorRequestStatus messages. The following is the format of the 1299 FloorRequestStatus message: 1301 FloorRequestStatus = (COMMON-HEADER) 1302 (FLOOR-REQUEST-INFORMATION) 1303 *[EXTENSION-ATTRIBUTE] 1305 Figure 30: FloorRequestStatus format 1307 5.3.5. UserQuery 1309 Floor participants and floor chairs request information about a 1310 participant and the floor requests related to this participant by 1311 sending a UserQuery message to the floor control server. The 1312 following is the format of the UserQuery message: 1314 UserQuery = (COMMON-HEADER) 1315 [BENEFICIARY-ID] 1316 *[EXTENSION-ATTRIBUTE] 1318 Figure 31: UserQuery format 1320 5.3.6. UserStatus 1322 The floor control server provide information about participants and 1323 their related floor requests to floor participants and floor chairs 1324 by sending them UserStatus messages. The following is the format of 1325 the UserStatus message: 1327 UserStatus = (COMMON-HEADER) 1328 [BENEFICIARY-INFORMATION] 1329 1*(FLOOR-REQUEST-INFORMATION) 1330 *[EXTENSION-ATTRIBUTE] 1332 Figure 32: UserStatus format 1334 5.3.7. FloorQuery 1336 Floor participants and floor chairs request information about a floor 1337 or floors by sending a FloorQuery message to the floor control 1338 server. The following is the format of the FloorRequest message: 1340 FloorQuery = (COMMON-HEADER) 1341 *(FLOOR-ID) 1342 *[EXTENSION-ATTRIBUTE] 1344 Figure 33: FloorQuery format 1346 5.3.8. FloorStatus 1348 The floor control server informs floor participants and floor chairs 1349 about the status (e.g., the current holder) of a floor by sending 1350 them FloorStatus messages. The following is the format of the 1351 FloorStatus message: 1353 FloorStatus = (COMMON-HEADER) 1354 (FLOOR-ID) 1355 *[FLOOR-REQUEST-INFORMATION] 1356 *[EXTENSION-ATTRIBUTE] 1358 Figure 34: FloorStatus format 1360 5.3.9. ChairAction 1362 Floor chairs send instructions to floor control servers by sending 1363 ChairAction messages. The following is the format of the ChairAction 1364 message: 1366 ChairAction = (COMMON-HEADER) 1367 1*(FLOOR-ID) 1368 (FLOOR-REQUEST-ID) 1369 (REQUEST-STATUS) 1370 [STATUS-INFO] 1371 *[EXTENSION-ATTRIBUTE] 1373 Figure 35: ChairAction format 1375 5.3.10. ChairActionAck 1377 Floor control servers confirm that they have accepted a ChairAction 1378 message by sending a ChairActionAck message. The following is the 1379 format of the ChairActionAck message: 1381 ChairActionAck = (COMMON-HEADER) 1382 *[EXTENSION-ATTRIBUTE] 1384 Figure 36: ChairActionAck format 1386 5.3.11. Hello 1388 Floor participants and floor chairs check the liveness of floor 1389 control servers by sending a Hello message. The following is the 1390 format of the Hello message: 1392 Hello = (COMMON-HEADER) 1393 *[EXTENSION-ATTRIBUTE] 1395 Figure 37: Hello format 1397 5.3.12. HelloAck 1399 Floor control servers confirm that they are alive on reception of a 1400 Hello message by sending a HelloAck message. The following is the 1401 format of the HelloAck message: 1403 HelloAck = (COMMON-HEADER) 1404 (SUPPORTED-PRIMITIVES) 1405 (SUPPORTED-ATTRIBUTES) 1406 *[EXTENSION-ATTRIBUTE] 1408 Figure 38: HelloAck format 1410 5.3.13. Error 1412 Floor control servers inform floor participants and floor chairs 1413 about errors processing requests by sending them Error messages. The 1414 following is the format of the Error message: 1416 Error = (COMMON-HEADER) 1417 (ERROR-CODE) 1418 [ERROR-INFO] 1419 *[EXTENSION-ATTRIBUTE] 1421 Figure 39: Error format 1423 6. Transport 1425 BFCP entities exchange BFCP messages using TCP connections. TCP 1426 provides an in-order reliable delivery of a stream of bytes. 1427 Consequently, message framing is implemented in the application 1428 layer. BFCP implements application-layer framing using TLV-encoded 1429 attributes. 1431 A client MUST NOT use more than one TCP connection to communicate 1432 with a given floor control server within a conference. Nevertheless, 1433 if the same physical box handles different clients (e.g., a floor 1434 chair and a floor participant), which are identified by different 1435 User IDs, a separate connection per client is allowed. 1437 If a BFCP entity (a client or a floor control server) receives data 1438 from TCP that cannot be parsed the entity MUST close the TCP 1439 connection using a RESET call (send a TCP RST bit) and the connection 1440 SHOULD be reestablished. Similarly, if a TCP connection cannot 1441 deliver a BFCP message and times out, the TCP connection SHOULD be 1442 reestablished. 1444 The way connection reestablishment is handled depends on how the 1445 client obtains information to contact the floor control server (e.g., 1446 using an offer/answer exchange [7]). Once the TCP connection is 1447 reestablished, the client MAY resend those messages it did not get a 1448 response for from the floor control server. 1450 If a floor control server detects that the TCP connection towards one 1451 of the floor participants is lost, it is up to the local policy of 1452 the floor control server what to do with the pending floor requests 1453 of the floor participant. In any case, it is RECOMMENDED that the 1454 floor control server keeps the floor requests (i.e., does not cancel 1455 them) while the TCP connection is reestablished. 1457 If a client wishes to end its BFCP connection with a floor control 1458 server, the client closes (i.e., a graceful close) the TCP connection 1459 towards the floor control server. If a floor control server wishes 1460 to end its BFCP connection with a client (e.g., the Focus of the 1461 conference informs the floor control server that the client has been 1462 kicked out from the conference), the floor control server closes 1463 (i.e., a graceful close) the TCP connection towards the client. 1465 7. Lower-Layer Security 1467 BFCP relies on lower-layer security mechanisms to provide replay and 1468 integrity protection, and confidentiality. BFCP floor control 1469 servers and clients (which include both floor participants and floor 1470 chairs) MUST support TLS [3]. Any BFCP entity MAY support other 1471 security mechanisms. 1473 BFCP entities MUST support, at a minimum, the TLS 1474 TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5]. 1476 Which party, the client or the floor control server, acts as the TLS 1477 server depends on how the underlying TCP connection is established. 1478 For example, when the TCP connection is established using an offer/ 1479 answer exchange [7], the answerer (which may be the client or the 1480 floor control server) always acts as the TLS server. 1482 8. Protocol Transactions 1484 In BFCP, there are two types of transactions: client-initiated 1485 transactions and server-initiated transactions (notifications). 1486 Client-initiated transactions consist of a request from a client to a 1487 floor control server and a response from the floor control server to 1488 the client. The request carries a Transaction ID in its common 1489 header which the floor control server copies into the response. 1490 Clients use Transaction ID values to match responses with previously- 1491 issued requests. 1493 Server-initiated transactions consist of a single message from a 1494 floor control server to a client. Since they do not trigger any 1495 response, their Transaction ID is set to 0. 1497 8.1. Client Behavior 1499 A client starting a client-initiated transaction MUST set the 1500 Conference ID in the common header of the message to the Conference 1501 ID for the conference that the client obtained previously. 1503 The client MUST set the Transaction ID value in the common header to 1504 a number which is different to 0 and which MUST NOT be reused in 1505 another message from the client until a response from the server is 1506 received for the transaction. The client uses the Transaction ID 1507 value to match this message with the response from the floor control 1508 server. 1510 8.2. Server Behavior 1512 A floor control server sending a response within a client-initiated 1513 transaction MUST copy the Conference ID, the Transaction ID, and the 1514 User ID from the request received from the client into the response. 1515 Server-initiated transactions MUST contain a Transaction ID equal to 1516 0. 1518 9. Authentication and Authorization 1520 BFCP clients SHOULD authenticate the floor control server before 1521 sending any BFCP message to it or accepting any BFCP message from it. 1523 Similarly, floor control servers SHOULD authenticate a client before 1524 accepting any BFCP message from it or sending any BFCP message to it. 1526 BFCP supports TLS-based mutual authentication between clients and 1527 floor control servers, as specified in Section 9.1. This is the 1528 RECOMMENDED authentication mechanism in BFCP. 1530 Note that future extensions may define additional authentication 1531 mechanisms. 1533 In addition to authenticating BFCP messages, floor control servers 1534 need to authorize them. On receiving an authenticated BFCP message, 1535 the floor control server checks whether the client sending the 1536 message is authorized. If the client is not authorized to perform 1537 the operation being requested, the floor control server generates an 1538 Error message, as described in Section 13.8, with an Error code with 1539 a value of 5 (Unauthorized Operation). Messages from a client that 1540 cannot be authorized MUST NOT be processed further. 1542 9.1. TLS-based Mutual Authentication 1544 BFCP supports TLS-based mutual authentication between clients and 1545 floor control servers. BFCP assumes that there is an integrity- 1546 protected channel between the client and the floor control server 1547 that can be used to exchange their self-signed certificates or, more 1548 commonly, the fingerprints of these certificates. These certificates 1549 are used at TLS establishment time. 1551 The implementation of such an integrity-protected channel using 1552 SIP and the offer/answer model is described in [7]. 1554 BFCP messages received over an authenticated TLS connection are 1555 considered authenticated. A floor control server that receives a 1556 BFCP message over TCP (no TLS) can request the use of TLS by 1557 generating an Error message, as described in Section 13.8, with an 1558 Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore 1559 unauthenticated messages. 1561 Note that future extensions may define additional authentication 1562 mechanisms that may not require an initial integrity-protected 1563 channel (e.g., authentication based on certificates signed by a 1564 certificate authority). 1566 As described in Section 9, floor control servers need to perform 1567 authorization before processing any message. In particular, the 1568 floor control server SHOULD check that messages arriving over a given 1569 authenticated TLS connection use an authorized User ID (i.e., a User 1570 ID that the user that established the authenticated TLS connection is 1571 allowed to use). 1573 10. Floor Participant Operations 1575 This section specifies how floor participants can perform different 1576 operations, such as requesting a floor, using the protocol elements 1577 described in earlier sections. Section 11 specifies operations that 1578 are specific to floor chairs, such as instructing the floor control 1579 server to grant or revoke a floor, and Section 12 specifies 1580 operations that can be performed by any client (i.e., both floor 1581 participants and floor chairs). 1583 10.1. Requesting a Floor 1585 A floor participant that wishes to request one or more floors does so 1586 by sending a FloorRequest message to the floor control server. 1588 10.1.1. Sending a FloorRequest Message 1590 The ABNF in Section 5.3.1 describes the attributes that a 1591 FloorRequest message can contain. In addition, the ABNF specifies 1592 normatively which of these attributes are mandatory, and which ones 1593 are optional. 1595 The floor participant sets the Conference ID and the Transaction ID 1596 in the common header following the rules given in Section 8.1. 1598 The floor participant sets the User ID in the common header to the 1599 floor participant's identifier. This User ID will be used by the 1600 floor control server to authenticate and authorize the request. If 1601 the sender of the FloorRequest message (identified by the User ID) is 1602 not the participant that would eventually get the floor (i.e., a 1603 third party floor request), the sender SHOULD add a BENEFICIARY-ID 1604 attribute to the message identifying the beneficiary of the floor. 1606 Note that the name space for both the User ID and the Beneficiary 1607 ID is the same. That is, a given participant is identified by a 1608 single 16-bit value that can be used in the User ID in the common 1609 header and in several attributes: BENEFICIARY-ID, BENEFICIARY- 1610 INFORMATION, and REQUESTED-BY-INFORMATION. 1612 The floor participant must insert at least one FLOOR-ID attribute in 1613 the FloorRequest message. If the client inserts more than one 1614 FLOOR-ID attributes, the floor control server will treat all the 1615 floor requests as an atomic package. That is, the floor control 1616 server will either grant or deny all the floors in the FloorRequest 1617 message. 1619 The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute 1620 to state the reason why the floor or floors are being requested. The 1621 Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for 1622 human consumption. 1624 The floor participant may request the server to handle the floor 1625 request with a certain priority using a PRIORITY attribute. 1627 10.1.2. Receiving a Response 1629 A message from the floor control server is considered to be a 1630 response to the FloorRequest message if the message from the floor 1631 control server has the same Conference ID, Transaction ID, and User 1632 ID as the FloorRequest message, as described in Section 8.1. On 1633 receiving such a response, the floor participant follows the rules in 1634 Section 9 which relate to floor control server authentication. 1636 The successful processing of a FloorRequest message at the floor 1637 control server involves generating one or several FloorRequestStatus 1638 messages. The floor participant obtains a Floor Request ID in the 1639 Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in 1640 the first FloorRequestStatus message from the floor control server. 1641 Subsequent FloorRequestStatus messages from the floor control server 1642 regarding the same floor request will carry the same Floor Request ID 1643 in a FLOOR-REQUEST-INFORMATION attribute as the initial 1644 FloorRequestStatus message. This way, the floor participant can 1645 associate subsequent incoming FloorRequestStatus messages with the 1646 ongoing floor request. 1648 The floor participant obtains information about the status of the 1649 floor request in the FLOOR-REQUEST-INFORMATION attribute of each of 1650 the FloorRequestStatus messages received from the floor control 1651 server. This attribute is a grouped attribute and, as such, it 1652 includes a number of attributes that provide information about the 1653 floor request. 1655 The REQUEST-STATUS attribute. If the Request Status value is 1656 Granted, all the floors that were requested in the FloorRequest 1657 message have been granted. If the Request Status value is Denied, 1658 all the floors that were requested in the FloorRequest message have 1659 been denied. A floor request is considered to be ongoing while it is 1660 in the Pending, Accepted, or Granted states. 1662 The STATUS-INFO attribute, if present, provides extra information 1663 which the floor participant MAY display to the user. 1665 The BENEFICIARY-INFORMATION attribute identifies the beneficiary of 1666 the floor request in third-party floor requests. The REQUESTED-BY- 1667 INFORMATION attribute may be not be present in FloorRequestStatus 1668 messages received by the floor participant that requested the floor 1669 because this floor participant is already identified by the User ID 1670 in the common header. 1672 The PRIORITY attribute, when present, contains the priority that was 1673 requested by the generator of the FloorRequest message. 1675 If the response is an Error message, the floor control server could 1676 not process the FloorRequest message for some reason, which is 1677 described in the Error message. 1679 10.2. Cancelling a Floor Request and Releasing a Floor 1681 A floor participant that wishes to cancel an ongoing floor request 1682 does so by sending a FloorRelease message to the floor control 1683 server. The FloorRelease message is also used by floor participants 1684 that hold a floor and would like to release it. 1686 10.2.1. Sending a FloorRelease Message 1688 The ABNF in Section 5.3.2 describes the attributes that a 1689 FloorRelease message can contain. In addition, the ABNF specifies 1690 normatively which of these attributes are mandatory, and which ones 1691 are optional. 1693 The floor participant sets the Conference ID and the Transaction ID 1694 in the common header following the rules given in Section 8.1. The 1695 floor participant sets the User ID in the common header to the floor 1696 participant's identifier. This User ID will be used by the floor 1697 control server to authenticate and authorize the request. 1699 Note that the FloorRelease message is used to release a floor or 1700 floors that were granted and to cancel ongoing floor requests 1701 (from the protocol perspective both are ongoing floor requests). 1702 Using the same message in both situations helps resolve the race 1703 condition that occurs when the FloorRelease message and the 1704 FloorGrant message cross each other on the wire. 1706 The floor participant uses the FLOOR-REQUEST-ID that was received in 1707 the response to the FloorRequest message that the FloorRelease 1708 message is cancelling. 1710 Note that if the floor participant requested several floors as an 1711 atomic operation (i.e., in a single FloorRequest message), all the 1712 floors are released as an atomic operation as well (i.e., all are 1713 released at the same time). 1715 10.2.2. Receiving a Response 1717 A message from the floor control server is considered to be a 1718 response to the FloorRelease message if the message from the floor 1719 control server has the same Conference ID, Transaction ID, and User 1720 ID as the FloorRequest message, as described in Section 8.1. On 1721 receiving such a response, the floor participant follows the rules in 1722 Section 9 which relate to floor control server authentication. 1724 If the response is a FloorRequestStatus message, the Request Status 1725 value in the REQUEST-STATUS attribute (within the FLOOR-REQUEST- 1726 INFORMATION grouped attribute) will be Cancelled or Released. 1728 If the response is an Error message, the floor control server could 1729 not process the FloorRequest message for some reason, which is 1730 described in the Error message. 1732 It is possible that the FloorRelease message crosses on the wire with 1733 a FloorRequestStatus message from the server with a Request Status 1734 different from Cancelled or Released. In any case, such a 1735 FloorRequestStatus message will not be a response to the FloorRelease 1736 message, because its Transaction ID will not match that of the 1737 FloorRelease. 1739 11. Chair Operations 1741 This section specifies how floor chairs can instruct the floor 1742 control server to grant or revoke a floor using the protocol elements 1743 described in earlier sections. 1745 Floor chairs that wish to send instructions to a floor control server 1746 do so by sending a ChairAction message. 1748 11.1. Sending a ChairAction Message 1750 The ABNF in Section 5.3.9 describes the attributes that a ChairAction 1751 message can contain. In addition, the ABNF specifies normatively 1752 which of these attributes are mandatory, and which ones are optional. 1754 The floor chair sets the Conference ID and the Transaction ID in the 1755 common header following the rules given in Section 8.1. The floor 1756 participant sets the User ID in the common header to the floor 1757 participant's identifier. This User ID will be used by the floor 1758 control server to authenticate and authorize the request. 1760 The ChairAction message contains instructions that apply to one or 1761 more floors within a particular floor request. The floor or floors 1762 are identified by FLOOR-ID attributes and the floor request is 1763 identified by a FLOOR-REQUEST-ID attribute, which are carried in the 1764 ChairAction message. 1766 For example, if a floor request consists of two floors that depend 1767 on different floor chairs, each floor chair will grant its floor 1768 within the floor request. Once both chairs have granted their 1769 floor, the floor control server will grant the floor request as a 1770 whole. On the other hand, if one of the floor chairs denies its 1771 floor, the floor control server will deny the floor request as a 1772 whole, regardless of the other floor chair's decision. 1774 The floor chair provides the new status for one or more floors within 1775 the floor request using a REQUEST-STATUS attribute. If the new 1776 status of the floor request is Accepted, the floor chair MAY use the 1777 Queue Position field to provide a queue position for the floor 1778 request. If the floor chair does not wish to provide a queue 1779 position, all the bits of the Queue Position field SHOULD be set to 1780 zero. The floor chair SHOULD use the Status Revoked to revoke a 1781 floor that was granted (i.e., Granted status) and the Status Denied 1782 to reject floor requests in any other status (e.g., Pending and 1783 Accepted). 1785 Note that a floor request may involve several floors and that a 1786 ChairAction message may only deal with a subset of these floors 1787 (e.g., if a single floor chair is not authorized to manage all the 1788 floors). In this case, the REQUEST-STATUS that the floor chair 1789 provides in the ChairAction message might not be the actual status 1790 that the floor request gets at the server. The floor control 1791 server will combine the instructions received from the different 1792 floor chairs to come up with the actual status of the floor 1793 request. 1795 The floor chair may use a STATUS-INFO attribute to state the reason 1796 why the floor or floors are being accepted, granted, or revoked. The 1797 Text in the STATUS-INFO attribute is intended for human consumption. 1799 11.2. Receiving a Response 1801 A message from the floor control server is considered to be a 1802 response to the ChairAction message if the message from the server 1803 has the same Conference ID, Transaction ID, and User ID as the 1804 ChairAction message, as described in Section 8.1. On receiving such 1805 a response, the floor chair follows the rules in Section 9 which 1806 relate to floor control server authentication. 1808 A ChairActionAck message from the floor control server confirms that 1809 the floor control server has accepted the ChairAction message. An 1810 Error message indicates that the floor control server could not 1811 process the ChairAction message for some reason, which is described 1812 in the Error message. 1814 12. General Client Operations 1816 This section specifies operations that can be performed by any 1817 client. That is, they are not specific to floor participants or 1818 floor chairs. They can be performed by both. 1820 12.1. Requesting Information about Floors 1822 A client can obtain information about the status of a floor or floors 1823 in different ways, which include using BFCP and using out-of-band 1824 mechanisms. Clients using BFCP to obtain such information use the 1825 procedures described in this section. 1827 Clients request information about the status of one or several floors 1828 by sending a FloorQuery message to the floor control server. 1830 12.1.1. Sending a FloorQuery Message 1832 The ABNF in Section 5.3.7 describes the attributes that a FloorQuery 1833 message can contain. In addition, the ABNF specifies normatively 1834 which of these attributes are mandatory, and which ones are optional. 1836 The client sets the Conference ID and the Transaction ID in the 1837 common header following the rules given in Section 8.1. The client 1838 sets the User ID in the common header to the client's identifier. 1839 This User ID will be used by the floor control server to authenticate 1840 and authorize the request. 1842 The client inserts in the message all the Floor IDs it wants to 1843 receive information about. The floor control server will send 1844 periodic information about all these floors. If the client does not 1845 want to receive information about a particular floor any longer, it 1846 sends a new FloorQuery message removing the FLOOR-ID of this floor. 1847 If the client does not want to receive information about any floor 1848 any longer, it sends a FloorQuery message with no FLOOR-ID attribute. 1850 12.1.2. Receiving a Response 1852 A message from the floor control server is considered to be a 1853 response to the FloorQuery message if the message from the floor 1854 control server has the same Conference ID, Transaction ID, and User 1855 ID as the FloorRequest message, as described in Section 8.1. On 1856 receiving such a response, the client follows the rules in Section 9 1857 which relate to floor control server authentication. 1859 On reception of the FloorQuery message, the floor control server will 1860 respond with a FloorStatus message or with an Error message. If the 1861 response is a FloorStatus message, it will contain information about 1862 one of the floors the client requested information about. If the 1863 client did not include any FLOOR-ID attribute in its FloorQuery 1864 message (i.e., the client does not want to receive information about 1865 any floor any longer), the FloorStatus message from the floor control 1866 server will not include any FLOOR-ID attribute either. 1868 FloorStatus messages which carry information about a floor contain a 1869 FLOOR-ID attribute that identifies the floor. After this attribute, 1870 FloorStatus messages contain information about existing (one or more) 1871 floor request that relate to that floor. The information about each 1872 particular floor request is encoded in a FLOOR-REQUEST-INFORMATION 1873 attribute. This grouped attribute carries a Floor Request ID that 1874 identifies the floor request followed by a set of attributes that 1875 provide information about the floor request. 1877 After the first FloorStatus, the floor control server will continue 1878 sending FloorStatus messages periodically informing the client about 1879 changes on the floors the client requested information about. 1881 12.2. Requesting Information about Floor Requests 1883 A client can obtain information about the status of one or several 1884 floor requests in different ways, which include using BFCP and using 1885 out-of-band mechanisms. Clients using BFCP to obtain such 1886 information use the procedures described in this section. 1888 Clients request information about the current status of a floor 1889 requests by sending a FloorRequestQuery message to the floor control 1890 server. 1892 Requesting information about a particular floor request is useful in 1893 a number of situations. For example, on reception of a FloorRequest 1894 message, a floor control server may choose to return 1895 FloorRequestStatus messages only when the floor request changes its 1896 state (e.g., from Accepted to Granted), but not when the floor 1897 request advances in its queue. In this situation, if the user 1898 requests it, the floor participant can use a FloorRequestQuery 1899 message to poll the floor control server for the status of the floor 1900 request. 1902 12.2.1. Sending a FloorRequestQuery Message 1904 The ABNF in Section 5.3.3 describes the attributes that a 1905 FloorRequestQuery message can contain. In addition, the ABNF 1906 specifies normatively which of these attributes are mandatory, and 1907 which ones are optional. 1909 The client sets the Conference ID and the Transaction ID in the 1910 common header following the rules given in Section 8.1. The client 1911 sets the User ID in the common header to the client's identifier. 1912 This User ID will be used by the floor control server to authenticate 1913 and authorize the request. 1915 The client must insert a FLOOR-REQUEST-ID attribute that identifies 1916 the floor request at the floor control server. 1918 12.2.2. Receiving a Response 1920 A message from the floor control server is considered to be a 1921 response to the FloorRequestQuery message if the message from the 1922 floor control server has the same Conference ID, Transaction ID, and 1923 User ID as the FloorRequestQuery message, as described in 1924 Section 8.1. On receiving such a response, the client follows the 1925 rules in Section 9 which relate to floor control server 1926 authentication. 1928 If the response is a FloorRequestStatus message, the client obtains 1929 information about the status of the FloorRequest the client requested 1930 information about in a FLOOR-REQUEST-INFORMATION attribute. 1932 If the response is an Error message, the floor control server could 1933 not process the FloorRequestQuery message for some reason, which is 1934 described in the Error message. 1936 12.3. Requesting Information about a User 1938 A client can obtain information about a participant and the floor 1939 requests related to this participant in different ways, which include 1940 using BFCP and using out-of-band mechanisms. Clients using BFCP to 1941 obtain such information use the procedures described in this section. 1943 Clients request information about a participant and the floor 1944 requests related to this participant by sending a UserQuery message 1945 to the floor control server. 1947 This functionality may be useful for floor chairs or floor 1948 participants interested in the display name and the URI of a 1949 particular floor participant. In addition, a floor participant may 1950 find it useful to request information about itself. For example, a 1951 floor participant, after experiencing connectivity problems (e.g., 1952 its TCP connection with the floor control server was down for a while 1953 and eventually was re-established), may need to request information 1954 about all the still existing floor requests associated to itself. 1956 12.3.1. Sending a UserQuery Message 1958 The ABNF in Section 5.3.5 describes the attributes that a UserQuery 1959 message can contain. In addition, the ABNF specifies normatively 1960 which of these attributes are mandatory, and which ones are optional. 1962 The client sets the Conference ID and the Transaction ID in the 1963 common header following the rules given in Section 8.1. The client 1964 sets the User ID in the common header to the client's identifier. 1965 This User ID will be used by the floor control server to authenticate 1966 and authorize the request. 1968 If the floor participant the client is requesting information about 1969 is not the client issuing the UserQuery message (which is identified 1970 by the User ID in the common header of the message) the client MUST 1971 insert a BENEFICIARY-ID attribute. 1973 12.3.2. Receiving a Response 1975 A message from the floor control server is considered to be a 1976 response to the UserQuery message if the message from the floor 1977 control server has the same Conference ID, Transaction ID, and User 1978 ID as the UserQuery message, as described in Section 8.1. On 1979 receiving such a response, the client follows the rules in Section 9 1980 which relate to floor control server authentication. 1982 If the response is a UserStatus message, the client obtains 1983 information about the floor participant in a BENEFICIARY-INFORMATION 1984 grouped attribute and about the status of the floor requests 1985 associated with the floor participant in FLOOR-REQUEST-INFORMATION 1986 attributes. 1988 If the response is an Error message, the floor control server could 1989 not process the UserQuery message for some reason, which is described 1990 in the Error message. 1992 12.4. Obtaining the Capabilities of a Floor Control Server 1994 A client that wishes to obtain the capabilities of a floor control 1995 server does so by sending a Hello message to the floor control 1996 server. 1998 12.4.1. Sending a Hello Message 2000 The ABNF in Section 5.3.11 describes the attributes that a Hello 2001 message can contain. In addition, the ABNF specifies normatively 2002 which of these attributes are mandatory, and which ones are optional. 2004 The client sets the Conference ID and the Transaction ID in the 2005 common header following the rules given in Section 8.1. The client 2006 sets the User ID in the common header to the client's identifier. 2007 This User ID will be used by the floor control server to authenticate 2008 and authorize the request. 2010 12.4.2. Receiving Responses 2012 A message from the floor control server is considered a response to 2013 the Hello message by the client if the message from the floor control 2014 server has the same Conference ID, Transaction ID, and User ID as the 2015 Hello message, as described in Section 8.1. On receiving such a 2016 response, the client follows the rules in Section 9 which relate to 2017 floor control server authentication. 2019 If the response is a HelloAck message, the floor control server could 2020 process successfully the Hello message. The SUPPORTED-ATTRIBUTES 2021 attribute indicates which attributes are supported by the server. 2023 If the response is an Error message, the floor control server could 2024 not process the Hello message for some reason, which is described in 2025 the Error message. 2027 13. Floor Control Server Operations 2029 This section specifies how floor control servers can perform 2030 different operations, such as granting a floor, using the protocol 2031 elements described in earlier sections. 2033 On reception of a message from a client, the floor control server 2034 MUST check whether or not the value of the Conference ID matched an 2035 existing conference. If it does not, the floor control server SHOULD 2036 send an Error message, as described in Section 13.8, with Error code 2037 1 (Conference does not Exist). 2039 On reception of a message from a client, the floor control server 2040 follows the rules in Section 9, which relate to the authentication of 2041 the message. 2043 On reception of a message from a client, the floor control server 2044 MUST check whether or not it understands all the mandatory ( 'M' bit 2045 set) attributes in the message. If the floor control server does not 2046 understand all of them, the floor control server SHOULD send an Error 2047 message, as described in Section 13.8, with Error code 2 2048 (Authentication Failed). The Error message SHOULD list the 2049 attributes that were not understood. 2051 13.1. Reception of a FloorRequest Message 2053 On reception of a FloorRequest message, the floor control server 2054 follows the rules in Section 9 which relate to client authentication 2055 and authorization. If while processing the FloorRequest message, the 2056 floor control server encounters an error, it SHOULD generate an Error 2057 response following the procedures described in Section 13.8 2059 BFCP allows floor participants to have several ongoing floor 2060 requests for the same floor (e.g., the same floor participant can 2061 occupy more than one position in a queue at the same time). A 2062 floor control server that only supports a certain number of 2063 ongoing floor requests per floor participant (e.g., one) can use 2064 Error Code 8 (You have Already Reached the Maximum Number of 2065 Ongoing Floor Requests for this Floor) to inform the floor 2066 participant. 2068 13.1.1. Generating the First FloorRequestStatus Message 2070 The successful processing of a FloorRequest message by a floor 2071 control server involves generating one or several FloorRequestStatus 2072 messages, the first of which SHOULD be generated as soon as possible. 2073 If the floor control server cannot accept, grant, or deny the floor 2074 request right away (e.g., a decision from a chair is needed), it 2075 SHOULD use a Request Status value of Pending in the REQUEST-STATUS 2076 attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of 2077 the first FloorRequestStatus message it generates. 2079 The policy a floor control server follows to grant or deny floors 2080 is outside the scope of this document. A given floor control 2081 server may perform these decisions automatically while another may 2082 contact a human acting as a chair everytime a decision needs to be 2083 made. 2085 The floor control server MUST copy the Conference ID, the Transaction 2086 ID, and the User ID from the FloorRequest into the 2087 FloorRequestStatus, as described in Section 8.2. Additionally, the 2088 floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2089 attribute to the FloorRequestStatus. The attributes contained in 2090 this grouped attribute carry information about the floor request. 2092 The floor control server MUST assign an identitifier that is unique 2093 within the conference to this floor request, and MUST insert it in 2094 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2095 attribute. This identifier will be used by the floor participant (or 2096 by a chair or chairs) to refer to this specific floor request in the 2097 future. 2099 The floor control server MUST copy the FLOOR-ID attributes from the 2100 FloorRequest into the FLOOR-REQUEST-INFORMATION attribute. These 2101 FLOOR-ID attributes identify the floors being requested (i.e., the 2102 floors associated with this particular floor request). 2104 The floor control server SHOULD copy (if present) the contents of the 2105 BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY- 2106 INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped 2107 attribute. Additionally, the floor control server MAY provide the 2108 display name and the URI of the beneficiary in this BENEFICIARY- 2109 INFORMATION attribute. 2111 The floor control server MAY provide information about the requester 2112 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2113 FLOOR-REQUEST-INFORMATION grouped attribute. 2115 The floor control server MAY copy (if present) the PRIORITY attribute 2116 from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped 2117 attribute. Note that this attribute carries the priority requested 2118 by the participant. The priority the floor control server assigns to 2119 the floor request depends on the priority requested by the 2120 participant and the rights the participant has according to the 2121 policy of the conference. For example, a participant that is only 2122 allowed to use the Normal priority may request Highest priority for a 2123 floor request. In that case, the floor control server would ignore 2124 the priority requested by the participant. 2126 The floor control server MAY copy (if present) the PARTICIPANT- 2127 PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST- 2128 INFO grouped attribute. 2130 13.1.2. Generation of Subsequent FloorRequestStatus Messages 2132 A floor request is considered to be ongoing as long as it is not in 2133 the Cancelled, Released, or Revoked states. If the REQUEST-STATUS 2134 attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of 2135 the first FloorRequestStatus message generated by the floor control 2136 server did not indicate any of these states, the floor control server 2137 will need to send subsequent FloorRequestStatus messages. 2139 When the status of the floor request changes, the floor control 2140 server SHOULD send new FloorRequestStatus messages with the 2141 appropriate Request Status. The floor control server MUST add a 2142 FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to 2143 the one sent in the first FloorRequestStatus message to any new 2144 FloorRequestStatus related to the same floor request. (The Floor 2145 Request ID identifies the floor request the FloorRequestStatus 2146 applies to.) 2148 The floor control server MUST set the Transaction ID of subsequent 2149 FloorRequestStatus messages to 0. 2151 The rate at which the floor control server sends 2152 FloorRequestStatus messages is a matter of local policy. A floor 2153 control server may choose to send a new FloorRequestStatus message 2154 every time the floor request moves in the floor request queue 2155 while another may choose to only send a new FloorRequestStatus 2156 message when the floor request is Granted or Denied. 2158 The floor control server may add a STATUS-INFO attribute to any of 2159 the FloorRequestStatus messages it generates to provide extra 2160 information about its decisions regarding the floor request (e.g., 2161 why it was denied). 2163 Floor participants and floor chairs may request to be informed 2164 about the status of a floor following the procedures in 2165 Section 12.1. If the processing of a floor request changes the 2166 status of a floor (e.g., the floor request is granted and 2167 consequently the floor has a new holder), the floor control server 2168 needs to follow the procedures in Section 13.5 to inform the 2169 clients that have requested that information 2171 The common header and the rest of the attributes are the same as in 2172 the first FloorRequestStatus message. 2174 The floor control server can discard the state information about a 2175 particular floor request when this reaches a status of Cancelled, 2176 Released, or Revoked. 2178 13.2. Reception of a FloorRequestQuery Message 2180 On reception of a FloorRequestQuery message, the floor control server 2181 follows the rules in Section 9 which relate to client authentication 2182 and authorization. If while processing the FloorRequestQuery 2183 message, the floor control server encounters an error, it SHOULD 2184 generate an Error response following the procedures described in 2185 Section 13.8 2187 The successful processing of a FloorRequestQuery message by a floor 2188 control server involves generating a FloorRequestStatus message, 2189 which SHOULD be generated as soon as possible. 2191 The floor control server MUST copy the Conference ID, the Transaction 2192 ID, and the User ID from the FloorRequestQuery message into the 2193 FloorRequestStatus message, as described in Section 8.2. 2194 Additionally, the floor control server MUST add a FLOOR-REQUEST- 2195 INFORMATION grouped attribute to the FloorRequestStatus. The 2196 attributes contained in this grouped attribute carry information 2197 about the floor request. 2199 The floor control server MUST copy the contents of the 2200 FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into 2201 the Floor Request ID field of the FLOOR-REQUEST-INFORMATION 2202 attribute. 2204 The floor control server MUST add FLOOR-ID attributes to the FLOOR- 2205 REQUEST-INFORMATION grouped attribute identifying the floors being 2206 requested (i.e., the floors associated with the floor request 2207 identified by the FLOOR-REQUEST-ID attribute). 2209 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2210 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2211 beneficiary of the floor request. Additionally, the floor control 2212 server MAY provide the display name and the URI of the beneficiary in 2213 this BENEFICIARY-INFORMATION attribute. 2215 The floor control server MAY provide information about the requester 2216 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2217 FLOOR-REQUEST-INFORMATION grouped attribute. 2219 The floor control server MAY provide the reason why the floor 2220 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2222 The floor control server MAY also add to the FLOOR-REQUEST- 2223 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2224 value requested for the floor request and a STATUS-INFO attribute 2225 with extra information about the floor request. 2227 The floor control server adds a REQUEST-STATUS attribute to the 2228 FLOOR-REQUEST-INFORMATION grouped attribute with the current status 2229 of the floor request. 2231 13.3. Reception of a UserQuery Message 2233 On reception of a UserQuery message, the floor control server follows 2234 the rules in Section 9 which relate to client authentication and 2235 authorization. If while processing the UserQuery message, the floor 2236 control server encounters an error, it SHOULD generate an Error 2237 response following the procedures described in Section 13.8 2239 The successful processing of a UserQuery message by a floor control 2240 server involves generating a UserStatus message, which SHOULD be 2241 generated as soon as possible. 2243 The floor control server MUST copy the Conference ID, the Transaction 2244 ID, and the User ID from the UserQuery message into the USerStatus 2245 message, as described in Section 8.2. 2247 The sender of the UserQuery message is requesting information about 2248 all the floor requests associated to a given participant (i.e., the 2249 floor requests where the participant is either the beneficiary or the 2250 requester). This participant is identified by a BENEFICIARY-ID 2251 attribute or, in the absence of a BENEFICIARY-ID attribute, by a the 2252 User ID in the common header of the UserQuery message. 2254 The floor control server MUST copy, if present, the contents of the 2255 BENEFICIARY-ID attribute from the UserQuery message into a 2256 BENEFICIARY-INFORMATION attribute in the UserStatus message. 2257 Additionally, the floor control server MAY provide the display name 2258 and the URI of the participant the UserStatus message provides 2259 information on in this BENEFICIARY-INFORMATION attribute. 2261 The floor control server SHOULD add to the UserStatus message a 2262 FLOOR-REQUEST-INFORMATION grouped attribute for each floor request 2263 related to the participant the message provides information on (i.e., 2264 the floor requests where the participant is either the beneficiary or 2265 the requester). For each FLOOR-REQUEST-INFORMATION attribute, the 2266 floor control server follows the following steps. 2268 The floor control server MUST identity the floor request the FLOOR- 2269 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2270 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2272 The floor control server MUST add FLOOR-ID attributes to the FLOOR- 2273 REQUEST-INFORMATION grouped attribute identifying the floors being 2274 requested (i.e., the floors associated with the floor request 2275 identified by the FLOOR-REQUEST-ID attribute). 2277 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2278 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2279 beneficiary of the floor request. Additionally, the floor control 2280 server MAY provide the display name and the URI of the beneficiary in 2281 this BENEFICIARY-INFORMATION attribute. 2283 The floor control server MAY provide information about the requester 2284 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2285 FLOOR-REQUEST-INFORMATION grouped attribute. 2287 The floor control server MAY provide the reason why the floor 2288 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2290 The floor control server MAY also add to the FLOOR-REQUEST- 2291 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2292 value requested for the floor request and a STATUS-INFO attribute 2293 with extra information about the floor request. 2295 The floor control server MUST add a REQUEST-STATUS attribute to the 2296 FLOOR-REQUEST-INFORMATION grouped attribute with the current status 2297 of the floor request. 2299 13.4. Reception of a FloorRelease Message 2301 On reception of a FloorRelease message, the floor control server 2302 follows the rules in Section 9 which relate to client authentication 2303 and authorization. If while processing the FloorRelease message, the 2304 floor control server encounters an error, it SHOULD generate an Error 2305 response following the procedures described in Section 13.8 2307 The successful processing of a FloorRelease message by a floor 2308 control server involves generating a FloorRequestStatus message, 2309 which SHOULD be generated as soon as possible. 2311 The floor control server MUST copy the Conference ID, the Transaction 2312 ID, and the User ID from the FloorRelease message into the 2313 FloorRequestStatus message, as described in Section 8.2. 2315 The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped 2316 attribute to the FloorRequestStatus. The attributes contained in 2317 this grouped attribute carry information about the floor request. 2319 The FloorRelease message identifies the floor request it applies to 2320 using a FLOOR-REQUEST-ID. The floor control server MUST copy the 2321 contents of the FLOOR-REQUEST-ID attribute from the FloorRelease 2322 message into the Floor Request ID field of the FLOOR-REQUEST- 2323 INFORMATION attribute. 2325 The floor control server MUST add FLOOR-ID attributes to the FLOOR- 2326 REQUEST-INFORMATION grouped attribute identifying the floors being 2327 requested (i.e., the floors associated with the floor request 2328 identified by the FLOOR-REQUEST-ID attribute). 2330 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2331 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2332 beneficiary of the floor request. Additionally, the floor control 2333 server MAY provide the display name and the URI of the beneficiary in 2334 this BENEFICIARY-INFORMATION attribute. 2336 The floor control server MAY provide information about the requester 2337 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2338 FLOOR-REQUEST-INFORMATION grouped attribute. 2340 The floor control server MAY provide the reason why the floor 2341 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2343 The floor control server MAY also add to the FLOOR-REQUEST- 2344 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2345 value requested for the floor request and a STATUS-INFO attribute 2346 with extra information about the floor request. 2348 The floor control server MUST add a REQUEST-STATUS attribute to the 2349 FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status 2350 value SHOULD be Released, if the floor (or floors) had been 2351 previously granted, or Cancelled, if the floor (or floors) had not 2352 been previously granted. 2354 13.5. Reception of a FloorQuery Message 2356 On reception of a FloorQuery message, the floor control server 2357 follows the rules in Section 9 which relate to client authentication. 2358 If while processing the FloorRelease message, the floor control 2359 server encounters an error, it SHOULD generate an Error response 2360 following the procedures described in Section 13.8 2362 A floor control server receiving a FloorQuery message from a client 2363 SHOULD keep this client informed about the status of the floors 2364 identified by FLOOR-ID attributes in the FloorQuery message. Floor 2365 Control Servers keep clients informed by using FloorStatus messages. 2367 An individual FloorStatus message carries information about a single 2368 floor. So, when a FloorQuery message requests information about more 2369 than one floor, the floor control server needs to send separate 2370 FloorStatus messages for different floors. 2372 The information FloorQuery messages carry may depend on the user 2373 requesting the information. For example, a chair may be able to 2374 receive information about pending requests while a regular user may 2375 not be authorized to do so. 2377 13.5.1. Generation of the First FloorStatus Message 2379 The successful processing of a FloorQuery message by a floor control 2380 server involves generating one or several FloorStatus messages, the 2381 first of which SHOULD be generated as soon as possible. 2383 The floor control server MUST copy the Conference ID, the Transaction 2384 ID, and the User ID from the FloorQuery message into the FloorStatus 2385 message, as described in Section 8.2. 2387 If the FloorQuery message did not contain any FLOOR-ID attribute, the 2388 floor control server sends the FloorStatus message without adding any 2389 additional attribute and does not send any subsequent FloorStatus 2390 message to the floor participant. 2392 If the FloorQuery message contained one or more FLOOR-ID attributes, 2393 the floor control server chooses one among them and adds this 2394 FLOOR-ID attribute to the FloorStatus message. The floor control 2395 server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for 2396 each floor request associated to the floor. Each FLOOR-REQUEST- 2397 INFORMATION grouped attribute contains a number of attributes which 2398 provide information about the floor request. For each FLOOR-REQUEST- 2399 INFORMATION attribute, the floor control server follows the following 2400 steps. 2402 The floor control server MUST identity the floor request the FLOOR- 2403 REQUEST-INFORMATION attribute applies to by filling the Floor Request 2404 ID field of the FLOOR-REQUEST-INFORMATION attribute. 2406 The floor control server MUST add FLOOR-ID attributes to the FLOOR- 2407 REQUEST-INFORMATION grouped attribute identifying the floors being 2408 requested (i.e., the floors associated with the floor request 2409 identified by the FLOOR-REQUEST-ID attribute). 2411 The floor control server SHOULD add a BENEFICIARY-ID attribute to the 2412 FLOOR-REQUEST-INFORMATION grouped attribute identifying the 2413 beneficiary of the floor request. Additionally, the floor control 2414 server MAY provide the display name and the URI of the beneficiary in 2415 this BENEFICIARY-INFORMATION attribute. 2417 The floor control server MAY provide information about the requester 2418 of the floor in a REQUESTED-BY-INFORMATION attribute inside the 2419 FLOOR-REQUEST-INFORMATION grouped attribute. 2421 The floor control server MAY provide the reason why the floor 2422 participant requested the floor in a PARTICIPANT-PROVIDED-INFO. 2424 The floor control server MAY also add to the FLOOR-REQUEST- 2425 INFORMATION grouped attribute a PRIORITY attribute with the Priority 2426 value requested for the floor request and a STATUS-INFO attribute 2427 with extra information about the floor request. 2429 The floor control server MUST add a REQUEST-STATUS attribute to the 2430 FLOOR-REQUEST-INFORMATION grouped attribute with the current status 2431 of the floor request. 2433 13.5.2. Generation of Subsequent FloorStatus Messages 2435 If the FloorQuery message carried more than one FLOOR-ID attribute, 2436 the floor control server SHOULD generate a FloorStatus message for 2437 each of them (except for the FLOOR-ID attribute chosen for the first 2438 FloorStatus message) as soon as possible. These FloorStatus messages 2439 are generated following the same rules as for the first FloorStatus 2440 message (see Section 13.5.1, but their Transaction ID is 0. 2442 After generating these messages, the floor control server sends 2443 FloorStatus messages periodically keeping the client informed about 2444 all the floors the client requested information about. The 2445 Transaction ID of these messages MUST be 0. 2447 The rate at which the floor control server sends FloorStatus 2448 messages is a matter of local policy. A floor control server may 2449 choose to send a new FloorStatus message every time a new floor 2450 request arrives while another may choose to only send a new 2451 FloorStatus message when a new floor request is Granted. 2453 13.6. Reception of a ChairAction Message 2455 On reception of a ChairAction message, the floor control server 2456 follows the rules in Section 9 which relate to client authentication 2457 and authorization. If while processing the ChairAction message, the 2458 floor control server encounters an error, it SHOULD generate an Error 2459 response following the procedures described in Section 13.8 2461 The successful processing of a ChairAction message by a floor control 2462 server involves generating a ChairActionAck message, which SHOULD be 2463 generated as soon as possible. 2465 The floor control server MUST copy the Conference ID, the Transaction 2466 ID, and the User ID from the ChairAction message into the 2467 ChairActionAck message, as described in Section 8.2. 2469 The floor control server needs to take into consideration the 2470 operation requested in the ChairAction message (e.g., granting a 2471 floor), but does not necessarily need to perform it as requested by 2472 the floor chair. The operation that the floor control server 2473 performs depends on the ChairAction message and on the internal state 2474 of the floor control server. 2476 For example, a floor chair may send a ChairAction message granting a 2477 floor which was requested as part of an atomic floor request 2478 operation that involved several floors. Even if the chair 2479 responsible for one of the floors instructs the floor control server 2480 to grant the floor, the floor control server will not grant it until 2481 the chairs responsible for the other floors agree to grant them as 2482 well. 2484 So, the floor control server is ultimately responsible to keep a 2485 coherent floor state using instructions from floor chairs as input to 2486 this state. 2488 If the new Status in the ChairAction message is Accepted and all the 2489 bits of the Queue Position field are zero, the floor chair is 2490 requesting the floor control server to assign a queue position (e.g., 2491 the last in the queue) to the floor request based on the local policy 2492 of the floor control server. (Of course, such a request only applies 2493 in case the floor control server implements a queue.) 2495 13.7. Reception of a Hello Message 2497 On reception of a Hello message, the floor control server follows the 2498 rules in Section 9 which relate to client authentication. If while 2499 processing the Hello message, the floor control server encounters an 2500 error, it SHOULD generate an Error response following the procedures 2501 described in Section 13.8 2503 The successful processing of a Hello message by a floor control 2504 server involves generating a HelloAck message, which SHOULD be 2505 generated as soon as possible. The floor control server MUST copy 2506 the Conference ID, the Transaction ID, and the User ID from the Hello 2507 into the HelloAck, as described in Section 8.2. 2509 The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to 2510 the HelloAck message listing all the primitives (i.e., BFCP messages) 2511 supported by the floor control server. 2513 The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to 2514 the HelloAck message listing all the attributes supported by the 2515 floor control server. 2517 13.8. Error Message Generation 2519 Error messages are always sent in response to a previous message from 2520 the client as part of a client-initiated transaction. The ABNF in 2521 Section 5.3.13 describes the attributes that an Error message can 2522 contain. In addition, the ABNF specifies normatively which of these 2523 attributes are mandatory, and which ones are optional. 2525 The floor control server MUST copy the Conference ID, the Transaction 2526 ID, and the User ID from the message from the client into the Error 2527 message, as described in Section 8.2. 2529 The floor control server MUST add an ERROR-CODE attribute to the 2530 Error message. The ERROR-CODE attribute contains an Error Code from 2531 Table 5. Additionally, the floor control server may add a ERROR-INFO 2532 attribute with extra information about the error. 2534 14. Security Considerations 2536 BFCP uses TLS to provide mutual authentication between clients and 2537 servers. TLS also provides replay and integrity protection, and 2538 confidentiality. It is RECOMMENDED that TLS with non-null encryption 2539 is always used. BFCP entities MAY use other security mechanisms as 2540 long as they provide similar security properties. 2542 The remainder of this Section analyzes some of the threats against 2543 BFCP and how they are addressed. 2545 An attacker may attempt to impersonate a client (a floor participant 2546 or a floor chair) in order to generate forged floor requests or to 2547 grant or deny existing floor requests. Client impersonation is 2548 avoided by having servers only accept BFCP messages over 2549 authenticated TLS connections. The floor control server assumes that 2550 attackers cannot hickjack the TLS connection and, therefore, that 2551 messages over the TLS connection come from the client that was 2552 initially authenticated. 2554 An attacker may attempt to impersonate a floor control server. A 2555 successful attacker would be able to make clients think that they 2556 hold a particular floor so that they would try to access a resource 2557 (e.g., sending media) without having legitimate rights to access it. 2558 Floor control server impersonation is avoided by having servers only 2559 accept BFCP messages over authenticated TLS connections. 2561 Attackers may attempt to modify messages exchanged by a client and a 2562 floor control server. The integrity protection provided by TLS 2563 connections prevents this attack. 2565 An attacker may attempt to fetch a valid message sent by a client to 2566 a floor control server and replay it over a connection between the 2567 attacker and the floor control server. This attack is prevented by 2568 having floor control servers check that messages arriving over a 2569 given authenticated TLS connection use an authorized user ID (i.e., a 2570 user ID that the user that established the authenticated TLS 2571 connection is allowed to use). 2573 Attackers may attempt to pick messages from the network to get access 2574 to confidential information between the floor control server and a 2575 client (e.g., why a floor request was denied). TLS confidentiality 2576 prevents this attack. Therefore, it is RECOMMENDED that TLS is used 2577 with a non-null encryption algorithm. 2579 15. IANA Considerations 2581 This document instructs the IANA to create a new registry for BFCP 2582 parameters called "Binary Floor Control Protocol (BFCP) Parameters". 2583 This new registry has a number of subregistries, which are described 2584 in the following Sections 2586 15.1. Attribute Subregistry 2588 This Section establishes the Attribute subregistry under the BFCP 2589 Parameters registry. As per the terminology in RFC 2434 [4], the 2590 registration policy for BFCP attributes shall be "Specification 2591 Required". For the purposes of this subregistry, the BFCP attributes 2592 for which IANA registration is requested MUST be defined by a 2593 standards-track RFC. Such RFC MUST specify the attribute's type, 2594 name, format, and semantics. 2596 For each BFCP attribute, the IANA registers its type, its name, and 2597 the reference to the RFC where the attribute is defined. The 2598 following table contains the initial values of this subregistry. 2600 +------+---------------------------+------------+ 2601 | Type | Attribute | Reference | 2602 +------+---------------------------+------------+ 2603 | 1 | BENEFICIARY-ID | [RFC XXXX] | 2604 | 2 | FLOOR-ID | [RFC XXXX] | 2605 | 3 | FLOOR-REQUEST-ID | [RFC XXXX] | 2606 | 4 | PRIORITY | [RFC XXXX] | 2607 | 5 | REQUEST-STATUS | [RFC XXXX] | 2608 | 6 | ERROR-CODE | [RFC XXXX] | 2609 | 7 | ERROR-INFO | [RFC XXXX] | 2610 | 8 | PARTICIPANT-PROVIDED-INFO | [RFC XXXX] | 2611 | 9 | STATUS-INFO | [RFC XXXX] | 2612 | 10 | SUPPORTED-ATTRIBUTES | [RFC XXXX] | 2613 | 11 | SUPPORTED-PRIMITIVES | [RFC XXXX] | 2614 | 12 | USER-DISPLAY-NAME | [RFC XXXX] | 2615 | 13 | USER-URI | [RFC XXXX] | 2616 | 14 | BENEFICIARY-INFORMATION | [RFC XXXX] | 2617 | 15 | FLOOR-REQUEST-INFORMATION | [RFC XXXX] | 2618 | 16 | REQUESTED-BY-INFORMATION | [RFC XXXX] | 2619 +------+---------------------------+------------+ 2621 Table 6: Initial values of the BFCP Attribute subregistry 2623 15.2. Primitive Subregistry 2625 This Section establishes the Primitive subregistry under the BFCP 2626 Parameters registry. As per the terminology in RFC 2434 [4], the 2627 registration policy for BFCP primitives shall be "Specification 2628 Required". For the purposes of this subregistry, the BFCP primitives 2629 for which IANA registration is requested MUST be defined by a 2630 standards-track RFC. Such RFC MUST specify the primitive's value, 2631 name, format, and semantics. 2633 For each BFCP primitive, the IANA registers its value, its name, and 2634 the reference to the RFC where the primitive is defined. The 2635 following table contains the initial values of this subregistry. 2637 +-------+--------------------+------------+ 2638 | Value | Primitive | Reference | 2639 +-------+--------------------+------------+ 2640 | 1 | FloorRequest | [RFC XXXX] | 2641 | 2 | FloorRelease | [RFC XXXX] | 2642 | 3 | FloorRequestQuery | [RFC XXXX] | 2643 | 4 | FloorRequestStatus | [RFC XXXX] | 2644 | 5 | UserQuery | [RFC XXXX] | 2645 | 6 | UserStatus | [RFC XXXX] | 2646 | 7 | FloorQuery | [RFC XXXX] | 2647 | 8 | FloorStatus | [RFC XXXX] | 2648 | 9 | ChairAction | [RFC XXXX] | 2649 | 10 | ChairActionAck | [RFC XXXX] | 2650 | 11 | Hello | [RFC XXXX] | 2651 | 12 | HelloAck | [RFC XXXX] | 2652 | 13 | Error | [RFC XXXX] | 2653 +-------+--------------------+------------+ 2655 Table 7: Initial values of the BFCP primitive subregistry 2657 15.3. Request Status Subregistry 2659 This Section establishes the Request Status subregistry under the 2660 BFCP Parameters registry. As per the terminology in RFC 2434 [4], 2661 the registration policy for BFCP request status shall be 2662 "Specification Required". For the purposes of this subregistry, the 2663 BFCP request status for which IANA registration is requested MUST be 2664 defined by a standards-track RFC. Such RFC MUST specify the value 2665 and the semantics of the request status. 2667 For each BFCP request status, the IANA registers its value, its 2668 meaning, and the reference to the RFC where the request status is 2669 defined. The following table contains the initial values of this 2670 subregistry. 2672 +-------+-----------+------------+ 2673 | Value | Status | Reference | 2674 +-------+-----------+------------+ 2675 | 1 | Pending | [RFC XXXX] | 2676 | 2 | Accepted | [RFC XXXX] | 2677 | 3 | Granted | [RFC XXXX] | 2678 | 4 | Denied | [RFC XXXX] | 2679 | 5 | Cancelled | [RFC XXXX] | 2680 | 6 | Released | [RFC XXXX] | 2681 | 7 | Revoked | [RFC XXXX] | 2682 +-------+-----------+------------+ 2684 Table 8: Initial values of the Request Status subregistry 2686 15.4. Error Code Subregistry 2688 This Section establishes the Error Code subregistry under the BFCP 2689 Parameters registry. As per the terminology in RFC 2434 [4], the 2690 registration policy for BFCP error codes shall be "Specification 2691 Required". For the purposes of this subregistry, the BFCP error 2692 codes for which IANA registration is requested MUST be defined by a 2693 standards-track RFC. Such RFC MUST specify the value and the 2694 semantics of the error code, and any Error Specific Details that 2695 apply to it. 2697 For each BFCP primitive, the IANA registers its value, its meaning, 2698 and the reference to the RFC where the primitive is defined. The 2699 following table contains the initial values of this subregistry. 2701 +-------+--------------------------------------------------+-----------+ 2702 | Value | Meaning | Reference | 2703 +-------+--------------------------------------------------+-----------+ 2704 | 1 | Conference does not Exist | [RFC | 2705 | | | XXXX] | 2706 | 2 | User does not Exist | [RFC | 2707 | | | XXXX] | 2708 | 3 | Unknown Primitive | [RFC | 2709 | | | XXXX] | 2710 | 4 | Unknown Mandatory Attribute | [RFC | 2711 | | | XXXX] | 2712 | 5 | Unauthorized Operation | [RFC | 2713 | | | XXXX] | 2714 | 6 | Invalid Floor ID | [RFC | 2715 | | | XXXX] | 2716 | 7 | Floor Request ID Does Not Exist | [RFC | 2717 | | | XXXX] | 2718 | 8 | You have Already Reached the Maximum Number of | [RFC | 2719 | | Ongoing Floor Requests for this Floor | XXXX] | 2720 | 9 | Use TLS | [RFC | 2721 | | | XXXX] | 2722 +-------+--------------------------------------------------+-----------+ 2724 Table 9: Initial Values of the Error Code subregistry 2726 16. Acknowledgments 2728 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 2729 ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, 2730 Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben 2731 Campbell, Dave Morgan, and Oscar Novo provided useful comments. 2733 17. References 2735 17.1. Normative References 2737 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2738 Levels", BCP 14, RFC 2119, March 1997. 2740 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2741 Specifications: ABNF", RFC 2234, November 1997. 2743 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2744 RFC 2246, January 1999. 2746 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 2747 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 2749 [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 2750 Transport Layer Security (TLS)", RFC 3268, June 2002. 2752 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 2753 STD 63, RFC 3629, November 2003. 2755 [7] Camarillo, G., "Session Description Protocol (SDP) Format for 2756 Binary Floor Control Protocol (BFCP) Streams", 2757 draft-ietf-mmusic-sdp-bfcp-02 (work in progress), July 2005. 2759 17.2. Informational References 2761 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 2762 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 2763 Session Initiation Protocol", RFC 3261, June 2002. 2765 [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 2766 Session Description Protocol (SDP)", RFC 3264, June 2002. 2768 [10] Schulzrinne, H., "Requirements for Floor Control Protocol", 2769 draft-ietf-xcon-floor-control-req-03 (work in progress), 2770 October 2005. 2772 [11] Rosenberg, J., "A Framework for Conferencing with the Session 2773 Initiation Protocol", 2774 draft-ietf-sipping-conferencing-framework-05 (work in 2775 progress), May 2005. 2777 [12] Barnes, M. and C. Boulton, "A Framework and Data Model for 2778 Centralized Conferencing", draft-barnes-xcon-framework-02 (work 2779 in progress), February 2005. 2781 Authors' Addresses 2783 Gonzalo Camarillo 2784 Ericsson 2785 Hirsalantie 11 2786 Jorvas 02420 2787 Finland 2789 Email: Gonzalo.Camarillo@ericsson.com 2791 Joerg Ott 2792 Helsinki University of Technology 2793 Department for Electrical and Communications Engineering 2794 Networking Laboratory 2795 Helsinki 2796 Finland 2798 Email: jo@netlab.hut.fi 2800 Keith Drage 2801 Lucent Technologies 2802 Windmill Hill Business Park 2803 Swindon 2804 Wiltshire SN5 6PP 2805 UK 2807 Email: drage@lucent.com 2809 Intellectual Property Statement 2811 The IETF takes no position regarding the validity or scope of any 2812 Intellectual Property Rights or other rights that might be claimed to 2813 pertain to the implementation or use of the technology described in 2814 this document or the extent to which any license under such rights 2815 might or might not be available; nor does it represent that it has 2816 made any independent effort to identify any such rights. Information 2817 on the procedures with respect to rights in RFC documents can be 2818 found in BCP 78 and BCP 79. 2820 Copies of IPR disclosures made to the IETF Secretariat and any 2821 assurances of licenses to be made available, or the result of an 2822 attempt made to obtain a general license or permission for the use of 2823 such proprietary rights by implementers or users of this 2824 specification can be obtained from the IETF on-line IPR repository at 2825 http://www.ietf.org/ipr. 2827 The IETF invites any interested party to bring to its attention any 2828 copyrights, patents or patent applications, or other proprietary 2829 rights that may cover technology that may be required to implement 2830 this standard. Please address the information to the IETF at 2831 ietf-ipr@ietf.org. 2833 Disclaimer of Validity 2835 This document and the information contained herein are provided on an 2836 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2837 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2838 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2839 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2840 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2841 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2843 Copyright Statement 2845 Copyright (C) The Internet Society (2005). This document is subject 2846 to the rights, licenses and restrictions contained in BCP 78, and 2847 except as set forth therein, the authors retain all their rights. 2849 Acknowledgment 2851 Funding for the RFC Editor function is currently provided by the 2852 Internet Society.