idnits 2.17.1 draft-camarillo-xcon-bfcp-00.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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1325. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1315. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1331), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (April 2004) is 7309 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: 'PRIORITY' on line 524 -- Looks like a reference, but probably isn't: 'USER-DISPLAY-NAME' on line 525 -- Looks like a reference, but probably isn't: 'USER-URI' on line 526 -- Looks like a reference, but probably isn't: 'HUMAN-READABLE-INFO' on line 527 -- Looks like a reference, but probably isn't: 'TOKEN' on line 567 ** 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 2396 (ref. '4') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2717 (ref. '5') (Obsoleted by RFC 4395) ** Obsolete normative reference: RFC 2732 (ref. '6') (Obsoleted by RFC 3986) == Outdated reference: A later version (-03) exists of draft-ietf-xcon-floor-control-req-00 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-03 Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 11 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: September 30, 2004 J. Ott 5 Universitaet Bremen 6 K. Drage 7 Lucent Technologies 8 April 2004 10 The Binary Floor Control Protocol (BFCP) 11 draft-camarillo-xcon-bfcp-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 30, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document specicies the Binary Floor Control Protocol (BFCP). 44 BFCP is used between conference participants and floor control 45 servers, and between floor chairs and floor control servers. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 52 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5 53 4.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 5 54 4.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 6 55 4.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 7 57 4.2.3 REQUEST-ID . . . . . . . . . . . . . . . . . . . . . . 7 58 4.2.4 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 7 59 4.2.5 TOKEN . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.2.6 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 8 61 4.2.7 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 9 62 4.2.8 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 11 63 4.2.9 USER-URI . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.2.10 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 11 65 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . . . 11 67 5.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.3 FloorRequestStatus . . . . . . . . . . . . . . . . . . . . 12 69 5.4 FloorStatus . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.5 ChairAction . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.6 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.7 PingAck . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5.8 Error . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6. bfcp and bfcps URI Definitions . . . . . . . . . . . . . . . 14 75 7. Contacting a bfcp or bfcps URI . . . . . . . . . . . . . . . 15 76 7.1 Selecting a Transport Protocol . . . . . . . . . . . . . . 15 77 7.2 Determining Port and IP Address . . . . . . . . . . . . . 16 78 7.3 Lower-Layer Security . . . . . . . . . . . . . . . . . . . 17 79 7.4 Conference ID, User ID, and Token Values . . . . . . . . . 17 80 8. Client Operations . . . . . . . . . . . . . . . . . . . . . 18 81 8.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . . 18 82 8.1.1 Receiving Responses . . . . . . . . . . . . . . . . . 19 83 8.2 Cancelling a Floor Request . . . . . . . . . . . . . . . . 19 84 8.2.1 Receiving Responses . . . . . . . . . . . . . . . . . 20 85 8.3 Releasing Floors . . . . . . . . . . . . . . . . . . . . . 20 86 8.3.1 Receiving Responses . . . . . . . . . . . . . . . . . 21 87 8.4 Checking the Liveness of a Server . . . . . . . . . . . . 21 88 8.4.1 Receiving Responses . . . . . . . . . . . . . . . . . 21 89 8.5 Responding to a Ping Message . . . . . . . . . . . . . . . 22 90 9. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 22 91 9.1 Obtaining Information about Floor Requests . . . . . . . . 22 92 9.2 Instructing the Floor Control Server . . . . . . . . . . . 22 93 10. Server Operations . . . . . . . . . . . . . . . . . . . . . 23 94 10.1 Reception of a FloorRequest Message . . . . . . . . . . 23 95 10.2 Checking the Liveness of a Client or Chair . . . . . . . 24 96 10.2.1 Receiving a PingAck Message . . . . . . . . . . . . 25 97 10.3 Responding to a Ping Message . . . . . . . . . . . . . . 25 98 10.4 Informing about the Status of a Floor . . . . . . . . . 25 99 10.5 Receiving a ChairAction Message . . . . . . . . . . . . 25 100 10.6 Error Message Generation . . . . . . . . . . . . . . . . 26 101 11. Security Considerations . . . . . . . . . . . . . . . . . . 26 102 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 103 12.1 bfcp and bfcps URI Schemes Registration . . . . . . . . 26 104 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 105 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 14.1 Normative References . . . . . . . . . . . . . . . . . . . 27 107 14.2 Informational References . . . . . . . . . . . . . . . . . 28 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 109 Intellectual Property and Copyright Statements . . . . . . . 30 111 1. Introduction 113 Conference applications may need to manage the access to a set of 114 shared resources such as the right to send media over a particular 115 media stream. Floor control enables such applications to provide 116 users with safe access to these resources. 118 The Requirements for Floor Control Protocol [11] list a set of 119 requirements that need to be met by floor control protocols. The 120 Binary Floor Control Protocol (BFCP), which is specified in this 121 document, meets these requirements. 123 BFCP provides a means for a floor control server to grant or deny 124 requests to access a given resource from users. Nevertheless, BFCP 125 does not allow floor control servers to keep a particular user or set 126 of users from actually accessing the resource. Enforcing policy 127 decisions is outside the scope of BFCP. In any case, one possible way 128 to implement policy enforcement is to have the floor control server 129 provide the conference policy server (e.g., using CPCP [12]) with 130 policies that the conference policy server will apply to the 131 conference. 133 Floor control servers identify users using a 32-bit user ID. The way 134 a conference server provides a user with its 32-bit user ID is out of 135 the scope of this document. 137 BFCP assumes that conference servers, after authenticating a user, 138 provides this user with a token, in addition to the user's user ID. 139 The user's client needs to include this token in its requests to 140 prove that they belong to the same user as the conference server 141 authenticated previously. The way a conference server provides a user 142 with such a token in a secure fashion falls outside the scope of this 143 document. 145 Section 2 defines the terminology used throughout this document, 146 Section 3 provides a non-normative overview of BFCP operation, and 147 subsequent sections provide the normative specification of BFCP. 149 2. Terminology 151 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 152 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 153 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 154 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 155 compliant implementations. 157 Floor: A permission to temporarily access or manipulate a specific 158 shared resource or set of resources. 160 Floor chair: A user (or an entity) who manages one floor (grants, 161 denies, or revokes a floor). The floor chair does not have to be a 162 member in a conference. 164 Floor control: A mechanism that enables applications or users to gain 165 safe and mutually exclusive or non-exclusive input access to the 166 shared object or resource. 168 Floor control server: A logical entity that maintains the state of 169 the floor(s) including which floors exists, who the floor chairs are, 170 who holds a floor, etc. Requests to manipulate a floor are directed 171 at the floor control server. 173 3. Overview of Operation 175 TBD: the Introduction and this section need more work. 177 4. Packet Format 179 BFCP packets consist of an 8-byte fixed header followed by 180 attributes. All the protocol values MUST be sent in network byte 181 order. 183 4.1 FIXED-HEADER Format 185 The following is the FIXED-HEADER format. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Ver |Reserved | Primitive | Payload Length | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Conference ID | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Ver: the 3-bit version field MUST be set to 1 to indicate this 196 version of BFCP. 198 Reserved: at this point, the 5 bits in the reserved field SHOULD be 199 set to zero by the sender of the message and MUST be ignored by the 200 receiver. 202 Primitive: this 8-bit field identifies the main purpose of the 203 message. The following primitive values are defined: 205 Value Primitive Direction 206 _________________________________________________________ 207 0 FloorRequest C -> S 208 1 FloorRelease C -> S 209 2 FloorRequestStatus S -> C 210 3 FloorStatus S -> C ; S -> Ch 211 4 ChairAction Ch -> S 212 5 Ping C <-> S ; Ch <-> S 213 6 PingAck C <-> S ; Ch <-> S 214 7 Error S -> C ; S -> Ch 216 S: Server C: Client Ch: Chair 218 Payload Length: this 16-bit field contains length of the message in 219 4-byte units excluding the fixed header. 221 Conference ID: this 32-bit identifies the conference the message 222 belongs to. 224 4.2 Attribute Format 226 BFCP attributes are encoded in TLV (Type-Length-Value) format. TLVs 227 are 32-bit aligned. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type |M| Length | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 234 | | 235 / Attribute Contents / 236 / / 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Type: this 7-bit field contains the code for the attribute. 242 M: the 'M' bit, known as the Mandatory bit, indicates whether support 243 of the attribute is required. If an unrecognized attribute with the 244 'M' bit set is received, the message is rejected. 246 Length: this 8-bit field contains the length of the attribute in 247 bytes, excluding any padding defined for specific attributes. The 248 Type, 'M' bit, and Length fields are included. 250 Attribute Contents: the contents of the different TLVs are defined in 251 the following sections. 253 4.2.1 FLOOR-ID 255 The following is the format of the contents of the FLOOR-ID 256 attribute, whose attribute type is 1. 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type = 1 |M| Length | Floor ID | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Floor ID: this field contains a 16-bit value that uniquely identifies 265 a floor within a conference. 267 4.2.2 USER-ID 269 The following is the format of the contents of the USER-ID attribute, 270 whose attribute type is 2. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type = 2 |M| Length | User ID | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 User ID: this field contains a 16-bit value that uniquely identifies 279 a user within a conference. 281 4.2.3 REQUEST-ID 283 The following is the format of the contents of the REQUEST-ID 284 attribute, whose attribute type is 3. 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type = 3 |M| Length | Request ID | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Request ID: this field contains a 16-bit value that allows users to 293 match a given message with its responses. 295 4.2.4 HUMAN-READABLE-INFO 297 The following is the format of the contents of the 298 HUMAN-READABLE-INFO attribute, whose attribute type is 4. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type = 4 |M| Length | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 305 | | 306 / Text / 307 / +-+-+-+-+-+-+-+-+ 308 | | Padding | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Text: this field contains UTF-8 [10] encoded text. 313 In some situations, the contents of the Text field may be generated 314 by an automata. If such automata has information about the preferred 315 language of the receiver of a particular HUMAN-READABLE-INFO TLV, it 316 may use this language to generate the Text field. 318 Padding: one, two, or three bytes of padding added so that the 319 contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned. The 320 Padding bits SHOULD be set to zero by the sender and MUST be ignored 321 by the receiver. If the TLV is already 32-bit aligned, no padding is 322 needed. 324 4.2.5 TOKEN 326 The following is the format of the contents of the TOKEN attribute, 327 whose attribute type is 5. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type = 5 |M| Length | Token | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Token: this field contains a 16-bit token used to authenticate the 336 user. 338 4.2.6 REQUEST-STATUS 340 The following is the format of the contents of the REQUEST-STATUS 341 attribute, whose attribute type is 6. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type = 6 |M| Length | Request Status | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Queue Position | Padding | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Request Status: this 16-bit field contains the status of the request, 352 as described in the following table. 354 Value Status 355 ______________________________ 356 0 Pending 357 1 Accepted 358 2 Granted 359 3 Denied 360 4 Cancelled 361 5 Released 362 6 Revoked 364 Queue Position: this 16-bit field contains, when applicable, the 365 position of the floor request in the floor request queue at the 366 server. If the Request Status value is different from Accepted, the 367 floor control server does not implement a floor request queue, or the 368 floor control server does not want to provide the client with this 369 information, all the bits of this field SHOULD be set to zero. 371 A floor request is in Pending state if the floor control server needs 372 to contact a floor chair in order to accept the floor request, but 373 has not done it yet. Once the floor control chair accepts the floor 374 request, the floor request is moved to the Accepted state. 376 Padding: two bytes of padding added so that the contents of the 377 REQUEST-STATUS TLV is 32-bit aligned. The Padding bits SHOULD be set 378 to zero by the sender and MUST be ignored by the receiver. 380 4.2.7 ERROR-CODE 382 The following is the format of the contents of the ERROR-CODE 383 attribute, whose attribute type is 7. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type = 7 |M| Length | Error Code | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 | Error Specific Details | 392 / / 393 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | Padding | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Error Code: this 16-bit field contains an error code from the 398 following table. 400 Value Meaning 401 ______________________________ 402 0 Conference does not Exist 403 1 Authentication Failed 404 2 Unknown Mandatory TLV 405 3 Floor Request does not Exist 406 4 Unauthorized Operation 407 5 User does not Exist 408 6 Invalid Request-ID 410 Error Specific Details: Present only for certain Error Codes. In this 411 document, only for Error Code 2 (Unknown Mandatory TLV). For Error 412 Code 2, this field contains the Types of the TLVs (which were present 413 in the message that triggered the Error message) that were unknown to 414 the receiver, encoded as follows. 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Unknown TLV Type | Unknown TLV Type | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | Unknown TLV Type | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Unknown TLV Type | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Padding: one, two, or three bytes of padding added so that the 429 contents of the ERROR-CODE TLV is 32-bit aligned. If the TLV is 430 already 32-bit aligned, no padding is needed. 432 The Padding bits SHOULD be set to zero by the sender and MUST be 433 ignored by the receiver. Note all the Error Codes defined in this 434 document but Error Code 2, result in a TLV which is already 32-bit 435 aligned (i.e., no need of padding). Error Code 2 results in a TLV 436 that may need 2 bytes of padding. 438 4.2.8 USER-DISPLAY-NAME 440 The USER-DISPLAY-NAME attribute type is 8 and its format is the same 441 as the HUMAN-READABLE-INFO attribute. The Text field in the 442 USER-DISPLAY-NAME attribute contains the name of the user. 444 4.2.9 USER-URI 446 The USER-URI attribute type is 9 and its format is the same as the 447 HUMAN-READABLE-INFO attribute. The Text field in the USER-URI 448 attribute contains the URI of the user. 450 4.2.10 PRIORITY 452 The following is the format of the contents of the PRIORITY 453 attribute, whose attribute type is 10. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type = 7 |M| Length | Priority | Reserved | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Priority: the higher the 8-bit value, the more priority is requested 462 for a given floor request. 464 Reserved: at this point, the 8 bits in the reserved field SHOULD be 465 set to zero by the sender of the message and MUST be ignored by the 466 receiver. 468 5. Message Format 470 This section contains the ABNF [2] of the BFCP messages. 472 5.1 FloorRequest 474 Clients request a floor by sending a FloorRequest message to the 475 floor control server. The following is the format of the FloorRequest 476 message: 478 FloorRequest = (FIXED-HEADER) 479 (REQUEST-ID) 480 1*(FLOOR-ID) 481 (USER-ID) 482 (TOKEN) 483 [PRIORITY] 484 [USER-DISPLAY-NAME] 485 [USER-URI] 486 [HUMAN-READABLE-INFO] 488 5.2 FloorRelease 490 Clients release a floor by sending a FloorRelease message to the 491 floor control server. Clients also use the FloorRelease message to 492 cancel pending floor requests. The following is the format of the 493 FloorRelease message: 495 FloorRelease = (FIXED-HEADER) 496 (REQUEST-ID) 497 1*(FLOOR-ID) 498 (USER-ID) 499 (TOKEN) 501 5.3 FloorRequestStatus 503 The floor control server informs clients about the status of their 504 floor requests by sending them FloorRequestStatus messages. The 505 following is the format of the FloorRelease message: 507 FloorRequestStatus = (FIXED-HEADER) 508 (REQUEST-ID) 509 1*(FLOOR-ID) 510 (USER-ID) 511 (REQUEST-STATUS) 513 5.4 FloorStatus 515 The floor control server informs clients about the holder of a floor 516 by sending them FloorStatus messages. The following is the format of 517 the FloorStatus message: 519 FloorStatus = (FIXED-HEADER) 520 (FLOOR-ID) 521 *( (REQUEST-ID) 522 (USER-ID) 524 [PRIORITY] 525 [USER-DISPLAY-NAME] 526 [USER-URI] 527 [HUMAN-READABLE-INFO] 528 (REQUEST-STATUS) ) 530 5.5 ChairAction 532 Chairs send instructions to floor control servers by sending 533 ChairAction messages. The following is the format of the ChairAction 534 message: 536 ChairAction = (FIXED-HEADER) 537 (REQUEST-ID) 538 (USER-ID) 539 (TOKEN) 540 (FLOOR-ID) 541 (REQUEST-ID) 542 (USER-ID) 543 (REQUEST-STATUS) 544 [HUMAN-READABLE-INFO] 546 5.6 Ping 548 Clients check the liveness of servers, and servers of clients, by 549 sending a Ping message. The following is the format of the Ping 550 message: 552 Ping = (FIXED-HEADER) 553 (REQUEST-ID) 554 (USER-ID) 555 (TOKEN) 557 5.7 PingAck 559 Clients and servers confirm that they are alive on reception of a 560 Ping message by sending a PingAck message. The following is the 561 format of the PingAck message: 563 PingAck = (FIXED-HEADER) 564 (REQUEST-ID) 565 (USER-ID) 567 [TOKEN] 569 5.8 Error 571 The floor control server informs clients about errors processing 572 requests by sending them Error messages. The following is the format 573 of the Error message: 575 Error = (FIXED-HEADER) 576 (REQUEST-ID) 577 (USER-ID) 578 (ERROR-CODE) 579 (HUMAN-READABLE-INFO) 581 6. bfcp and bfcps URI Definitions 583 The following is the ABNF [2] for the "bfcp" and "bfcps" URIs: 585 bfcpURI = "bfcp://" server "/" conf-id [ uri-parameters ] 586 bfcpsURI = "bfcps://" server "/" conf-id [ uri-parameters ] 588 server = [ user "@" ] hostport 589 user = user-id [ ":" token ] 590 user-id = 1*DIGIT 591 token = 1*DIGIT 593 conf-id = 1*DIGIT 595 uri-parameters = *( "?" uri-parameter) 596 uri-parameter = transport-param / other-param 597 transport-param = "transport=" 598 ( "tcp" / other-transport ) 599 other-transport = pvalue 600 other-param = pname [ "=" pvalue ] 601 pname = 1*paramchar 602 pvalue = 1*paramchar 603 paramchar = param-unreserved / unreserved / escaped 604 param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" 605 unreserved = alphanum / mark 606 alphanum = ALPHA / DIGIT 607 mark = "-" / "_" / "." / "!" / "~" / "*" / "'" 608 / "(" / ")" 609 escaped = "%" HEXDIG HEXDIG 611 We import several definitions from RFC 2396 [4] and RFC 2732 [6], but 612 we make them complatible with RFC 2234 [2]: 614 hostport = host [ ":" port ] 616 host = hostname / IPv4address / IPv6reference 617 hostname = *( domainlabel "." ) toplabel [ "." ] 618 domainlabel = alphanum 619 / alphanum *( alphanum / "-" ) alphanum 620 toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 621 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 622 IPv6reference = "[" IPv6address "]" 623 IPv6address = hexpart [ ":" IPv4address ] 624 hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] 625 hexseq = hex4 *( ":" hex4) 626 hex4 = 1*4HEXDIG 628 port = 1*DIGIT 630 The following are examples of bfcp and bfcps URIs: 632 bfcp://1234:472@server34.example.com/4321 633 bfcp://5678:243@server45.example.com:20000/9876?transport=tcp 634 bfcps://server57.example.com/5643 636 7. Contacting a bfcp or bfcps URI 638 A client contacting a bfcp or bfcps follows the rules described in 639 the following sections. 641 7.1 Selecting a Transport Protocol 643 XXX: Once we resolve Issue 3 in the tracker, we will edit this 644 section. 646 If the URI specifies a transport protocol in the transport parameter, 647 that transport protocol SHOULD be used. 649 Otherwise, if no transport protocol is specified, but the host part 650 of the URI is a numeric IP address, the client SHOULD use TCP. 651 Similarly, if no transport protocol is specified, the host part is 652 not numeric, but an explicit port is provided, the client SHOULD use 653 TCP. 655 Otherwise, if no transport protocol or port is specified, and the 656 host part of the URI is not a numeric IP address, the client SHOULD 657 perform a NAPTR [9] query for the domain in the URI. The services 658 relevant for the task of transport protocol selection are those with 659 NAPTR service fields with values "BFCP+D2X" and "BFCPS+D2X", where X 660 is a letter that corresponds to a transport protocol supported by the 661 domain. This specification defines D2T for TCP. 663 These NAPTR records provide a mapping from a domain to the SRV [7] 664 record for contacting a server with the specific transport protocol 665 in the NAPTR services field. The resource record will contain an 666 empty regular expression and a replacement value, which is the SRV 667 record for that particular transport protocol. If the server supports 668 multiple transport protocols, there will be multiple NAPTR records, 669 each with a different service value. 671 A client resolving a BFCPS URI MUST discard any services that do not 672 contain "BFCPS" as the protocol in the service field. On the other 673 hand, a client resolving a BFCP URI SHOULD retain records with 674 "BFCPS" as the protocol, if the client supports TLS. 676 The client MUST discard any service fields that identify a resolution 677 service whose value is not "D2X", for values of X that indicate 678 transport protocols supported by the client. The NAPTR processing as 679 described in RFC 3403 [9] will result in the discovery of the most 680 preferred transport protocol of the server that is supported by the 681 client, as well as an SRV record for the server. 683 If no NAPTR records are found, the client constructs SRV queries for 684 those transport protocols it supports, and does a query for each. 685 Queries are done using the service identifier "_bfcp" for bfcp URIs 686 and "_bfcps" for bfcps URIs. If the client supports TLS and wishes to 687 use it, it SHOULD also query using the service identifier "_bfcps", 688 even when handling floor URIs. A particular transport is supported if 689 the query is successful. The client MAY use any transport protocol it 690 desires which is supported by the server. 692 If no SRV records are found, the client SHOULD use TCP to contact the 693 server. 695 7.2 Determining Port and IP Address 697 Once the transport protocol has been determined, the next step is to 698 determine the IP address and port. 700 If the host part of the URI is a numeric IP address, the client uses 701 that address. If the URI also contains a port, the client uses that 702 port. If no port is specified, the client uses the default port for 703 the particular transport protocol. 705 If the host part of the URI was not a numeric IP address, but a port 706 is present in the URI, the client performs an A or AAAA record lookup 707 of the domain name. The result will be a list of IP addresses, each 708 of which can be contacted at the specific port from the URI and 709 transport protocol determined previously. The client SHOULD try the 710 first record. If an attempt should fail, the next SHOULD be tried, 711 and if that should fail, the next SHOULD be tried, and so on. 713 If the host part of the URI was not a numeric IP address, and no port 714 was present in the URI, the client performs an SRV query on the 715 record returned from the NAPTR processing of Section 7.1, if such 716 processing was performed. If it was not, because a transport was 717 specified explicitly, the client performs an SRV query for that 718 specific transport, using the service identifiers as described in 719 Section 7.1. If the NAPTR processing was not done because no NAPTR 720 records were found, but an SRV query for a supported transport 721 protocol was successful, those SRV records are selected. Regardless 722 of how the SRV records were determined, the procedures of RFC 2782 723 [7], as described in the section titled "Usage rules" are followed. 725 If no SRV records were found, the client performs an A or AAAA record 726 lookup of the domain name. The result will be a list of IP addresses, 727 each of which can be contacted using the transport protocol 728 determined previously, at the default port for that transport. 730 7.3 Lower-Layer Security 732 SFTP relies on lower-layer security mechanisms to provide integrity 733 and replay protection, and confidentiality. SFTP servers MUST support 734 TLS [3], and clients SHOULD support TLS. Clients and servers MAY 735 support other security mechanisms. 737 Servers and clients that implement TLS MUST support XXX: cypher and 738 hash algorithm. 740 If a client is contacting a BFCPS URI, the client MUST use TLS 741 towards the server. If a client is contacting a BFCP URI, and the 742 client wishes to use TLS, the client MAY use TLS towards the server. 743 If the client is contacting a BFCP URI, and the client does not wish 744 to use or does not support TLS, it SHOULD use a different security 745 mechanism which SHOULD provide integrity and replay protection, and 746 confidentiality. 748 7.4 Conference ID, User ID, and Token Values 750 Once the client has determined the transport protocol to use, the IP 751 address and port number of the server, and the security mechanism to 752 use, the client SHOULD establish the transport and security 753 connections needed to contact the server. At this point, the client 754 is ready to send BFCP messages to the server. 756 In order to do this, the client needs to fill a set of fields. In 757 particular, the client needs to fill the Conference ID field in the 758 FIXED-HEADER, and the User ID and Token fields in their respective 759 TLVs. 761 The conf-id of the BFCP or BFCPS URI contains the integer 762 representation of the 32-bit Conference ID to be used in the 763 FIXED-HEADER. If the conf-id contains an integer too large to be 764 represented using 32 bits, the client MUST only use the least 765 significant 32 bits of its representation. 767 The values to be used in the USER-ID and TOKEN parameters may be 768 obtained from the URI. If the URI does not contain these values, they 769 are obtained by the client using a mechanism which is outside the 770 scope of this document. Examples of such a mechanism are using the 771 Conference Event Package [13] and using the SIP [8] Call-Info header 772 field. 774 8. Client Operations 776 This section specifies how clients can perform different operations, 777 such as requesting a floor, using the protocol elements described in 778 earlier sections. Chair operations, such as instructing the floor 779 server to grant or revoke a floor, are described in Section 9. 781 8.1 Requesting a Floor 783 A client that wishes to request one or more floors does so by sending 784 a FloorRequest message to the floor control server. The ABNF in 785 Section 5.1 describes the TLVs that a FloorRequest message can 786 contain. In addition, the ABNF specifies which of these TLVs are 787 mandatory, and which ones are optional. 789 The client MUST set the Conference ID in the FIXED-HEADER of the 790 FloorRequest to the Conference ID for the conference that the client 791 obtained previously. 793 The client MUST set the Request ID value in the REQUEST-ID TLV to a 794 random number. The Request ID value is used by the client to match 795 this floor request with the responses received from the floor control 796 server. The Request ID value is also used by the server to match this 797 floor request with eventual FloorRelease messages from the client 798 cancelling the floor request. The client MUST NOT reuse the same 799 Request ID value for new messages different than FloorRelease until 800 the floor request is granted or denied or an Error message for this 801 FloorRequest is received. 803 If the client inserts more than one FLOOR-ID TLVs in the FloorRequest 804 message, the server will treat all the floor requests as an atomic 805 package. That is, the floor control server will either grant or deny 806 all the floors in the FloorRequest message. 808 The USER-ID and the TOKEN TLVs in the FloorRequest message are used 809 by the server to authenticate and authorize the request. 811 The USER-DISPLAY-NAME and the USER-URI TLVs in the FloorRequest 812 message, if present, provide extra information about the user 813 requesting the floor. 815 The client can request the server to handle the floor request with a 816 certain priority using a PRIORITY TLV. 818 The client MAY use a HUMAN-READABLE-INFO TLV to state the reason why 819 the floor or floors are being requested. The Text in the 820 HUMAN-READABLE-INFO TLV is intended for human consumption. 822 8.1.1 Receiving Responses 824 A message from the server is considered a response to the 825 FloorRequest message by the client if the message from the server has 826 the same Conference ID, Request ID, and User ID as the FloorRequest 827 message. 829 If the response is a FloorRequestStatus message, the client obtains 830 information about the status of the FloorRequest in a REQUEST-STATUS 831 TLV. If the Request Status value is Granted, the client has been 832 granted all the floors that were requested in the FloorRequest 833 message. If the Request Status value is Denied, the client has been 834 denied all the floors that were requested in the FloorRequest 835 message. The HUMAN-READABLE-INFO TLV, if present, provides extra 836 information which the client MAY display to the user. 838 If the response is an Error message, the server could not process the 839 FloorRequest message for some reason, which is described in the Error 840 message. 842 8.2 Cancelling a Floor Request 844 A client that wishes to cancel a pending floor request does so by 845 sending a FloorRelease message to the floor control server. The ABNF 846 in Section 5.2 describes the TLVs that a FloorRelease message can 847 contain. In addition, the ABNF specifies which of these TLVs are 848 mandatory, and which ones are optional. 850 The client MUST set the Conference ID in the FIXED-HEADER of the 851 FloorRelease to the Conference ID for the conference that the client 852 obtained previously. 854 Note that the FloorRelease message is also used to release a floor 855 or floors that were granted to the client. Using the same message 856 for both situations helps resolve the race condition that occurs 857 when the FloorRelease message and the FloorGrant message cross 858 each other on the wire. 860 The client MUST copy the REQUEST-ID, FLOOR-ID, USER-ID, and TOKEN 861 TLVs from the FloorRequest message that the FloorRelease message is 862 cancelling into the FloorRelease message. 864 8.2.1 Receiving Responses 866 A message from the server is considered a response to the 867 FloorRelease message by the client if the message from the server has 868 the same Conference ID, Request ID, and User ID as the FloorRelease 869 message. 871 If the response is a FloorRequestStatus message, the client obtains 872 information about the status of the FloorRequest in a REQUEST-STATUS 873 TLV. If the Request Status value is different from Cancelled, the 874 FloorRelease message and the FloorRequestStatus crossed on the wire. 875 The client does not need to resend the FloorRelease message, because 876 the server will send a new FloorRequestStatus message with a Request 877 Status value of Cancelled as soon as it receives the original 878 FloorRelease message. The HUMAN-READABLE-INFO TLV, if present, 879 provides extra information which the client MAY display to the user. 881 If the response is an Error message, the server could not process the 882 FloorRelease message for some reason, which is described in the Error 883 message. 885 8.3 Releasing Floors 887 A client that wishes to release one or more floors, which were 888 granted to it before, does so by sending a FloorRelease message. The 889 ABNF in Section 5.2 describes the TLVs that a FloorRelease message 890 can contain. In addition, the ABNF specifies which of these TLVs are 891 mandatory, and which ones are optional. 893 The client MUST set the Conference ID in the FIXED-HEADER of the 894 FloorRelease to the Conference ID for the conference that the client 895 obtained previously. 897 The client MUST copy the REQUEST-ID, FLOOR-ID, USER-ID, and TOKEN 898 TLVs from the FloorRequest message that resulted in the floor being 899 granted into the FloorRelease message. 901 8.3.1 Receiving Responses 903 A message from the server is considered a response to the 904 FloorRelease message by the client if the message from the server has 905 the same Conference ID, Request ID, and User ID as the FloorRelease 906 message. 908 If the response is a FloorRequestStatus message, the client obtains 909 information about the status of the FloorRequest in a REQUEST-STATUS 910 TLV. The server will send a FloorRequestStatus with a Request Status 911 value of Released as soon as it receives the FloorRelease message. 912 The HUMAN-READABLE-INFO TLV, if present, provides extra information 913 which the client MAY display to the user. 915 If the response is an Error message, the server could not process the 916 FloorRelease message for some reason, which is described in the Error 917 message. 919 8.4 Checking the Liveness of a Server 921 A client that wishes to check the liveness of a server does so by 922 sending a Ping message to the floor control server. The ABNF in 923 Section 5.6 describes the TLVs that a Ping message can contain. In 924 addition, the ABNF specifies which of these TLVs are mandatory, and 925 which ones are optional. 927 The client MUST set the Conference ID in the FIXED-HEADER of the Ping 928 to the Conference ID for the conference that the client obtained 929 previously. 931 The client MUST set the Request ID value of the REQUEST-ID TLV to a 932 random number. The Request ID value is used by the client to match 933 this ping request with the response received from the floor control 934 server. The client MUST NOT reuse the same Request ID value for new 935 messages until the client receives a PingAck or an Error message for 936 this request. 938 The server uses the values of the USER-ID and TOKEN TLVs in the Ping 939 message to authenticate and authorize the message. 941 8.4.1 Receiving Responses 943 A message from the server is considered a response to the Ping 944 message by the client if the message from the server has the same 945 Conference ID, Request ID, and User ID as the Ping message. 947 If the response is a PingAck message, the server is alive and the 948 User ID and Token values sent by the client were acceptable. 950 If the response is an Error message, the server could not process the 951 Ping message for some reason, which is described in the Error 952 message. 954 8.5 Responding to a Ping Message 956 The processing of a Ping message by a client involves generating a 957 PingAck message. The PingAck message is constructed by copying the 958 Conference ID, Request ID, and User ID values from the Ping message 959 into the PingAck message. The PingAck message MUST also contain a 960 TOKEN TLV. 962 9. Chair Operations 964 This section specifies how clients acting as chairs can perform 965 different operations, such as instructing the floor server to grant 966 or revoke a floor, using the protocol elements described in earlier 967 sections. 969 9.1 Obtaining Information about Floor Requests 971 A chair can obtain information about the floor requests that the 972 floor control server receives in different ways, which include using 973 out-of-band mechanisms. Chairs using BFCP to obtain such information 974 receive it in FloorStatus messages from the floor control server. 976 9.2 Instructing the Floor Control Server 978 Chairs that wish to send instructions to a floor control server does 979 so by sending a ChairAction message. The ABNF in Section 5.5 980 describes the TLVs that a ChairAction message can contain. In 981 addition, the ABNF specifies which of these TLVs are mandatory, and 982 which ones are optional. 984 The client MUST set the Conference ID in the FIXED-HEADER of the 985 ChairAction to the Conference ID for the conference that the client 986 obtained previously. 988 The client MUST set the Request ID value of the REQUEST-ID TLV to a 989 random number. The Request ID value is used by the chair to match 990 this ChairAction message with the responses received from the floor 991 control server. The chair MUST NOT reuse the same Request ID value 992 for new messages until the floor server has performed the 993 instructions sent in the ChairAction message or until an Error 994 response is received. 996 The server uses the values of the USER-ID and TOKEN TLVs to 997 authenticate and authorize the request. 999 The chair MUST identify the floor the instructions in the message 1000 apply to using a FLOOR-ID TLV. Additionally, the chair MUST identify 1001 the floor request the instructions in the message apply to using a 1002 REQUEST-ID and a USER-ID TLVs. 1004 The chair MUST provide the new status of the floor request using a 1005 REQUEST-STATUS TLV. If the new status of the floor request is 1006 Accepted, the chair MAY use the Queue Position field to provide a 1007 queue position for the floor request. If the chair does not wish to 1008 provide a queue position, all the bits of the Queue Position field 1009 SHOULD be set to zero. The chair SHOULD use the Status Revoked to 1010 revoke a floor that was granted (i.e., Granted status) and to reject 1011 floor requests in any other status (e.g., Pending and Accepted). 1013 The chair MAY use a HUMAN-READABLE-INFO TLV to state the reason why 1014 the floor or floors are being accepted, granted, or revoked. The Text 1015 in the HUMAN-READABLE-INFO TLV is intended for human consumption. 1017 10. Server Operations 1019 This section specifies how servers can perform different operations, 1020 such as granting a floor, using the protocol elements described in 1021 earlier sections. Section 10.6 1023 On reception of a message from a client, the floor control server 1024 MUST check whether or not the values of the Conference ID, User ID, 1025 and Token identify a valid user. If they do not, the floor server 1026 SHOULD send an Error message, as described in Section 10.6, with 1027 Error code 1 (Authentication Failed). 1029 On reception of a message from a client, the floor control server 1030 MUST check whether or not it understands all the mandatory ( 'M' bit 1031 set) TLVs in the message. If the server does not understand all of 1032 them, the floor server SHOULD send an Error message, as described in 1033 Section 10.6, with Error code 2 (Authentication Failed). The Error 1034 message SHOULD list the TLVs that were not understood. 1036 10.1 Reception of a FloorRequest Message 1038 The processing of a FloorRequest message by a server involves 1039 generating one or more FloorRequestStatus messages. The floor control 1040 server SHOULD generate a FloorRequestStatus message as soon as 1041 possible. If the floor server cannot accept, grant or deny the floor 1042 request right away, it SHOULD use a Request Status value of Pending. 1044 At any time, when the status of the floor request changes, the floor 1045 control server SHOULD send a FloorRequest message with the 1046 appropriate Request Status. 1048 On reception of a FloorRelease message, the server SHOULD send a 1049 FloorRequestStatus message with a Request Status value of Released, 1050 if the floor had been previously granted, or of Cancelled, if it had 1051 not. 1053 The server constructs the FloorRequestStatus messages by copying the 1054 Conference ID, Request ID, and User ID values from the FloorRequest 1055 message into the response message. The server MAY add a 1056 HUMAN-READABLE-INFO TLV to provide extra information to the user 1057 about its decision. 1059 The floor control server MAY use the PRIORITY TLV, if present in the 1060 FloorRequest, to give higher or lower priority to the floor request. 1062 10.2 Checking the Liveness of a Client or Chair 1064 A server that wishes to check the liveness of a client does so by 1065 sending a Ping message to the client or chair. Such a Ping message 1066 makes the client return a PingAck message, which contains the 1067 client's or chair's User ID and Token. So, the server can use Ping 1068 messages to re-authenticate the client (e.g., a new token is sent to 1069 the client or chair out-of-band and the Ping message makes the client 1070 show the server that the client or chair received it). 1072 The ABNF in Section 5.6 describes the TLVs that a Ping message can 1073 contain. In addition, the ABNF specifies which of these TLVs are 1074 mandatory, and which ones are optional. 1076 The server MUST set the Conference ID in the FIXED-HEADER of the Ping 1077 to the Conference ID for the conference that the client or chair is 1078 part of. 1080 The server MUST set the Request ID valie of the REQUEST-ID TLV to a 1081 random number. The Request ID value is used by the server to match 1082 this ping request with the response received from the client or 1083 chair. The server MUST NOT reuse the same Request ID value for new 1084 messages until the server receives a PingAck message for this 1085 request. 1087 The server MUST set the User ID value of the USER-ID TLV to the User 1088 ID of the destination client or chair. 1090 10.2.1 Receiving a PingAck Message 1092 A PingAck message from the client is considered a response to the 1093 Ping message by the server if the PingAck message has the same 1094 Conference ID, Request ID, and User ID as the Ping message. 1096 The PingAck message sent by the client in response to the Ping 1097 message sent by the server will contain the client's User ID and 1098 Token. The server authenticates this message as any other message, 1099 which may involve returning an Error message if the authentication is 1100 not succesful. 1102 10.3 Responding to a Ping Message 1104 The processing of a Ping message by a server involves generating a 1105 PingAck message. The PingAck message is constructed by copying the 1106 Conference ID, Request ID, and User ID values from the Ping message 1107 into the PingAck message. 1109 10.4 Informing about the Status of a Floor 1111 Floor control servers send information to clients and chairs about 1112 the status of a floor by sending FloorStatus messages. 1114 The server MUST set the Conference ID in the FIXED-HEADER of the 1115 FloorStatus to the Conference ID for the conference that the client 1116 or chair is part of. 1118 The chair MUST identify the floor the FloorStatus message applies to 1119 using a FLOOR-ID TLV. 1121 The server MAY provide information about a number of floor requests 1122 in a single FloorStatus message. For each floor request, the server 1123 MUST include in the FloorStatus the request's REQUEST-ID, USER-ID, 1124 and REQUEST-STATUS, and MAY include its USER-DISPLAY-NAME, USER-URI, 1125 HUMAN-READABLE-INFO, and requested PRIORITY. 1127 10.5 Receiving a ChairAction Message 1129 On reception of a ChairAction message, the floor control server 1130 checks whether the chair that send the message is authorized to 1131 perform the operation being requested. If the chair is authorized, 1132 the floor control server performs the operation. If the new Status is 1133 Accepted and all the bits of the Queue Position field are zero, the 1134 server assigns a queue position (e.g., the last in the queue) to the 1135 floor request based on local policy (in case the server implements a 1136 queue). 1138 If the floor control server cannot find a floor request that matches 1139 the request the operation in the ChairAction message applies to, the 1140 floor control server generates an Error message, as described in 1141 Section 10.6, with an Error code with a value of 3 (Floor Request 1142 does not Exist). 1144 If the chair is not authorized to perform the operation being 1145 requested, the floor control server generates an Error message, as 1146 described in Section 10.6, with an Error code with a value of 4 1147 (Unauthorized Operation). 1149 10.6 Error Message Generation 1151 Error messages are always sent in response to a previous message from 1152 the client. Servers construct Error messages by copying the 1153 Conference ID, Request ID, and User ID values from the client's 1154 message into the Error message. 1156 The ABNF in Section 5.8 describes the TLVs that a Error message can 1157 contain. In addition, the ABNF specifies which of these TLVs are 1158 mandatory, and which ones are optional. 1160 11. Security Considerations 1162 TBD. 1164 12. IANA Considerations 1166 TBD 1168 12.1 bfcp and bfcps URI Schemes Registration 1170 This section registers the bfcp and bfcps URI schemes following the 1171 template given in RFC 2717 [5]. 1173 URI scheme names: "bfcp" and "bfcps" 1175 URI scheme syntax: specified in Section 6 of RFC XXXX (substitute 1176 XXXX with the number of this RFC). 1178 Character encoding considerations: The "bfcp" and "bfcps" URIs 1179 support the UTF-8 encoding scheme. 1181 Intended use: common within floor control protocols. 1183 Applications and/or protocols which use these URI scheme: BFCP, which 1184 is specified in this document. 1186 Interoperability considerations: none known. 1188 Security considerations: the "bfcps" URI scheme indicates a 1189 requirement to use TLS to contact the floor control server. 1191 Relevant publications: RFC XXXX (substitute XXXX with the number of 1192 this RFC). 1194 Contact information: the IETF XCON Working group. In case the WG does 1195 no exist anymore, any person appointed by the IETF Transport Area 1196 Director(s). 1198 Registered-by: Gonzalo Camarillo 1200 Change control: extensions, new parameters and new values to these 1201 URIs have to be documented in an RFC. The IETF XCON Working Group or, 1202 in case the WG does no exist anymore, any person appointed by the 1203 IETF Transport Area Director(s), will provide expert review and 1204 advise to the change control process. 1206 13. Acknowledgments 1208 The XCON WG chairs, Adam Roach and Alan Johnston, provided useful 1209 ideas for this document. 1211 14. References 1213 14.1 Normative References 1215 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1216 Levels", BCP 14, RFC 2119, March 1997. 1218 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1219 Specifications: ABNF", RFC 2234, November 1997. 1221 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1222 2246, January 1999. 1224 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1225 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1226 1998. 1228 [5] Petke, R. and I. King, "Registration Procedures for URL Scheme 1229 Names", BCP 35, RFC 2717, November 1999. 1231 [6] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal 1232 IPv6 Addresses in URL's", RFC 2732, December 1999. 1234 [7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1235 specifying the location of services (DNS SRV)", RFC 2782, 1236 February 2000. 1238 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1239 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1240 Session Initiation Protocol", RFC 3261, June 2002. 1242 [9] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 1243 Three: The Domain Name System (DNS) Database", RFC 3403, 1244 October 2002. 1246 [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 1247 63, RFC 3629, November 2003. 1249 14.2 Informational References 1251 [11] Schulzrinne, H., "Requirements for Floor Control Protocol", 1252 draft-ietf-xcon-floor-control-req-00 (work in progress), 1253 January 2004. 1255 [12] Koskelainen, P. and H. Khartabil, "An Extensible Markup 1256 Language (XML) Configuration Access Protocol (XCAP) Usage for 1257 Conference Policy Manipulation", 1258 draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress), 1259 February 2004. 1261 [13] Rosenberg, J. and H. Schulzrinne, "A Session Initiation 1262 Protocol (SIP) Event Package for Conference State", 1263 draft-ietf-sipping-conference-package-03 (work in progress), 1264 February 2004. 1266 Authors' Addresses 1268 Gonzalo Camarillo 1269 Ericsson 1270 Hirsalantie 11 1271 Jorvas 02420 1272 Finland 1274 EMail: Gonzalo.Camarillo@ericsson.com 1275 Joerg Ott 1276 Universitaet Bremen 1277 MZH 5180 1278 Bibliothekstr. 1 1279 Bremen D-28359 1280 Germany 1282 EMail: jo@tzi.org 1284 Keith Drage 1285 Lucent Technologies 1286 Windmill Hill Business Park 1287 Swindon 1288 Wiltshire SN5 6PP 1289 UK 1291 EMail: drage@lucent.com 1293 Intellectual Property Statement 1295 The IETF takes no position regarding the validity or scope of any 1296 Intellectual Property Rights or other rights that might be claimed to 1297 pertain to the implementation or use of the technology described in 1298 this document or the extent to which any license under such rights 1299 might or might not be available; nor does it represent that it has 1300 made any independent effort to identify any such rights. Information 1301 on the IETF's procedures with respect to rights in IETF Documents can 1302 be found in BCP 78 and BCP 79. 1304 Copies of IPR disclosures made to the IETF Secretariat and any 1305 assurances of licenses to be made available, or the result of an 1306 attempt made to obtain a general license or permission for the use of 1307 such proprietary rights by implementers or users of this 1308 specification can be obtained from the IETF on-line IPR repository at 1309 http://www.ietf.org/ipr. 1311 The IETF invites any interested party to bring to its attention any 1312 copyrights, patents or patent applications, or other proprietary 1313 rights that may cover technology that may be required to implement 1314 this standard. Please address the information to the IETF at 1315 ietf-ipr@ietf.org. 1317 Disclaimer of Validity 1319 This document and the information contained herein are provided on an 1320 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1321 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1322 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1323 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1324 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1325 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1327 Copyright Statement 1329 Copyright (C) The Internet Society (2004). This document is subject 1330 to the rights, licenses and restrictions contained in BCP 78, and 1331 except as set forth therein, the authors retain all their rights. 1333 Acknowledgment 1335 Funding for the RFC Editor function is currently provided by the 1336 Internet Society.