idnits 2.17.1 draft-ietf-xcon-bfcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1892. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1898. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1844 has weird spacing: '...Changes in XM...' == 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 (August 19, 2004) is 7161 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) == Unused Reference: '6' is defined on line 1791, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1795, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1798, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1801, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1812, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1835, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '1') ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2717 (ref. '7') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2732 (ref. '8') (Obsoleted by RFC 3986) == Outdated reference: A later version (-10) exists of draft-ietf-mmusic-sdp-comedia-08 == Outdated reference: A later version (-03) exists of draft-ietf-xcon-floor-control-req-01 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-05 == Outdated reference: A later version (-03) exists of draft-ietf-simple-xcap-package-02 Summary: 12 errors (**), 0 flaws (~~), 14 warnings (==), 7 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: February 17, 2005 J. Ott 5 Universitaet Bremen 6 K. Drage 7 Lucent Technologies 8 August 19, 2004 10 The Binary Floor Control Protocol (BFCP) 11 draft-ietf-xcon-bfcp-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 17, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 Floor control is a means to manage joint or exclusive access to 47 shared resource in a (multiparty) conferencing environment. Thereby, 48 floor control complements other functions -- such as conference and 49 media session setup, conference policy manipulation, and media 50 control -- that are realized by other protocols. 52 This document specicies the Binary Floor Control Protocol (BFCP). 53 BFCP is used between conference participants and floor control 54 servers, and between floor chairs (i.e., moderators) and floor 55 control servers. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1 Floor Creation . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2 Obtaining Information to Contact a BFCP Floor Server . . . 7 64 3.3 Generating a Shared Secret . . . . . . . . . . . . . . . . 7 65 3.4 Obtaining Floor-Resource Associations . . . . . . . . . . 7 66 3.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . 8 67 4. Overview of Operation . . . . . . . . . . . . . . . . . . . 8 68 4.1 User - Floor Control Server Interface . . . . . . . . . . 9 69 4.2 Floor Chair - Floor Control Server Interface . . . . . . . 11 70 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 12 72 5.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 13 73 5.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 14 74 5.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.2.3 BENEFICIARY-ID . . . . . . . . . . . . . . . . . . . . 14 76 5.2.4 TRANSACTION-ID . . . . . . . . . . . . . . . . . . . . 15 77 5.2.5 FLOOR-REQUEST-ID . . . . . . . . . . . . . . . . . . . 15 78 5.2.6 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 15 79 5.2.7 INTEGRITY . . . . . . . . . . . . . . . . . . . . . . 16 80 5.2.8 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 16 81 5.2.9 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 17 82 5.2.10 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . 19 83 5.2.11 USER-URI . . . . . . . . . . . . . . . . . . . . . . 19 84 5.2.12 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 19 85 6. Message Format . . . . . . . . . . . . . . . . . . . . . . . 19 86 6.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . . . 19 87 6.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . . . 20 88 6.3 FloorRequestInfo . . . . . . . . . . . . . . . . . . . . . 20 89 6.4 FloorRequestStatus . . . . . . . . . . . . . . . . . . . . 20 90 6.5 FloorInfo . . . . . . . . . . . . . . . . . . . . . . . . 21 91 6.6 FloorStatus . . . . . . . . . . . . . . . . . . . . . . . 21 92 6.7 ChairAction . . . . . . . . . . . . . . . . . . . . . . . 22 93 6.8 ChairActionAck . . . . . . . . . . . . . . . . . . . . . . 22 94 6.9 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 95 6.10 PingAck . . . . . . . . . . . . . . . . . . . . . . . . 22 96 6.11 Error . . . . . . . . . . . . . . . . . . . . . . . . . 23 97 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 8. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . 23 99 9. Protocol Transactions . . . . . . . . . . . . . . . . . . . 23 100 9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . 24 101 9.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . 24 102 10. Authentication . . . . . . . . . . . . . . . . . . . . . . . 24 103 10.1 Client Behavior . . . . . . . . . . . . . . . . . . . . 24 104 10.2 Server Behavior . . . . . . . . . . . . . . . . . . . . 25 105 11. Client Operations . . . . . . . . . . . . . . . . . . . . . 25 106 11.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . 25 107 11.1.1 Receiving a Response . . . . . . . . . . . . . . . . 26 108 12. Requesting Information about Floor Requests . . . . . . . . 27 109 12.1 Receiving a Response . . . . . . . . . . . . . . . . . . 27 110 13. Cancelling a Floor Request and Releasing a Floor . . . . . . 28 111 13.1 Receiving a Response . . . . . . . . . . . . . . . . . . 28 112 14. Requesting Information about Floors . . . . . . . . . . . . 28 113 14.1 Receiving a Response . . . . . . . . . . . . . . . . . . 29 114 15. Checking the Liveness of a Server . . . . . . . . . . . . . 29 115 15.1 Receiving Responses . . . . . . . . . . . . . . . . . . 30 116 16. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 30 117 16.1 Obtaining Information about Floor Requests . . . . . . . 30 118 16.2 Instructing the Floor Control Server . . . . . . . . . . 30 119 16.2.1 Receiving a Response . . . . . . . . . . . . . . . . 31 120 17. Server Operations . . . . . . . . . . . . . . . . . . . . . 32 121 17.1 Reception of a FloorRequest Message . . . . . . . . . . 32 122 17.2 Reception of a FloorRequestInfo Message . . . . . . . . 33 123 17.3 Reception of a FloorRelease Message . . . . . . . . . . 33 124 17.4 Reception of a FloorInfo Message . . . . . . . . . . . . 34 125 17.5 Reception of a ChairAction Message . . . . . . . . . . . 35 126 17.6 Reception of a Ping Message . . . . . . . . . . . . . . 35 127 17.7 Error Message Generation . . . . . . . . . . . . . . . . 36 128 18. BFCP and the Offer/Answer Model . . . . . . . . . . . . . . 36 129 18.1 Fields in the m Line . . . . . . . . . . . . . . . . . . 36 130 18.2 The confid and userid SDP Parameters . . . . . . . . . . 37 131 18.3 The k line . . . . . . . . . . . . . . . . . . . . . . . 37 132 18.4 TCP Connection Management . . . . . . . . . . . . . . . 37 133 18.5 Association between Streams and Floors . . . . . . . . . 38 134 18.6 Example . . . . . . . . . . . . . . . . . . . . . . . . 38 135 19. Security Considerations . . . . . . . . . . . . . . . . . . 39 136 20. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 137 20.1 SDP Attributes Registration . . . . . . . . . . . . . . 39 138 21. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 39 139 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 140 22.1 Normative References . . . . . . . . . . . . . . . . . . . 39 141 22.2 Informational References . . . . . . . . . . . . . . . . . 40 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 143 Intellectual Property and Copyright Statements . . . . . . . 42 145 1. Introduction 147 Within a (multimedia) conference, some applications (e.g., conference 148 applications) need to manage the access to a set of shared resources, 149 such as the right to send media over a particular media stream. 150 Floor control enables such applications to provide users with 151 coordinated (shared or exclusive) access to these resources. 153 The Requirements for Floor Control Protocol [15] list a set of 154 requirements that need to be met by floor control protocols. The 155 Binary Floor Control Protocol (BFCP), which is specified in this 156 document, meets these requirements. 158 Section 2 defines the terminology used throughout this document and 159 Section 3 discusses the scope of BFCP (i.e., which tasks fall within 160 the scope of BFCP and which ones are performed using different 161 mechanisms). Section 4 provides a non-normative overview of BFCP 162 operation and subsequent sections provide the normative specification 163 of BFCP. 165 2. Terminology 167 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 168 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 169 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 170 described in BCP 14, RFC 2119 [2] and indicate requirement levels for 171 compliant implementations. 173 Conference Policy: The complete set of rules for a particular 174 conference manipulated by the conference policy server. It includes 175 the membership policy and the media policy. There is an instance of 176 conference policy for each conference. 178 Conference Policy Control Protocol (CPCP): The protocol used by 179 clients to manipulate the conference policy. 181 Floor: A permission to temporarily access or manipulate a specific 182 shared resource or set of resources. 184 Floor chair: A user (or an entity) who manages one floor (grants, 185 denies, or revokes a floor). The floor chair does not have to be a 186 member in a conference. 188 Floor control: A mechanism that enables applications or users to gain 189 safe and mutually exclusive or non-exclusive input access to the 190 shared object or resource. 192 Floor control server: A logical entity that maintains the state of 193 the floor(s) including which floors exists, who the floor chairs are, 194 who holds a floor, etc. Requests to manipulate a floor are directed 195 at the floor control server. 197 Media Policy: A set of rules manipulated by the conference policy 198 server regarding the media composition of the conference. The media 199 policy is used by the focus to determine the mixing characteristics 200 for the conference. The media policy includes rules about which 201 participants receive media from which other participants, and the 202 ways in which that media is combined for each participant. In the 203 case of audio, these rules can include the relative volumes at which 204 each participant is mixed. In the case of video, these rules can 205 indicate whether the video is tiled, whether the video indicates the 206 loudest speaker, and so on. 208 EDITOR'S NOTE: we may want to reference the definitions in the 209 conferencing framework. If we decide to copy them here, we need to 210 make sure that we copy all the definitions we use in this document. 212 3. Scope 214 As stated above, the BFCP is a protocol to coordinate access to 215 shared resources in a conference setting following the requirements 216 defined in [15]. Floor control complements other functions defined 217 in the conference framework, such as conference policy and media 218 policy. In particular, it is the conference policy that defines 219 which media streams and applications are floor-controlled, who is/are 220 the respective floor chair(s), and how access to the floor is 221 managed. Furthermore, it is up to the media policy to define which 222 (if any) impact on media stream handling (e.g. switching or mixing) 223 assignment of a floor to a participant has. 225 The floor control protocol BFCP defined in this document only 226 specifies a means to arbitrate access to floors. The rules and 227 constraints for floor arbitration and the results of floor 228 assignments are outside the scope of this document and defined by the 229 conference and media policy, respectively. 231 Figure 1 shows the tasks that BFCP can perform. 233 +---------+ 234 | Floor | 235 | Chair | 236 | | 237 +---------+ 238 ^ | 239 | | 240 Notification | | Decision 241 | | 242 | | 243 Floor | v 244 +---------+ Request +---------+ +---------+ 245 | |----------->| Floor | Notification | | 246 | User | | Control |------------->| User | 247 | |<-----------| Server | | | 248 +---------+ Granted or +---------+ +---------+ 249 Denied 251 Figure 1: Functionality provided by BFCP 253 BFCP provides a means: 255 o for users to send floor requests to floor control servers. 256 o for floor control servers to grant or deny requests to access a 257 given resource from users. 258 o for floor chairs to send floor control servers decisions regarding 259 floor requests. 260 o for floor control servers to keep users and floor chairs informed 261 about the status of a given floor. 263 Even though tasks that do not belong to the previous list are outside 264 the scope of BFCP, some of these out-of-scope tasks relate to floor 265 control and are essential to create floors and to establish BFCP 266 connections between different entities. In the following 267 subsections, we discuss some of these tasks and mechanisms to perform 268 them. 270 3.1 Floor Creation 272 The conference policy for a particular conference contains the floors 273 of the conference and the resource or resources associated with each 274 floor. For example, a conference may have two floors: one 275 controlling who can talk at a particular time and another controlling 276 who can write on a shared whiteboard. 278 According to the definitions in Section 2, the conference policy is 279 manipulated using a Conference Policy Control Protocol (CPCP), such 280 as [16]. Consequently, floor creation and termination is handled by 281 CPCP. In addition, CPCP also handles the association of a given 282 floor with a resource or a set of resources (e.g., media streams). 284 Additionally, the floor control server needs to stay up to date on 285 changes on the conference policy (e.g., when a new floor is created). 286 The floor control may use a mechanism such as the XCAP event package 287 [19] to keep itself up to date. 289 3.2 Obtaining Information to Contact a BFCP Floor Server 291 A user or a floor chair needs a set of data in order to establish a 292 BFCP connection to a floor control server. These data include the 293 transport address of the server, the conference identifier, and the 294 user identifier. 296 Users can obtain this information in different ways. Two 297 possibilities are using CPCP and using the offer/answer [11] exchange 298 which is used to establish media streams between the user and the 299 conference server. Section 18 discusses how to use an SDP [5] offer/ 300 answer [11] exchange to obtain this information. 302 3.3 Generating a Shared Secret 304 Authentication and integrity protection in BFCP are based on a shared 305 secret between the user or floor chair, and the floor control server. 306 So, there is a need for a mechanism to generate such a shared secret. 308 When the user or the floor control chair obtains a the information 309 needed to contact the BFCP floor server over a secure channel (e.g., 310 an offer/answer exchange using SIP [10] protected using S/MIME), they 311 can get the shared secret using the same channel. 313 If there is no secure channel available, a different mechanism needs 314 to be used. For example, MIKEY [18] allows an offerer and an 315 answerer to perform a Diffie-Hellman key exchange. 317 Editor's note: Probably need to mention TLS as another mechanism 318 here. 320 3.4 Obtaining Floor-Resource Associations 322 Floors are associated with resources. For example, a floor that 323 controls who talks at a given time has a particular audio stream as 324 its associated resource. Associations between floors and resources 325 are part of the conference policy, which is manipulated using CPCP. 327 Users and floor chairs need to know which resources are associated 328 with which floors. They can obtain this information using different 329 mechanisms, such as CPCP or an offer/answer [11] exchange. Section 330 18 describes how to use an offer/answer exchange to obtain these 331 associations. 333 Note that users perform offer/answer exchanges with the SIP focus 334 of the conference. So, the SIP focus needs to obtain information 335 about associations between floors and resources using a mechanism 336 such as CPCP in order to be able to provide this information to a 337 user in an offer/answer exchange. 339 3.5 Policy Enforcement 341 A user whose floor request is granted has the right to use in a 342 certain way the resource or resources associated with the floor that 343 was requested. For example, the user may have the right to talk 344 (i.e., 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. According to the definition in 349 Section 2, the media policy of a conference is the one that 350 determines which users can actually use the resources in the 351 conference. 353 So, if the policy of a conference is to enforce floor control 354 decisions, every change in the status of any floor needs to be 355 reflected in the media policy of the conference. For example, the 356 mixer only accepts media from the user who holds the floor. 358 A way to reflect the status of the floors in the media policy is to 359 have the floor control server manipulate the media policy using CPCP. 360 Nevertheless, there are other ways to enforce floor control policies, 361 such as having a floor control chair manipulate the media policy 362 (using CPCP) only if there are misbehaving users trying to use a 363 resource without holding its associated floor. 365 4. Overview of Operation 367 This section provides a non-normative description of BFCP operations. 368 Section 4.1 describes the interface between users and floor control 369 servers and Section 4.2 describes the interface between floor chairs 370 and floor control servers 372 BFCP messages, which use a TLV (Type-Length-Value) binary encoding, 373 consist of a common header followed by a set of TLVs. The common 374 header contains, among other information, a 32-bit conference 375 identifier. Users and floor chairs are identified by a 16-bit user 376 identifier, which is carried in a TLV. 378 4.1 User - Floor Control Server Interface 380 Users request a floor by sending a FloorRequest message to the floor 381 control server. BFCP supports third party floor requests. That is, 382 the user sending the floor request need not be the same as the user 383 who will get the floor once the floor request is granted. 384 FloorRequest messages carry the identity of the requester in a 385 USER-ID TLV, and the identity of the beneficiary of the floor, in 386 third party floor requests, in a BENEFICIARY-ID TLV. 388 Third party floor requests can be sent by users that have a BFCP 389 connection to the floor control server, but who are not conference 390 participants (i.e., they do not handle any media). 392 FloorRequest messages identify the floor or floors being requested by 393 carrying their 16-bit floor identifiers in FLOOR-ID TLVs. If a 394 FloorRequest message carries more than one floor identifier, the 395 floor control server treats all the floor requests as an atomic 396 package. That is, the floor control server either grants or denies 397 all the floors in the FloorRequest message. 399 EDITOR'S NOTE: we need to explain in this paragraph that if a user is 400 anonymous, the floor control server does not disclose the identity of 401 the requester of the floor to the rest of the users and floor chairs. 403 Floor control servers respond to FloorRequest messages with 404 FloorStatus messages. 406 Editor's note: This section will be finished when we have agreed on 407 what it is specified in the rest of this document. For the time 408 being, below there are two typical call flows: a client requesting a 409 floor and a client requesting information about a floor. 411 Client Floor Control 412 Server 414 | FloorRequest | 415 | TRANSACTION-ID: 123 | 416 |----------------------------->| 417 | | 418 | FloorRequestStatus | 419 | TRANSACTION-ID: 123 | 420 | FLOOR-REQUEST-ID: 345 | 421 | REQUEST-STATUS: Pending | 422 |<-----------------------------| 423 | | 424 | FloorRequestStatus | 425 | FLOOR-REQUEST-ID: 345 | 426 | REQUEST-STATUS: Accepted | 427 |<-----------------------------| 428 | | 429 | | 430 | FloorRequestStatus | 431 | FLOOR-REQUEST-ID: 345 | 432 | REQUEST-STATUS: Granted | 433 |<-----------------------------| 434 | | 435 | | 436 | FloorRelease | 437 | TRANSACTION-ID: 124 | 438 | FLOOR-REQUEST-ID: 345 | 439 |----------------------------->| 440 | | 441 | FloorRequestStatus | 442 | TRANSACTION-ID: 124 | 443 | FLOOR-REQUEST-ID: 345 | 444 | REQUEST-STATUS: Released | 445 |<-----------------------------| 446 | | 448 Figure 2: Requesting and releasing a floor 450 Client or Floor Control 451 Chair Server 453 | FloorInfo | 454 | TRANSACTION-ID: 123 | 455 | FLOOR-ID: 15 | 456 |----------------------------->| 457 | | 458 |FloorStatus | 459 | TRANSACTION-ID: 123 | 460 | FLOOR-ID: 15 | 461 | FLOOR-REQUEST-ID: 345 | 462 | REQUEST-STATUS: Granted | 463 | FLOOR-REQUEST-ID: 348 | 464 | REQUEST-STATUS: 1st in queue| 465 |<-----------------------------| 466 | | 467 |FloorStatus | 468 | FLOOR-ID: 15 | 469 | FLOOR-REQUEST-ID: 348 | 470 | REQUEST-STATUS: Granted | 471 |<-----------------------------| 472 | | 473 |FloorStatus | 474 | FLOOR-ID: 15 | 475 |<-----------------------------| 476 | | 478 Figure 3: Obtaining status information about a floor 480 4.2 Floor Chair - Floor Control Server Interface 482 TBD. For the time being, below there is the typical call flow for 483 this interface. 485 Chair Floor Control 486 Server 488 | ChairAction | 489 | TRANSACTION-ID: 123 | 490 | FLOOR-ID: 15 | 491 | FLOOR-REQUEST-ID: 345 | 492 | REQUEST-STATUS: Granted | 493 |----------------------------->| 494 | | 495 | ChairActionAck | 496 | TRANSACTION-ID: 123 | 497 |<-----------------------------| 498 | | 500 Figure 4: Chair invoking an action at the floor control server 502 5. Packet Format 504 BFCP packets consist of an 8-byte fixed header followed by 505 attributes. All the protocol values MUST be sent in network byte 506 order. 508 5.1 FIXED-HEADER Format 510 The following is the FIXED-HEADER format. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Ver |Reserved | Primitive | Payload Length | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Conference ID | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Ver: the 3-bit version field MUST be set to 1 to indicate this 521 version of BFCP. 523 Reserved: at this point, the 5 bits in the reserved field SHOULD be 524 set to zero by the sender of the message and MUST be ignored by the 525 receiver. 527 Primitive: this 8-bit field identifies the main purpose of the 528 message. The following primitive values are defined: 530 Value Primitive Direction 531 _________________________________________________________ 532 0 FloorRequest C -> S 533 1 FloorRelease C -> S 534 2 FloorRequestInfo S -> C ; Ch -> S 535 3 FloorRequestStatus S -> C 536 4 FloorInfo C -> S ; Ch -> S 537 5 FloorStatus S -> C ; S -> Ch 538 6 ChairAction Ch -> S 539 7 ChairActionAck S -> Ch 540 8 Ping C -> S ; Ch <-> S 541 9 PingAck S -> C ; Ch <-> S 542 10 Error S -> C ; S -> Ch 544 S: Server C: Client Ch: Chair 546 Payload Length: this 16-bit field contains length of the message in 547 4-byte units excluding the fixed header. 549 Conference ID: this 32-bit identifies the conference the message 550 belongs to. 552 5.2 Attribute Format 554 BFCP attributes are encoded in TLV (Type-Length-Value) format. TLVs 555 are 32-bit aligned. 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Type |M| Length | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 562 | | 563 / Attribute Contents / 564 / / 565 | | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Type: this 7-bit field contains the code for the attribute. 570 M: the 'M' bit, known as the Mandatory bit, indicates whether support 571 of the attribute is required. If an unrecognized attribute with the 572 'M' bit set is received, the message is rejected. 574 Length: this 8-bit field contains the length of the attribute in 575 bytes, excluding any padding defined for specific attributes. The 576 Type, 'M' bit, and Length fields are included. 578 Attribute Contents: the contents of the different TLVs are defined in 579 the following sections. 581 5.2.1 FLOOR-ID 583 The following is the format of the contents of the FLOOR-ID 584 attribute, whose attribute type is 1. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type = 1 |M| Length | Floor ID | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Floor ID: this field contains a 16-bit value that uniquely identifies 593 a floor within a conference. 595 5.2.2 USER-ID 597 The following is the format of the contents of the USER-ID attribute, 598 whose attribute type is 2. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type = 2 |M| Length | User ID | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 User ID: this field contains a 16-bit value that uniquely identifies 607 a user within a conference. 609 5.2.3 BENEFICIARY-ID 611 The following is the format of the contents of the BENEFICIARY-ID 612 attribute, whose attribute type is 2. 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Type = 2 |M| Length | Beneficiary ID | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Beneficiary ID: this field contains a 16-bit value that uniquely 621 identifies a user within a conference. 623 5.2.4 TRANSACTION-ID 625 The following is the format of the contents of the TRANSACTION-ID 626 attribute, whose attribute type is 3. 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Type = 3 |M| Length | Transaction ID | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Transaction ID: this field contains a 16-bit value that allows users 635 to match a given message with its response. 637 5.2.5 FLOOR-REQUEST-ID 639 The following is the format of the contents of the FLOOR-REQUEST-ID 640 attribute, whose attribute type is 4. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Type = 3 |M| Length | Floor Request ID | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Floor Request ID: this field contains a 16-bit value that indentifies 649 a floor request at the floor control server. 651 5.2.6 HUMAN-READABLE-INFO 653 The following is the format of the contents of the 654 HUMAN-READABLE-INFO attribute, whose attribute type is 5. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type = 4 |M| Length | | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 661 | | 662 / Text / 663 / +-+-+-+-+-+-+-+-+ 664 | | Padding | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Text: this field contains UTF-8 [13] encoded text. 669 In some situations, the contents of the Text field may be generated 670 by an automaton. If such automaton has information about the 671 preferred language of the receiver of a particular 672 HUMAN-READABLE-INFO TLV, it MAY use this language to generate the 673 Text field. 675 Padding: one, two, or three bytes of padding added so that the 676 contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned. The 677 Padding bits SHOULD be set to zero by the sender and MUST be ignored 678 by the receiver. If the TLV is already 32-bit aligned, no padding is 679 needed. 681 5.2.7 INTEGRITY 683 The following is the format of the contents of the INTEGRITY 684 attribute, whose attribute type is 6. 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Type = 5 |M| Length | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 691 | | 692 + + 693 | | 694 + HMAC-SHA1 + 695 | | 696 + + 697 | | 698 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | | Padding | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 HMAC-SHA1: this 20-byte field contains an HMAC-SHA1 [1] of the BFCP 703 message. Its calculation is described in Section 10. 705 Padding: two bytes of padding added so that the contents of the 706 HMAC-SHA1 TLV is 32-bit aligned. The Padding bits SHOULD be set to 707 zero by the sender and MUST be ignored by the receiver. 709 5.2.8 REQUEST-STATUS 711 The following is the format of the contents of the REQUEST-STATUS 712 attribute, whose attribute type is 7. 714 0 1 2 3 715 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 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Type = 6 |M| Length | Request Status | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Queue Position | Padding | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Request Status: this 16-bit field contains the status of the request, 723 as described in the following table. 725 Value Status 726 ______________________________ 727 0 Pending 728 1 Accepted 729 2 Granted 730 3 Denied 731 4 Cancelled 732 5 Released 733 6 Revoked 734 7 Replaced 736 Queue Position: this 16-bit field contains, when applicable, the 737 position of the floor request in the floor request queue at the 738 server. If the Request Status value is different from Accepted, the 739 floor control server does not implement a floor request queue, or the 740 floor control server does not want to provide the client with this 741 information, all the bits of this field SHOULD be set to zero. 743 A floor request is in Pending state if the floor control server needs 744 to contact a floor chair in order to accept the floor request, but 745 has not done it yet. Once the floor control chair accepts the floor 746 request, the floor request is moved to the Accepted state. 748 Padding: two bytes of padding added so that the contents of the 749 REQUEST-STATUS TLV is 32-bit aligned. The Padding bits SHOULD be set 750 to zero by the sender and MUST be ignored by the receiver. 752 5.2.9 ERROR-CODE 754 The following is the format of the contents of the ERROR-CODE 755 attribute, whose attribute type is 8. 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 | Type = 7 |M| Length | Error Code | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 | Error Specific Details | 764 / / 765 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | | Padding | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Error Code: this 16-bit field contains an error code from the 770 following table. 772 Value Meaning 773 __________________________________________________________ 774 0 Conference does not Exist 775 1 Authentication Failed 776 2 Unknown Mandatory TLV 777 3 Floor Request ID Does Not Exist 778 4 Unauthorized Operation 779 5 User does not Exist 780 6 Invalid Request-ID 781 7 INTEGRITY TLV Required 783 Error Specific Details: Present only for certain Error Codes. In 784 this document, only for Error Code 2 (Unknown Mandatory TLV). For 785 Error Code 2, this field contains the Types of the TLVs (which were 786 present in the message that triggered the Error message) that were 787 unknown to the receiver, encoded as follows. 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Unknown TLV Type | Unknown TLV Type | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | 795 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | | Unknown TLV Type | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Unknown TLV Type | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 Padding: one, two, or three bytes of padding added so that the 802 contents of the ERROR-CODE TLV is 32-bit aligned. If the TLV is 803 already 32-bit aligned, no padding is needed. 805 The Padding bits SHOULD be set to zero by the sender and MUST be 806 ignored by the receiver. Note all the Error Codes defined in this 807 document but Error Code 2, result in a TLV which is already 32-bit 808 aligned (i.e., no need of padding). Error Code 2 results in a TLV 809 that may need 2 bytes of padding. 811 5.2.10 USER-DISPLAY-NAME 813 The USER-DISPLAY-NAME attribute type is 9 and its format is the same 814 as the HUMAN-READABLE-INFO attribute. The Text field in the 815 USER-DISPLAY-NAME attribute contains the name of the user. 817 5.2.11 USER-URI 819 The USER-URI attribute type is 10 and its format is the same as the 820 HUMAN-READABLE-INFO attribute. The Text field in the USER-URI 821 attribute contains the URI of the user. 823 5.2.12 PRIORITY 825 The following is the format of the contents of the PRIORITY 826 attribute, whose attribute type is 11. 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Type = 7 |M| Length | Priority | Reserved | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Priority: the higher the 8-bit value, the more priority is requested 835 for a given floor request. 837 Reserved: at this point, the 8 bits in the reserved field SHOULD be 838 set to zero by the sender of the message and MUST be ignored by the 839 receiver. 841 6. Message Format 843 This section contains the ABNF [3] of the BFCP messages. 845 6.1 FloorRequest 847 Clients request a floor by sending a FloorRequest message to the 848 floor control server. In addition, the FloorRequest message is also 849 used to modify existing floor requests. The following is the format 850 of the FloorRequest message: 852 FloorRequest = (FIXED-HEADER) 853 (TRANSACTION-ID) 854 (USER-ID) 855 [BENEFICIARY-ID] 856 [FLOOR-REQUEST-ID] 857 *(FLOOR-ID) 858 [HUMAN-READABLE-INFO] 859 [PRIORITY] 860 [INTEGRITY] 862 6.2 FloorRelease 864 Clients release a floor by sending a FloorRelease message to the 865 floor control server. Clients also use the FloorRelease message to 866 cancel pending floor requests. The following is the format of the 867 FloorRelease message: 869 FloorRelease = (FIXED-HEADER) 870 (TRANSACTION-ID) 871 (USER-ID) 872 (FLOOR-REQUEST-ID) 873 [INTEGRITY] 875 6.3 FloorRequestInfo 877 Clients request information about a floor request by sending a 878 FloorRequestInfo message to the floor control server. The following 879 is the format of the FloorRequest message: 881 FloorRequestInfo = (FIXED-HEADER) 882 (TRANSACTION-ID) 883 (USER-ID) 884 [BENEFICIARY-ID] 885 [FLOOR-REQUEST-ID] 886 [INTEGRITY] 888 6.4 FloorRequestStatus 890 The floor control server informs clients about the status of their 891 floor requests by sending them FloorRequestStatus messages. The 892 following is the format of the FloorRequestStatus message: 894 FloorRequestStatus = (FIXED-HEADER) 895 (TRANSACTION-ID) 896 (USER-ID) 897 [BENEFICIARY-ID] 898 [USER-DISPLAY-NAME] 899 [USER-URI] 900 1*( (FLOOR-REQUEST-ID) 901 1*(FLOOR-ID) 902 [HUMAN-READABLE-INFO] 903 [PRIORITY] 904 (REQUEST-STATUS) ) 905 [INTEGRITY] 907 6.5 FloorInfo 909 Clients request information about a floor or floors by sending a 910 FloorInfo message to the floor control server. The following is the 911 format of the FloorRequest message: 913 FloorInfo = (FIXED-HEADER) 914 (TRANSACTION-ID) 915 (USER-ID) 916 *(FLOOR-ID) 917 [INTEGRITY] 919 6.6 FloorStatus 921 The floor control server informs clients about the status, e.g., the 922 current holder(s), of a floor by sending them FloorStatus messages. 923 The following is the format of the FloorStatus message: 925 FloorStatus = (FIXED-HEADER) 926 [TRANSACTION-ID] 927 (USER-ID) 928 [FLOOR-ID] 929 *( (FLOOR-REQUEST-ID) 930 [BENEFICIARY-ID] 931 [USER-DISPLAY-NAME] 932 [USER-URI] 933 *(FLOOR-ID) 934 [HUMAN-READABLE-INFO] 935 [PRIORITY] 936 (REQUEST-STATUS) ) 937 [INTEGRITY] 939 6.7 ChairAction 941 Chairs send instructions to floor control servers by sending 942 ChairAction messages. The following is the format of the ChairAction 943 message: 945 ChairAction = (FIXED-HEADER) 946 (TRANSACTION-ID) 947 (USER-ID) 948 1*(FLOOR-ID) 949 (FLOOR-REQUEST-ID) 950 (REQUEST-STATUS) 951 [HUMAN-READABLE-INFO] 952 [INTEGRITY] 954 6.8 ChairActionAck 956 Floor control servers condirm that they have accepted a ChairAction 957 message by sending a ChairActionAck message. The following is the 958 format of the ChairActionAck message: 960 ChairActionAck = (FIXED-HEADER) 961 (TRANSACTION-ID) 962 (USER-ID) 963 [INTEGRITY] 965 6.9 Ping 967 Clients check the liveness of servers, and servers of clients, by 968 sending a Ping message. The following is the format of the Ping 969 message: 971 Ping = (FIXED-HEADER) 972 (TRANSACTION-ID) 973 (USER-ID) 974 [INTEGRITY] 976 6.10 PingAck 978 Servers confirm that they are alive on reception of a Ping message by 979 sending a PingAck message. The following is the format of the 980 PingAck message: 982 PingAck = (FIXED-HEADER) 983 (TRANSACTION-ID) 984 (USER-ID) 985 [INTEGRITY] 987 6.11 Error 989 The floor control server informs clients about errors processing 990 requests by sending them Error messages. The following is the format 991 of the Error message: 993 Error = (FIXED-HEADER) 994 (TRANSACTION-ID) 995 (USER-ID) 996 (ERROR-CODE) 997 [HUMAN-READABLE-INFO] 998 [INTEGRITY] 1000 7. Transport 1002 BFCP entities exchange BFCP messages using TCP connections. TCP 1003 provides an in-order reliable delivery of a stream of bytes. 1004 Consequently, message framing is implemented in the application 1005 layer. BFCP implements application-layer framing using TLVs. 1007 Editor's note: We need to address how to handle lost TCP connections 1008 (e.g., that the TCP connection will be re-established in this case 1009 using O/A as described further below). 1011 8. Lower-Layer Security 1013 BFCP relies on lower-layer security mechanisms to provide replay 1014 protection, and confidentiality. BFCP servers MUST support TLS [4], 1015 and clients SHOULD support TLS. Clients and servers MAY support 1016 other security mechanisms. 1018 OPEN ISSUE: do we want to implement replay-protection in the protocol 1019 instead of relying on TLS? 1021 Servers and clients that implement TLS MUST support TBD. (cypher and 1022 hash algorithm). 1024 9. Protocol Transactions 1026 In BFCP, there are two types of transactions: client-initiated 1027 transactions and server-initiated transactions (notifications). 1028 Client-initiated transactions consist of a request from a client to a 1029 server and a response from the server to the client. The request 1030 carries a TRANSACTION-ID TLV which the server copies into the 1031 response. Clients use Transaction ID values to match responses with 1032 previously-issued requests. 1034 Server-initiated transactions consist of a single message from a 1035 server to a client. Consequently, since they do not trigger any 1036 response, server-initiated transactions do not have Transaction IDs 1037 associated with them. 1039 9.1 Client Behavior 1041 A client starting a client-initiated transaction MUST set the 1042 Conference ID in the FIXED-HEADER of the message to the Conference ID 1043 for the conference that the client obtained previously. 1045 The client MUST set the Transaction ID value in the TRANSACTION-ID 1046 TLV to a number which MUST NOT be reused in another message from the 1047 client until a response from the server is received. The client uses 1048 the Transaction ID value to match this FloorRequest message with the 1049 response from the floor control server. 1051 9.2 Server Behavior 1053 A server sending a response within a client-initiated transaction 1054 MUST copy the Conference ID and the TRANSACTION-ID TLV from the 1055 request received from the client into the response. Server-initiated 1056 transactions MUST NOT contain a TRANSACTION-ID TLV. 1058 10. Authentication 1060 BFCP uses the INTEGRITY TLV to provide client and server 1061 authentication, and message integrity. The INTEGRITY TLV contains an 1062 HMAC-SHA1 [1] of the BFCP message. The use of SHA1 implies that the 1063 length of the HMAC is 20 bytes. The text used as input to HMAC is 1064 the BFCP message, including the FIXED-HEADER, up to and including the 1065 TLV preceding the INTEGRITY TLV. This text is then padded with 1066 zeroes so as to be a multiple of 64 bytes. As a result, the 1067 INTEGRITY TLV MUST be the last attribute in any BFCP message. The 1068 key used as input to HMAC is the secret shared between the server and 1069 the user identified by the USER-ID TLV in the message. 1071 10.1 Client Behavior 1073 Clients SHOULD add an INTEGRITY TLV to all their messages. 1074 Furthermore, if a client generates a message without this TLV and 1075 receives an Error response with Error Code 7 (INTEGRITY TLV 1076 Required), the client SHOULD NOT send more messages without the 1077 INTEGRITY TLV to the same server within the same conference. 1079 When a client receives a BFCP message with an INTEGRITY TLV, it 1080 calculates the HMAC-SHA1 [1] of the message excluding the INTEGRITY 1081 TLV. The key used as input to HMAC is the secret shared between the 1082 server and the user identified by the USER-ID TLV in the message. If 1083 the resulting value is the same as the one in the INTEGRITY TLV, 1084 authentication is considered successful. If the resulting value is 1085 different than the one in the INTEGRITY TLV, authentication is 1086 considered to have failed and the message MUST NOT be processed 1087 further. 1089 10.2 Server Behavior 1091 Servers SHOULD add an INTEGRITY TLV to all their messages. 1092 Furthermore, if a client sends messages with this TLV to a server, 1093 the server MUST include it as well in its messages to this client. 1095 If a client does not add an INTEGRITY TLV to a message, the server 1096 MAY request its addition by returning an Error message with Error 1097 Code 7 (INTEGRITY TLV Required). 1099 When a server receives a BFCP message with an INTEGRITY TLV, it 1100 calculates the HMAC-SHA1 [1] of the message excluding the INTEGRITY 1101 TLV. The key used as input to HMAC is the secret shared between the 1102 server and the user identified by the USER-ID TLV in the message. If 1103 the resulting value is the same as the one in the INTEGRITY TLV, 1104 authentication is considered successful. 1106 If the resulting value is different than the one in the INTEGRITY 1107 TLV, authentication is considered to have failed, in which case the 1108 server SHOULD return an Error message with Error Code 1 1109 (Authentication Failed). Messages that cannot be authenticated MUST 1110 NOT be processed further. 1112 11. Client Operations 1114 This section specifies how clients can perform different operations, 1115 such as requesting a floor, using the protocol elements described in 1116 earlier sections. Chair operations, such as instructing the floor 1117 server to grant or revoke a floor, are described in Section 16. 1119 11.1 Requesting a Floor 1121 A client that wishes to request one or more floors does so by sending 1122 a FloorRequest message to the floor control server. The ABNF in 1123 Section 6.1 describes the TLVs that a FloorRequest message can 1124 contain. In addition, the ABNF specifies which of these TLVs are 1125 mandatory, and which ones are optional. 1127 The client sets the Conference ID in the FIXED-HEADER and the 1128 TRANSACTION-ID TLV following the rules given in Section 9.1. 1129 Additionally, the client follows the rules in Section 10.1 which 1130 relate to the authentication and the protection of the integrity of 1131 the message (i.e., to the INTEGRITY TLV). 1133 The client must insert a USER-ID TLV, which will be used by the 1134 server to authenticate and authorize the request. If the user 1135 sending the FloorRequest message (identified by the USER-ID TLV) is 1136 not the same as the user requesting the floor (i.e., a third party 1137 floor request), the client SHOULD add a BENEFICIARY-ID TLV to the 1138 message identifying the beneficiary of the floor. 1140 The client must insert at least one FLOOR-ID TLV in the FloorRequest 1141 message. If the client inserts more than one FLOOR-ID TLVs, the 1142 server will treat all the floor requests as an atomic package. That 1143 is, the floor control server will either grant or deny all the floors 1144 in the FloorRequest message. 1146 The client may use a HUMAN-READABLE-INFO TLV to state the reason why 1147 the floor or floors are being requested. The Text field in the 1148 HUMAN-READABLE-INFO TLV is intended for human consumption. 1150 The client may request the server to handle the floor request with a 1151 certain priority using a PRIORITY TLV. 1153 11.1.1 Receiving a Response 1155 A message from the server is considered to be a response to the 1156 FloorRequest message if the message from the server has the same 1157 Conference ID and Transaction ID as the FloorRequest message, as 1158 described in Section 9.1. 1160 If the response is a FloorRequestStatus message, the client obtains 1161 information about the status of the FloorRequest in a REQUEST-STATUS 1162 TLV. If the Request Status value is Granted, the client has been 1163 granted all the floors that were requested in the FloorRequest 1164 message. If the Request Status value is Denied, the client has been 1165 denied all the floors that were requested in the FloorRequest 1166 message. The HUMAN-READABLE-INFO TLV, if present, provides extra 1167 information which the client MAY display to the user. 1169 A floor request is considered to be ongoing while it is in the 1170 Pending, Accepted, or Granted states. FloorRequestStatus messages 1171 carrying any of these states will contain a FLOOR-REQUEST-ID TLV. 1172 The value of this TLV is used to match subsequent messages received 1173 at the client side (e.g., further FloorRequestStatus messages) or at 1174 the server side (e.g., a FloorRelease message) with this floor 1175 request. 1177 If the response is an Error message, the server could not process the 1178 FloorRequest message for some reason, which is described in the Error 1179 message. 1181 12. Requesting Information about Floor Requests 1183 Clients request information about the current status of one or 1184 several floor request by sending a FloorRequestInfo message to the 1185 floor control server. 1187 The client sets the Conference ID in the FIXED-HEADER and the 1188 TRANSACTION-ID TLV following the rules given in Section 9.1. 1189 Additionally, the client follows the rules in Section 10.1 which 1190 relate to the authentication and the protection of the integrity of 1191 the message (i.e., to the INTEGRITY TLV). The client must insert a 1192 USER-ID TLV, which will be used by the server to authenticate and 1193 authorize the request. 1195 If the client wants to request the status of a single floor request, 1196 it MUST insert a FLOOR-REQUEST-ID TLV that identifies the floor 1197 request at the server. 1199 The client can also request information about all the ongoing floor 1200 requests associated with a particular user. In this case, the client 1201 MUST NOT insert a FLOOR-REQUEST-ID TLV. If the beneficiary of the 1202 floor requests the client is requesting information about is not the 1203 client issuing the FloorRequestInfo message (which is identified by 1204 the USER-ID TLV in the message) the client SHOULD insert a 1205 BENEFICIARY-ID TLV. 1207 12.1 Receiving a Response 1209 On reception of the FloorRequestInfo message, the server will respond 1210 with a FloorRequestStatus message or with an error message. That is, 1211 the server will respond using the same message types as when it 1212 receives a FloorRequest message. Consequently, after sending the 1213 FloorRequestInfo message, the client follows the steps described in 1214 Section 11.1.1. 1216 If the FloorRequestInfo message requested information about several 1217 floor requests, the FloorRequestStatus message will contain 1218 information about all of them. 1220 13. Cancelling a Floor Request and Releasing a Floor 1222 A client that wishes to cancel an ongoing floor request does so by 1223 sending a FloorRelease message to the floor control server. The ABNF 1224 in Section 6.2 describes the TLVs that a FloorRelease message can 1225 contain. In addition, the ABNF specifies which of these TLVs are 1226 mandatory, and which ones are optional. 1228 The client sets the Conference ID in the FIXED-HEADER and the 1229 TRANSACTION-ID TLV following the rules given in Section 9.1. 1230 Additionally, the client follows the rules in Section 10.1 which 1231 relate to the authentication and the protection of the integrity of 1232 the message (i.e., to the INTEGRITY TLV). The client must insert a 1233 USER-ID TLV, which will be used by the server to authenticate and 1234 authorize the request. 1236 Note that the FloorRelease message is also used to release a floor 1237 or floors that were granted to the client (from the protocol 1238 perspective both are ongoing floor requests). Using the same 1239 message in both situations helps resolve the race condition that 1240 occurs when the FloorRelease message and the FloorGrant message 1241 cross each other on the wire. 1243 The client uses the FLOOR-REQUEST-ID that was received in the 1244 response to the FloorRequest message that the FloorRelease message is 1245 cancelling. 1247 13.1 Receiving a Response 1249 On reception of the FloorRelease message, the server will respond as 1250 with a FloorRequestStatus message or with an error message. That is, 1251 the server will respond using the same message types as when it 1252 receives a FloorRequest message. Consequently, after sending the 1253 FloorRelease message, the client follows the steps described in 1254 Section 11.1.1. 1256 It is possible that the FloorRelease message crosses on the wire with 1257 a FloorRequestStatus message from the server with a Request Status 1258 different from Cancelled. In any case, such a FloorRequestStatus 1259 message will not be a response to the FloorRelease message, because 1260 its Transaction ID will not match that of the FloorRelease. 1262 14. Requesting Information about Floors 1264 Clients request information about the status of one or several floors 1265 by sending a FloorInfo message to the floor control server. 1267 The client sets the Conference ID in the FIXED-HEADER and the 1268 TRANSACTION-ID TLV following the rules given in Section 9.1. 1269 Additionally, the client follows the rules in Section 10.1 which 1270 relate to the authentication and the protection of the integrity of 1271 the message (i.e., to the INTEGRITY TLV). The client must insert a 1272 USER-ID TLV, which will be used by the server to authenticate and 1273 authorize the request. 1275 The client inserts in the message all the FLOOR-IDs it wants to 1276 receive information about. The server will send periodic information 1277 about all these floors. If the client does not want to receive 1278 information about a particular floor any longer, it sends a new 1279 FloorInfo message removing the FLOOR-ID of this floor. If the client 1280 does not want to receive information about any floor, it sends a 1281 FloorInfo message with no FLOOR-ID TLV. 1283 14.1 Receiving a Response 1285 A message from the server is considered to be a response to the 1286 FloorInfo message if the message from the server has the same 1287 Conference ID and Transaction ID as the FloorRequest message, as 1288 described in Section 9.1. 1290 On reception of the FloorInfo message, the server will respond with a 1291 FloorStatus message or with an Error message. If the response is a 1292 FloorStatus message, it will contain information about one of the 1293 floors the client requested information about. If the client did not 1294 include any FLOOR-ID in its FloorInfo message, the FloorStatus 1295 message from the server will not include any either. 1297 After the first FloorStatus, the server will continue sending 1298 FloorStatus messages periodically informing the client about changes 1299 on the floors the client requested information about. 1301 15. Checking the Liveness of a Server 1303 A client that wishes to check the liveness of a server does so by 1304 sending a Ping message to the floor control server. The ABNF in 1305 Section 6.9 describes the TLVs that a Ping message can contain. In 1306 addition, the ABNF specifies which of these TLVs are mandatory, and 1307 which ones are optional. 1309 The client sets the Conference ID in the FIXED-HEADER and the 1310 TRANSACTION-ID TLV following the rules given in Section 9.1. 1311 Additionally, the client follows the rules in Section 10.1 which 1312 relate to the authentication and the protection of the integrity of 1313 the message (i.e., to the INTEGRITY TLV). 1315 15.1 Receiving Responses 1317 A message from the server is considered a response to the Ping 1318 message by the client if the message from the server has the same 1319 Conference ID and Transaction ID as the Ping message, as described in 1320 Section 9.1. 1322 If the response is a PingAck message, the server is alive and the 1323 user identified by the User ID was authenticated successfully. 1325 If the response is an Error message, the server could not process the 1326 Ping message for some reason, which is described in the Error 1327 message. 1329 16. Chair Operations 1331 This section specifies how clients acting as chairs can perform 1332 different operations, such as instructing the floor server to grant 1333 or revoke a floor, using the protocol elements described in earlier 1334 sections. 1336 16.1 Obtaining Information about Floor Requests 1338 A chair can obtain information about the floor requests that the 1339 floor control server receives in different ways, which include using 1340 out-of-band mechanisms. Chairs using BFCP to obtain such information 1341 use the procedures described in Section 14. As a result, they 1342 receive information about floor requests that relate to specific 1343 floors in FloorStatus messages from the floor control server. 1345 16.2 Instructing the Floor Control Server 1347 Chairs that wish to send instructions to a floor control server does 1348 so by sending a ChairAction message. The ABNF in Section 6.7 1349 describes the TLVs that a ChairAction message can contain. In 1350 addition, the ABNF specifies which of these TLVs are mandatory, and 1351 which ones are optional. 1353 The chair sets the Conference ID in the FIXED-HEADER and the 1354 TRANSACTION-ID TLV following the rules given in Section 9.1. 1355 Additionally, the chair follows the rules in Section 10.1 which 1356 relate to the authentication and the protection of the integrity of 1357 the message (i.e., to the INTEGRITY TLV). The client must insert a 1358 USER-ID TLV, which will be used by the server to authenticate and 1359 authorize the request. 1361 The ChairAction message contains instructions that apply to one or 1362 more floors within a particular floor request. The floor or floors 1363 are identified by FLOOR-ID TLVs and the floor request is identified 1364 by a FLOOR-REQUEST-ID TLV, which are carries in the ChairAction 1365 message. 1367 For example, if a floor request consists of two floors that depend 1368 on different chairs, each chair will grant its floor within the 1369 floor request. Once both chairs have grant their floor, the floor 1370 control server will grant the floor request as a whole. On the 1371 other hand, if one of the chairs denies its floor, the floor 1372 control server will deny the floor request as a whole, regardless 1373 of the other chair's decision. 1375 The chair provides the new status for one or more floors within the 1376 floor request using a REQUEST-STATUS TLV. If the new status of the 1377 floor request is Accepted, the chair MAY use the Queue Position field 1378 to provide a queue position for the floor request. If the chair does 1379 not wish to provide a queue position, all the bits of the Queue 1380 Position field SHOULD be set to zero. The chair SHOULD use the 1381 Status Revoked to revoke a floor that was granted (i.e., Granted 1382 status) and to reject floor requests in any other status (e.g., 1383 Pending and Accepted). 1385 Note a floor request may involve several floors and that a 1386 ChairAction message could only deal with a subset of these floors 1387 (e.g., if a single chair is not authorized to manage all the 1388 floors). In this case, the REQUEST-STATUS that the chair provides 1389 in the ChairAction message might not be the actual status that the 1390 floor request gets at the server. The floor control server will 1391 combine the instructions received from the different chairs to 1392 come up with the actual status of the floor request. 1394 The chair may use a HUMAN-READABLE-INFO TLV to state the reason why 1395 the floor or floors are being accepted, granted, or revoked. The 1396 Text in the HUMAN-READABLE-INFO TLV is intended for human 1397 consumption. 1399 16.2.1 Receiving a Response 1401 A message from the server is considered to be a response to the 1402 ChairAction message if the message from the server has the same 1403 Conference ID and Transaction ID as the ChairAction message, as 1404 described in Section 9.1. 1406 A ChairActionAck message from the server confirms that the server has 1407 accepted the ChairAction message. An Error message indicates that 1408 the server could not process the ChairAction message for some reason, 1409 which is described in the Error message. 1411 17. Server Operations 1413 This section specifies how servers can perform different operations, 1414 such as granting a floor, using the protocol elements described in 1415 earlier sections. 1417 On reception of a message from a client, the floor control server 1418 MUST check whether or not the value of the Conference ID matched an 1419 existing conference. If it does not, the floor server SHOULD send an 1420 Error message, as described in Section 17.7, with Error code 0 1421 (Conference does not Exist). 1423 On reception of a message from a client, the floor control server 1424 follows the rules in Section 10.2, which relate to the authentication 1425 of the message. 1427 On reception of a message from a client, the floor control server 1428 MUST check whether or not it understands all the mandatory ( 'M' bit 1429 set) TLVs in the message. If the server does not understand all of 1430 them, the floor server SHOULD send an Error message, as described in 1431 Section 17.7, with Error code 2 (Authentication Failed). The Error 1432 message SHOULD list the TLVs that were not understood. 1434 OPEN ISSUE: can servers use new mandatory TLVs in their messages? 1435 Right now we do not have a way for clients to complain about 1436 unsupported TLVs received from the server. 1438 17.1 Reception of a FloorRequest Message 1440 The processing of a FloorRequest message by a server involves 1441 generating a FloorRequestStatus message. The floor control server 1442 SHOULD generate a FloorRequestStatus message as soon as possible. If 1443 the floor server cannot accept, grant, or deny the floor request 1444 right away (e.g., a decision from a chair is needed), it SHOULD use a 1445 Request Status value of Pending. 1447 The server copies the Conference ID and the TRANSACTION-ID TLV from 1448 the FloorRequest into the FloorRequestStatus, as described in Section 1449 9.2. Additionally, the server MUST assign an identitifier that is 1450 unique within the conference to this floor request, and insert it in 1451 a FLOOR-REQUEST-ID TLV into the FloorRequestStatus message. This 1452 indentifier will be used by the client to refer to this specific 1453 floor request in the future. 1455 The server follows the rules in Section 10.2 which relate to 1456 authentication and the use of the INTEGRITY TLV. 1458 At later time, when the status of the floor request changes, the 1459 floor control server SHOULD send a new FloorRequestStatus message 1460 with the appropriate Request Status. This FloorRequestStatus message 1461 MUST contain a FLOOR-REQUEST-ID TLV identifying the floor request, 1462 but MUST NOT contain any TRANSACTION-ID TLV. The server may add a 1463 HUMAN-READABLE-INFO TLV to provide extra information to the user 1464 about its decision. 1466 The rate at which the floor control server sends 1467 FloorRequestStatus messages is a matter of local policy. A server 1468 may choose to send a new FloorRequestStatus message every time the 1469 floor request moves in the floor request queue while another may 1470 choose to only send a new FloorRequestStatus message when the 1471 floor request is Granted or Denied. 1473 Clients and chairs that request so need to be informed about changes 1474 in the status of a floor (e.g., a new floor request arrives). To 1475 accomplish this, the floor control server follows the rules in 1476 Section 17.4. 1478 17.2 Reception of a FloorRequestInfo Message 1480 The processing of a FloorRequestInfo message by a server involves 1481 generating a FloorRequestStatus message. The FloorRequestInfo 1482 message can apply to a single floor request, identified by a 1483 FLOOR-REQUEST-ID, or to all the floor requests from a given user, the 1484 FloorRequestInfo does not carry a FLOOR-REQUEST-ID. The user is 1485 identified by a BENEFICIARY-ID TLV, or if this is not present, by a 1486 USER-ID TLV. 1488 If the FloorRequestInfo message contains an invalid FLOOR-REQUEST-ID, 1489 the floor control server SHOULD respond with an Error response with 1490 Error Code 3 (Floor Request ID Does Not Exist). 1492 On reception of a FloorRequestInfo message, the floor control server 1493 SHOULD generate a FloorRequestStatus message as soon as possible. 1495 The server copies the Conference ID and the TRANSACTION-ID TLV from 1496 the FloorRequestInfo message into the FloorRequestStatus, as 1497 described in Section 9.2. 1499 The server follows the rules in Section 10.2 which relate to 1500 authentication and the use of the INTEGRITY TLV. 1502 17.3 Reception of a FloorRelease Message 1504 The processing of a FloorRelease message by a server involves 1505 generating a FloorRequestStatus message. The FloorRelease message 1506 identifies the floor request it applies to using a FLOOR-REQUEST-ID. 1508 If the FloorRelease message contains an invalid FLOOR-REQUEST-ID, the 1509 floor control server SHOULD respond with an Error response with Error 1510 Code 3 (Floor Request ID Does Not Exist). 1512 On reception of a FloorRelease message with a valid FLOOR-REQUEST-ID, 1513 the floor control server SHOULD generate a FloorRequestStatus message 1514 as soon as possible. If the floor server can authorize the release 1515 operation right away, it SHOULD use a Request Status value of 1516 Released, if the floor had been previously granted, or of Cancelled, 1517 if it had not. The server may add a HUMAN-READABLE-INFO TLV to 1518 provide extra information to the user about its decision. 1520 The server copies the Conference ID and the TRANSACTION-ID TLV from 1521 the FloorRelease into the FloorRequestStatus, as described in Section 1522 9.2. 1524 The server follows the rules in Section 10.2 which relate to 1525 authentication and the use of the INTEGRITY TLV. 1527 17.4 Reception of a FloorInfo Message 1529 A server receiving a FloorInfo message from a client SHOULD keep this 1530 client informed about the status of the floors identified by 1531 FLOOR-IDs in the FloorInfo message. Servers keep clients informed by 1532 using FloorStatus messages. 1534 The information FloorInfo messages carry may depend on the user 1535 requesting the information. For example, a chair may be able to 1536 receive information about pending requests while a regular user may 1537 not be authorized to do so. 1539 The server may provide information about a number of floor requests 1540 in a single FloorInfo message. For each floor request, the server 1541 provides its FLOOR-REQUEST-ID and its REQUEST-STATUS, and may provide 1542 further information such as its BENEFICIARY-ID. 1544 On reception of a FloorInfo message with one or more FLOOR-ID TLVs, 1545 the server generates a FloorStatus message for one of the floors 1546 identified in the FloorInfo message. 1548 The server copies the Conference ID and the TRANSACTION-ID TLV from 1549 the FloorInfo message into the FloorStatus message, as described in 1550 Section 9.2. 1552 The server follows the rules in Section 10.2 which relate to 1553 authentication and the use of the INTEGRITY TLV. 1555 After sending this message, the server SHOULD continue sending 1556 FloorStatus messages about all the floors the client requested 1557 information about. These messages MUST NOT carry a TRANSACTION-ID 1558 TLV. 1560 The rate at which the floor control server sends FloorStatus 1561 messages is a matter of local policy. A server may choose to send 1562 a new FloorRequestStatus message every time a new floor request 1563 arrives while another may choose to only send a new FloorStatus 1564 message when a new floor request is Granted. 1566 17.5 Reception of a ChairAction Message 1568 On reception of a ChairAction message, the floor control server 1569 checks whether the chair that send the message is authorized to 1570 perform the operation being requested. If the chair is authorized, 1571 the floor control server performs the operation and sends a 1572 ChairActionAck message to the client. If the new Status in the 1573 ChairAction message is Accepted and all the bits of the Queue 1574 Position field are zero, the server assigns a queue position (e.g., 1575 the last in the queue) to the floor request based on local policy (in 1576 case the server implements a queue). 1578 The server copies the Conference ID and the TRANSACTION-ID TLV from 1579 the ChairAction message into the ChairActionAck message, as described 1580 in Section 9.2. 1582 The server follows the rules in Section 10.2 which relate to 1583 authentication and the use of the INTEGRITY TLV. 1585 If the floor control server cannot find a floor request that matches 1586 the FLOOR-REQUEST-ID TLV in the ChairAction message the floor control 1587 server generates an Error message, as described in Section 17.7, with 1588 an Error code with a value of 3 (Floor Request ID Does Not Exist). 1590 If the chair is not authorized to perform the operation being 1591 requested, the floor control server generates an Error message, as 1592 described in Section 17.7, with an Error code with a value of 4 1593 (Unauthorized Operation). 1595 17.6 Reception of a Ping Message 1597 The processing of a Ping message by a server involves generating a 1598 PingAck message. On reception of a Ping message, the floor control 1599 server SHOULD generate a PingAck message as soon as possible. The 1600 server copies the Conference ID and the TRANSACTION-ID TLV from the 1601 Ping into the PingAck, as described in Section 9.2. 1603 The server follows the rules in Section 10.2 which relate to 1604 authentication and the use of the INTEGRITY TLV. 1606 17.7 Error Message Generation 1608 Error messages are always sent in response to a previous message from 1609 the client as part of a client-initiated transaction. The ABNF in 1610 Section 6.11 describes the TLVs that an Error message can contain. 1611 In addition, the ABNF specifies which of these TLVs are mandatory, 1612 and which ones are optional. 1614 Servers copy the Conference ID and the TRANSACTION-ID TLV from the 1615 message from the client into the Error message, as described in 1616 Section 9.2. 1618 The server follows the rules in Section 10.2 which relate to 1619 authentication and the use of the INTEGRITY TLV. 1621 18. BFCP and the Offer/Answer Model 1623 The way a client obtains a the information needed to contact a BFCP 1624 floor control server is outside the scope of BCFP. Nevertheless, 1625 this section describes how to obtain such an information using an SDP 1626 [5] offer/answer [11] exchange. 1628 User agents typically use the offer/answer model to establish a 1629 number of media streams of different types. Following this model, a 1630 BFCP connection is described as any other media stream by using an 1631 SDP m line. 1633 18.1 Fields in the m Line 1635 According to RFC 2327 [5], the m-line format is the following: 1637 m= 1639 The media field MUST have a value of "application". The port field 1640 is not used by BFCP, and MAY be set to any value chosen by the 1641 endpoint. A port field value of zero has the standard SDP meaning 1642 (i.e., rejection of the media stream). 1644 The port field is set following the rules in [14]. Depending on the 1645 value of the setup attribute (disccused in Section 18.4), the port 1646 field contains the port the remote endpoint will initiate its TCP 1647 connection to, or is irrelevant (i.e., the endpoint will initiate the 1648 connection towards the remote endpoint) and should be set to a value 1649 of 9, which is the discard port. Since BFCP only runs on top of TCP, 1650 the port is always a TCP port. 1652 We define two new values for the transport field: TCP/BFCP and TCP/ 1653 TLS/BFCP. 1655 The fmt (format) list is ignored for BFCP. The fmt list of BFCP m 1656 lines SHOULD contain a single "*" character. 1658 The following is an example of an m line for a BFCP connection: 1660 m=application 20000 TCP/BFCP * 1662 18.2 The confid and userid SDP Parameters 1664 We define the confid and the userid SDP media-level attributes. 1665 Their syntax is: 1667 confid-attribute = "a=confid: " conference-id 1668 conference-id = token 1670 userid-attribute = "a=userid: " user-id 1671 user-id = token 1673 The confid and the userid attributes carry the integer representation 1674 of a conference ID and a user ID respectively. 1676 Endpoints which use the offer/answer model to establish BFCP 1677 connections MUST support the confid and the userid attributes. A 1678 floor control server acting as an offerer or as an answerers SHOULD 1679 include these attributes in its session descriptions. 1681 18.3 The k line 1683 If the offer/answer exchange is encrypted and integrity protected, 1684 the offerer MAY use an SDP k line to provide the answerer with a 1685 shared secret to be used to calculate the value of the INTEGRITY 1686 TLVs. The following is an example of a k line: 1688 k=base64:c2hhcmVkLXNlY3JldA== 1690 18.4 TCP Connection Management 1692 The management of the TCP connection used to transport BFCP is 1693 performed using the setup and connid attributes as defined in [14]. 1695 The setup attribute indicates which of the endpoints (client or floor 1696 control server) initiates the TCP connection. The connid attribute 1697 handles TCP connection reestablishment. 1699 Editor's note: need to address loss and re-establishment of TCP 1700 connections. 1702 18.5 Association between Streams and Floors 1704 EDITOR'S NOTE: We need a way for clients that don't support CPCP to 1705 at a minimum learn enough information about floors to use the floor 1706 control protocol. This section will need to be harmonized with the 1707 media policy work. 1709 We define the floorid SDP media-level attribute. Its syntax is: 1711 floor-id-attribute = "a=floorid:" token " mstream:" 1*(token) 1713 The floorid attribute is used in BFCP m lines and associates a floor 1714 ID with a media stream. The token representing the floor ID is the 1715 integer representation of the 16-bit floorid to be used in BFCP. The 1716 token representing the media stream is a pointer to the media stream, 1717 which is identified by an SDP label attribute 1718 [draft-levin-mmmusic-sdp-media-label-00.txt]. 1720 Endpoints which use the offer/answer model to establish BFCP 1721 connections MUST support the floorid and the label attributes. A 1722 floor control server acting as an offerer or as an answerers SHOULD 1723 include these attributes in its session descriptions. 1725 18.6 Example 1727 The following is an example of an offer sent by a conference server 1728 to a user. For the purpose of brevity, the main portion of the 1729 session description is omitted in the examples, which only show m= 1730 lines and their attributes. 1732 m=application 20000 TCP/BFCP * 1733 k=base64:c2hhcmVkLXNlY3JldA== 1734 a=setup:passive 1735 a=connid:1 1736 a=confid:4321 1737 a=userid:1234 1738 a=floorid:1 m-stream:10 1739 a=floorid:2 m-stream:11 1740 m=audio 20000 RTP/AVP 0 1741 a=label:10 1742 m=video 30000 RTP/AVP 31 1743 a=label:11 1745 The following is the answer returned by the user. 1747 m=application 9 TCP/BFCP * 1748 a=setup:active 1749 a=connid:1 1750 m=audio 25000 RTP/AVP 0 1751 m=video 35000 RTP/AVP 31 1753 19. Security Considerations 1755 TBD. 1757 20. IANA Considerations 1759 TBD 1761 20.1 SDP Attributes Registration 1763 TBD: 1765 21. Acknowledgments 1767 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 1768 ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, 1769 Jonathan Rosenberg, and Miguel A. Garcia-Martin provided useful 1770 comments. 1772 22. References 1774 22.1 Normative References 1776 [1] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 1777 for Message Authentication", RFC 2104, February 1997. 1779 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1780 Levels", BCP 14, RFC 2119, March 1997. 1782 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1783 Specifications: ABNF", RFC 2234, November 1997. 1785 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1786 2246, January 1999. 1788 [5] Handley, M. and V. Jacobson, "SDP: Session Description 1789 Protocol", RFC 2327, April 1998. 1791 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1792 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1793 1998. 1795 [7] Petke, R. and I. King, "Registration Procedures for URL Scheme 1796 Names", BCP 35, RFC 2717, November 1999. 1798 [8] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 1799 IPv6 Addresses in URL's", RFC 2732, December 1999. 1801 [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1802 specifying the location of services (DNS SRV)", RFC 2782, 1803 February 2000. 1805 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1806 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1807 Session Initiation Protocol", RFC 3261, June 2002. 1809 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 1810 Session Description Protocol (SDP)", RFC 3264, June 2002. 1812 [12] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 1813 Three: The Domain Name System (DNS) Database", RFC 3403, 1814 October 2002. 1816 [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 1817 63, RFC 3629, November 2003. 1819 [14] Yon, D., "Connection-Oriented Media Transport in the Session 1820 Description Protocol (SDP)", draft-ietf-mmusic-sdp-comedia-08 1821 (work in progress), July 2004. 1823 22.2 Informational References 1825 [15] Schulzrinne, H., "Requirements for Floor Control Protocol", 1826 draft-ietf-xcon-floor-control-req-01 (work in progress), July 1827 2004. 1829 [16] Koskelainen, P. and H. Khartabil, "An Extensible Markup 1830 Language (XML) Configuration Access Protocol (XCAP) Usage for 1831 Conference Policy Manipulation", 1832 draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress), 1833 February 2004. 1835 [17] Rosenberg, J. and H. Schulzrinne, "A Session Initiation 1836 Protocol (SIP) Event Package for Conference State", 1837 draft-ietf-sipping-conference-package-05 (work in progress), 1838 July 2004. 1840 [18] Arkko, J., "MIKEY: Multimedia Internet KEYing", 1841 draft-ietf-msec-mikey-08 (work in progress), December 2003. 1843 [19] Rosenberg, J., "An Extensible Markup Language (XML) Document 1844 Format for Indicating Changes in XML Configuration Access 1845 Protocol (XCAP) Resources", draft-ietf-simple-xcap-package-02 1846 (work in progress), July 2004. 1848 Authors' Addresses 1850 Gonzalo Camarillo 1851 Ericsson 1852 Hirsalantie 11 1853 Jorvas 02420 1854 Finland 1856 EMail: Gonzalo.Camarillo@ericsson.com 1858 Joerg Ott 1859 Universitaet Bremen 1860 MZH 5180 1861 Bibliothekstr. 1 1862 Bremen D-28359 1863 Germany 1865 EMail: jo@tzi.org 1867 Keith Drage 1868 Lucent Technologies 1869 Windmill Hill Business Park 1870 Swindon 1871 Wiltshire SN5 6PP 1872 UK 1874 EMail: drage@lucent.com 1876 Intellectual Property Statement 1878 The IETF takes no position regarding the validity or scope of any 1879 Intellectual Property Rights or other rights that might be claimed to 1880 pertain to the implementation or use of the technology described in 1881 this document or the extent to which any license under such rights 1882 might or might not be available; nor does it represent that it has 1883 made any independent effort to identify any such rights. Information 1884 on the procedures with respect to rights in RFC documents can be 1885 found in BCP 78 and BCP 79. 1887 Copies of IPR disclosures made to the IETF Secretariat and any 1888 assurances of licenses to be made available, or the result of an 1889 attempt made to obtain a general license or permission for the use of 1890 such proprietary rights by implementers or users of this 1891 specification can be obtained from the IETF on-line IPR repository at 1892 http://www.ietf.org/ipr. 1894 The IETF invites any interested party to bring to its attention any 1895 copyrights, patents or patent applications, or other proprietary 1896 rights that may cover technology that may be required to implement 1897 this standard. Please address the information to the IETF at 1898 ietf-ipr@ietf.org. 1900 Disclaimer of Validity 1902 This document and the information contained herein are provided on an 1903 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1904 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1905 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1906 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1907 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1908 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1910 Copyright Statement 1912 Copyright (C) The Internet Society (2004). This document is subject 1913 to the rights, licenses and restrictions contained in BCP 78, and 1914 except as set forth therein, the authors retain all their rights. 1916 Acknowledgment 1918 Funding for the RFC Editor function is currently provided by the 1919 Internet Society.