diff options
Diffstat (limited to 'doc/rfc/rfc4582.txt')
| -rw-r--r-- | doc/rfc/rfc4582.txt | 3643 |
1 files changed, 3643 insertions, 0 deletions
diff --git a/doc/rfc/rfc4582.txt b/doc/rfc/rfc4582.txt new file mode 100644 index 0000000..a48333f --- /dev/null +++ b/doc/rfc/rfc4582.txt @@ -0,0 +1,3643 @@ + + + + + + +Network Working Group G. Camarillo +Request for Comments: 4582 Ericsson +Category: Standards Track J. Ott + Helsinki University of Technology + K. Drage + Lucent Technologies + November 2006 + + + The Binary Floor Control Protocol (BFCP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2006). + +Abstract + + Floor control is a means to manage joint or exclusive access to + shared resources in a (multiparty) conferencing environment. + Thereby, floor control complements other functions -- such as + conference and media session setup, conference policy manipulation, + and media control -- that are realized by other protocols. + + This document specifies the Binary Floor Control Protocol (BFCP). + BFCP is used between floor participants and floor control servers, + and between floor chairs (i.e., moderators) and floor control + servers. + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................4 + 3. Scope ...........................................................5 + 3.1. Floor Creation .............................................7 + 3.2. Obtaining Information to Contact a Floor Control Server ....7 + 3.3. Obtaining Floor-Resource Associations ......................7 + 3.4. Privileges of Floor Control ................................8 + 4. Overview of Operation ...........................................8 + 4.1. Floor Participant to Floor Control Server Interface ........8 + 4.2. Floor Chair to Floor Control Server Interface .............13 + + + +Camarillo, et al. Standards Track [Page 1] + +RFC 4582 BFCP November 2006 + + + 5. Packet Format ..................................................14 + 5.1. COMMON-HEADER Format ......................................15 + 5.2. Attribute Format ..........................................16 + 5.2.1. BENEFICIARY-ID .....................................18 + 5.2.2. FLOOR-ID ...........................................18 + 5.2.3. FLOOR-REQUEST-ID ...................................19 + 5.2.4. PRIORITY ...........................................19 + 5.2.5. REQUEST-STATUS .....................................20 + 5.2.6. ERROR-CODE .........................................21 + 5.2.6.1. Error-Specific Details for Error Code 4 ...22 + 5.2.7. ERROR-INFO .........................................22 + 5.2.8. PARTICIPANT-PROVIDED-INFO ..........................23 + 5.2.9. STATUS-INFO ........................................24 + 5.2.10. SUPPORTED-ATTRIBUTES ..............................24 + 5.2.11. SUPPORTED-PRIMITIVES ..............................25 + 5.2.12. USER-DISPLAY-NAME .................................26 + 5.2.13. USER-URI ..........................................26 + 5.2.14. BENEFICIARY-INFORMATION ...........................27 + 5.2.15. FLOOR-REQUEST-INFORMATION .........................27 + 5.2.16. REQUESTED-BY-INFORMATION ..........................28 + 5.2.17. FLOOR-REQUEST-STATUS .............................29 + 5.2.18. OVERALL-REQUEST-STATUS ...........................30 + 5.3. Message Format ............................................30 + 5.3.1. FloorRequest .......................................31 + 5.3.2. FloorRelease .......................................31 + 5.3.3. FloorRequestQuery ..................................31 + 5.3.4. FloorRequestStatus .................................31 + 5.3.5. UserQuery ..........................................32 + 5.3.6. UserStatus .........................................32 + 5.3.7. FloorQuery .........................................32 + 5.3.8. FloorStatus ........................................33 + 5.3.9. ChairAction ........................................33 + 5.3.10. ChairActionAck ....................................33 + 5.3.11. Hello .............................................33 + 5.3.12. HelloAck ..........................................34 + 5.3.13. Error .............................................34 + 6. Transport ......................................................34 + 7. Lower-Layer Security ...........................................35 + 8. Protocol Transactions ..........................................35 + 8.1. Client Behavior ...........................................36 + 8.2. Server Behavior ...........................................36 + 9. Authentication and Authorization ...............................36 + 9.1. TLS-Based Mutual Authentication ...........................37 + 10. Floor Participant Operations ..................................37 + 10.1. Requesting a Floor .......................................37 + 10.1.1. Sending a FloorRequest Message ....................38 + 10.1.2. Receiving a Response ..............................38 + 10.2. Cancelling a Floor Request and Releasing a Floor .........40 + + + +Camarillo, et al. Standards Track [Page 2] + +RFC 4582 BFCP November 2006 + + + 10.2.1. Sending a FloorRelease Message ....................40 + 10.2.2. Receiving a Response ..............................40 + 11. Chair Operations ..............................................41 + 11.1. Sending a ChairAction Message ............................41 + 11.2. Receiving a Response .....................................42 + 12. General Client Operations .....................................43 + 12.1. Requesting Information about Floors ......................43 + 12.1.1. Sending a FloorQuery Message ......................43 + 12.1.2. Receiving a Response ..............................43 + 12.2. Requesting Information about Floor Requests ..............44 + 12.2.1. Sending a FloorRequestQuery Message ...............45 + 12.2.2. Receiving a Response ..............................45 + 12.3. Requesting Information about a User ......................45 + 12.3.1. Sending a UserQuery Message .......................46 + 12.3.2. Receiving a Response ..............................46 + 12.4. Obtaining the Capabilities of a Floor Control Server .....46 + 12.4.1. Sending a Hello Message ...........................47 + 12.4.2. Receiving Responses ...............................47 + 13. Floor Control Server Operations ...............................47 + 13.1. Reception of a FloorRequest Message ......................48 + 13.1.1. Generating the First FloorRequestStatus Message ...48 + 13.1.2. Generation of Subsequent + FloorRequestStatus Messages .......................50 + 13.2. Reception of a FloorRequestQuery Message .................51 + 13.3. Reception of a UserQuery Message .........................52 + 13.4. Reception of a FloorRelease Message ......................53 + 13.5. Reception of a FloorQuery Message ........................54 + 13.5.1. Generation of the First FloorStatus Message .......55 + 13.5.2. Generation of Subsequent FloorStatus Messages .....56 + 13.6. Reception of a ChairAction Message .......................56 + 13.7. Reception of a Hello Message .............................57 + 13.8. Error Message Generation .................................58 + 14. Security Considerations .......................................58 + 15. IANA Considerations ...........................................59 + 15.1. Attribute Subregistry ....................................59 + 15.2. Primitive Subregistry ....................................60 + 15.3. Request Status Subregistry ...............................61 + 15.4. Error Code Subregistry ...................................62 + 16. Acknowledgements ..............................................62 + 17. References ....................................................63 + 17.1. Normative References .....................................63 + 17.2. Informational References .................................63 + + + + + + + + + +Camarillo, et al. Standards Track [Page 3] + +RFC 4582 BFCP November 2006 + + +1. Introduction + + Within a conference, some applications need to manage the access to a + set of shared resources, such as the right to send media to a + particular media session. Floor control enables such applications to + provide users with coordinated (shared or exclusive) access to these + resources. + + The Requirements for Floor Control Protocol [9] list a set of + requirements that need to be met by floor control protocols. The + Binary Floor Control Protocol (BFCP), which is specified in this + document, meets these requirements. + + In addition, BFCP has been designed so that it can be used in + low-bandwidth environments. The binary encoding used by BFCP + achieves a small message size (when message signatures are not used) + that keeps the time it takes to transmit delay-sensitive BFCP + messages to a minimum. Delay-sensitive BFCP messages include + FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It + is expected that future extensions to these messages will not + increase the size of these messages in a significant way. + + The remainder of this document is organized as follows: Section 2 + defines the terminology used throughout this document, Section 3 + discusses the scope of BFCP (i.e., which tasks fall within the scope + of BFCP and which ones are performed using different mechanisms), + Section 4 provides a non-normative overview of BFCP operation, and + subsequent sections provide the normative specification of BFCP. + +2. Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as + described in BCP 14, RFC 2119 [1] and indicate requirement levels for + compliant implementations. + + Media Participant: An entity that has access to the media resources + of a conference (e.g., it can receive a media stream). In floor- + controlled conferences, a given media participant is typically + colocated with a floor participant, but it does not need to be. + Third-party floor requests consist of having a floor participant + request a floor for a media participant when they are not colocated. + The protocol between a floor participant and a media participant + (that are not colocated) is outside the scope of this document. + + Client: A floor participant or a floor chair that communicates with a + floor control server using BFCP. + + + +Camarillo, et al. Standards Track [Page 4] + +RFC 4582 BFCP November 2006 + + + Floor: A temporary permission to access or manipulate a specific + shared resource or set of resources. + + Floor Chair: A logical entity that manages one floor (grants, denies, + or revokes a floor). An entity that assumes the logical role of a + floor chair for a given transaction may assume a different role + (e.g., floor participant) for a different transaction. The roles of + floor chair and floor participant are defined on a transaction-by- + transaction basis. BFCP transactions are defined in Section 8. + + Floor Control: A mechanism that enables applications or users to gain + safe and mutually exclusive or non-exclusive input access to the + shared object or resource. + + Floor Control Server: A logical entity that maintains the state of + the floor(s), including which floors exists, who the floor chairs + are, who holds a floor, etc. Requests to manipulate a floor are + directed at the floor control server. The floor control server of a + conference may perform other logical roles (e.g., floor participant) + in another conference. + + Floor Participant: A logical entity that requests floors, and + possibly information about them, from a floor control server. An + entity that assumes the logical role of a floor participant for a + given transaction may assume a different role (e.g., a floor chair) + for a different transaction. The roles of floor participant and + floor chair are defined on a transaction-by-transaction basis. BFCP + transactions are defined in Section 8. In floor-controlled + conferences, a given floor participant is typically colocated with a + media participant, but it does not need to be. Third-party floor + requests consist of having a floor participant request a floor for a + media participant when they are not colocated. + + Participant: An entity that acts as a floor participant, as a media + participant, or as both. + +3. Scope + + As stated earlier, BFCP is a protocol to coordinate access to shared + resources in a conference following the requirements defined in [9]. + Floor control complements other functions defined in the XCON + conferencing framework [10]. The floor control protocol BFCP defined + in this document only specifies a means to arbitrate access to + floors. The rules and constraints for floor arbitration and the + results of floor assignments are outside the scope of this document + and are defined by other protocols [10]. + + + + + +Camarillo, et al. Standards Track [Page 5] + +RFC 4582 BFCP November 2006 + + + Figure 1 shows the tasks that BFCP can perform. + + +---------+ + | Floor | + | Chair | + | | + +---------+ + ^ | + | | + Notification | | Decision + | | + | | + Floor | v + +-------------+ Request +---------+ +-------------+ + | Floor |----------->| Floor | Notification | Floor | + | Participant | | Control |------------->| Participant | + | |<-----------| Server | | | + +-------------+ Granted or +---------+ +-------------+ + Denied + + Figure 1: Functionality provided by BFCP + + BFCP provides a means: + + o for floor participants to send floor requests to floor control + servers. + + o for floor control servers to grant or deny requests to access a + given resource from floor participants. + + o for floor chairs to send floor control servers decisions regarding + floor requests. + + o for floor control servers to keep floor participants and floor + chairs informed about the status of a given floor or a given floor + request. + + Even though tasks that do not belong to the previous list are outside + the scope of BFCP, some of these out-of-scope tasks relate to floor + control and are essential for creating floors and establishing BFCP + connections between different entities. In the following + subsections, we discuss some of these tasks and mechanisms to perform + them. + + + + + + + + +Camarillo, et al. Standards Track [Page 6] + +RFC 4582 BFCP November 2006 + + +3.1. Floor Creation + + The association of a given floor with a resource or a set of + resources (e.g., media streams) is out of the scope of BFCP as + described in [10]. Floor creation and termination are also outside + the scope of BFCP; these aspects are handled using the conference + control protocol for manipulating the conference object. + Consequently, the floor control server needs to stay up to date on + changes to the conference object (e.g., when a new floor is created). + +3.2. Obtaining Information to Contact a Floor Control Server + + A client needs a set of data in order to establish a BFCP connection + to a floor control server. These data include the transport address + of the server, the conference identifier, and a user identifier. + + Clients can obtain this information in different ways. One is to use + an SDP offer/answer [8] exchange, which is described in [7]. Other + mechanisms are described in the XCON framework [10] (and other + related documents). + +3.3. Obtaining Floor-Resource Associations + + Floors are associated with resources. For example, a floor that + controls who talks at a given time has a particular audio session as + its associated resource. Associations between floors and resources + are part of the conference object. + + Floor participants and floor chairs need to know which resources are + associated with which floors. They can obtain this information by + using different mechanisms, such as an SDP offer/answer [8] exchange. + How to use an SDP offer/answer exchange to obtain these associations + is described in [7]. + + Note that floor participants perform SDP offer/answer exchanges + with the conference focus of the conference. So, the conference + focus needs to obtain information about associations between + floors and resources in order to be able to provide this + information to a floor participant in an SDP offer/answer + exchange. + + Other mechanisms for obtaining this information, including discussion + of how the information is made available to a (SIP) Focus, are + described in the XCON framework [10] (and other related documents). + + + + + + + +Camarillo, et al. Standards Track [Page 7] + +RFC 4582 BFCP November 2006 + + +3.4. Privileges of Floor Control + + A participant whose floor request is granted has the right to use (in + a certain way) the resource or resources associated with the floor + that was requested. For example, the participant may have the right + to send media over a particular audio stream. + + Nevertheless, holding a floor does not imply that others will not be + able to use its associated resources at the same time, even if they + do not have the right to do so. Determination of which media + participants can actually use the resources in the conference is + discussed in the XCON Framework [10]. + +4. Overview of Operation + + This section provides a non-normative description of BFCP operations. + Section 4.1 describes the interface between floor participants and + floor control servers, and Section 4.2 describes the interface + between floor chairs and floor control servers. + + BFCP messages, which use a TLV (Type-Length-Value) binary encoding, + consist of a common header followed by a set of attributes. The + common header contains, among other information, a 32-bit conference + identifier. Floor participants, media participants, and floor chairs + are identified by 16-bit user identifiers. + + BFCP supports nested attributes (i.e., attributes that contain + attributes). These are referred to as grouped attributes. + + There are two types of transactions in BFCP: client-initiated + transactions and server-initiated transactions. Client-initiated + transactions consist of a message from a client to the floor control + server and a response from the floor control server to the client. + Both messages can be related because they carry the same Transaction + ID value in their common headers. Server-initiated transactions + consist of a single message, whose Transaction ID is 0, from the + floor control server to a client. + +4.1. Floor Participant to Floor Control Server Interface + + Floor participants request a floor by sending a FloorRequest message + to the floor control server. BFCP supports third-party floor + requests. That is, the floor participant sending the floor request + need not be colocated with the media participant that will get the + floor once the floor request is granted. FloorRequest messages carry + the identity of the requester in the User ID field of the common + header, and the identity of the beneficiary of the floor (in third- + party floor requests) in a BENEFICIARY-ID attribute. + + + +Camarillo, et al. Standards Track [Page 8] + +RFC 4582 BFCP November 2006 + + + Third-party floor requests can be sent, for example, by floor + participants that have a BFCP connection to the floor control + server but that are not media participants (i.e., they do not + handle any media). + + FloorRequest messages identify the floor or floors being requested by + carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a + FloorRequest message carries more than one floor identifier, the + floor control server treats all the floor requests as an atomic + package. That is, the floor control server either grants or denies + all the floors in the FloorRequest message. + + Floor control servers respond to FloorRequest messages with + FloorRequestStatus messages, which provide information about the + status of the floor request. The first FloorRequestStatus message is + the response to the FloorRequest message from the client, and + therefore has the same Transaction ID as the FloorRequest. + + Additionally, the first FloorRequestStatus message carries the Floor + Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent + FloorRequestStatus messages related to the same floor request will + carry the same Floor Request ID. This way, the floor participant can + associate them with the appropriate floor request. + + Messages from the floor participant related to a particular floor + request also use the same Floor Request ID as the first + FloorRequestStatus Message from the floor control server. + + Figure 2 shows how a floor participant requests a floor, obtains it, + and, at a later time, releases it. This figure illustrates the use, + among other things, of the Transaction ID and the FLOOR-REQUEST-ID + attribute. + + + + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 9] + +RFC 4582 BFCP November 2006 + + + Floor Participant Floor Control + Server + |(1) FloorRequest | + |Transaction ID: 123 | + |User ID: 234 | + |FLOOR-ID: 543 | + |---------------------------------------------->| + | | + |(2) FloorRequestStatus | + |Transaction ID: 123 | + |User ID: 234 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 789 | + | OVERALL-REQUEST-STATUS | + | Request Status: Pending | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + |<----------------------------------------------| + | | + |(3) FloorRequestStatus | + |Transaction ID: 0 | + |User ID: 234 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 789 | + | OVERALL-REQUEST-STATUS | + | Request Status: Accepted | + | Queue Position: 1st | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + |<----------------------------------------------| + | | + |(4) FloorRequestStatus | + |Transaction ID: 0 | + |User ID: 234 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 789 | + | OVERALL-REQUEST-STATUS | + | Request Status: Granted | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + |<----------------------------------------------| + | | + |(5) FloorRelease | + |Transaction ID: 154 | + |User ID: 234 | + |FLOOR-REQUEST-ID: 789 | + |---------------------------------------------->| + + + + +Camarillo, et al. Standards Track [Page 10] + +RFC 4582 BFCP November 2006 + + + | | + |(6) FloorRequestStatus | + |Transaction ID: 154 | + |User ID: 234 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 789 | + | OVERALL-REQUEST-STATUS | + | Request Status: Released | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + |<----------------------------------------------| + + Figure 2: Requesting and releasing a floor + + Figure 3 shows how a floor participant requests to be informed on the + status of a floor. The first FloorStatus message from the floor + control server is the response to the FloorQuery message and, as + such, has the same Transaction ID as the FloorQuery message. + + Subsequent FloorStatus messages consist of server-initiated + transactions, and therefore their Transaction ID is 0. FloorStatus + message (2) indicates that there are currently two floor requests for + the floor whose Floor ID is 543. FloorStatus message (3) indicates + that the floor requests with Floor Request ID 764 has been granted, + and the floor request with Floor Request ID 635 is the first in the + queue. FloorStatus message (4) indicates that the floor request with + Floor Request ID 635 has been granted. + + Floor Participant Floor Control + Server + |(1) FloorQuery | + |Transaction ID: 257 | + |User ID: 234 | + |FLOOR-ID: 543 | + |---------------------------------------------->| + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 11] + +RFC 4582 BFCP November 2006 + + + | | + |(2) FloorStatus | + |Transaction ID: 257 | + |User ID: 234 | + |FLOOR-ID:543 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 764 | + | OVERALL-REQUEST-STATUS | + | Request Status: Accepted | + | Queue Position: 1st | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + | BENEFICIARY-INFORMATION | + | Beneficiary ID: 124 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 635 | + | OVERALL-REQUEST-STATUS | + | Request Status: Accepted | + | Queue Position: 2nd | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + | BENEFICIARY-INFORMATION | + | Beneficiary ID: 154 | + |<----------------------------------------------| + | | + |(3) FloorStatus | + |Transaction ID: 0 | + |User ID: 234 | + |FLOOR-ID:543 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 764 | + | OVERALL-REQUEST-STATUS | + | Request Status: Granted | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + | BENEFICIARY-INFORMATION | + | Beneficiary ID: 124 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 635 | + | OVERALL-REQUEST-STATUS | + | Request Status: Accepted | + | Queue Position: 1st | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + | BENEFICIARY-INFORMATION | + | Beneficiary ID: 154 | + |<----------------------------------------------| + + + + +Camarillo, et al. Standards Track [Page 12] + +RFC 4582 BFCP November 2006 + + + | | + |(4) FloorStatus | + |Transaction ID: 0 | + |User ID: 234 | + |FLOOR-ID:543 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 635 | + | OVERALL-REQUEST-STATUS | + | Request Status: Granted | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + | BENEFICIARY-INFORMATION | + | Beneficiary ID: 154 | + |<----------------------------------------------| + + Figure 3: Obtaining status information about a floor + + FloorStatus messages contain information about the floor requests + they carry. For example, FloorStatus message (4) indicates that the + floor request with Floor Request ID 635 has as the beneficiary (i.e., + the participant that holds the floor when a particular floor request + is granted) the participant whose User ID is 154. The floor request + applies only to the floor whose Floor ID is 543. That is, this is + not a multi-floor floor request. + + A multi-floor floor request applies to more than one floor (e.g., + a participant wants to be able to speak and write on the + whiteboard at the same time). The floor control server treats a + multi-floor floor request as an atomic package. That is, the + floor control server either grants the request for all floors or + denies the request for all floors. + +4.2. Floor Chair to Floor Control Server Interface + + Figure 4 shows a floor chair instructing a floor control server to + grant a floor. + + Note, however, that although the floor control server needs to + take into consideration the instructions received in ChairAction + messages (e.g., granting a floor), it does not necessarily need to + perform them exactly as requested by the floor chair. The + operation that the floor control server performs depends on the + ChairAction message and on the internal state of the floor control + server. + + + + + + + +Camarillo, et al. Standards Track [Page 13] + +RFC 4582 BFCP November 2006 + + + For example, a floor chair may send a ChairAction message granting a + floor that was requested as part of an atomic floor request operation + that involved several floors. Even if the chair responsible for one + of the floors instructs the floor control server to grant the floor, + the floor control server will not grant it until the chairs + responsible for the other floors agree to grant them as well. In + another example, a floor chair may instruct the floor control server + to grant a floor to a participant. The floor control server needs to + revoke the floor from its current holder before granting it to the + new participant. + + So, the floor control server is ultimately responsible for keeping a + coherent floor state using instructions from floor chairs as input to + this state. + + Floor Chair Floor Control + Server + |(1) ChairAction | + |Transaction ID: 769 | + |User ID: 357 | + |FLOOR-REQUEST-INFORMATION | + | Floor Request ID: 635 | + | FLOOR-REQUEST-STATUS | + | Floor ID: 543 | + | Request Status: Granted | + |---------------------------------------------->| + | | + |(2) ChairActionAck | + |Transaction ID: 769 | + |User ID: 357 | + |<----------------------------------------------| + + Figure 4: Chair instructing the floor control server + +5. Packet Format + + BFCP packets consist of a 12-octet common header followed by + attributes. All the protocol values MUST be sent in network byte + order. + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 14] + +RFC 4582 BFCP November 2006 + + +5.1. COMMON-HEADER Format + + The following is the format of the common header. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ver |Reserved | Primitive | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Conference ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Transaction ID | User ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: COMMON-HEADER format + + Ver: The 3-bit version field MUST be set to 1 to indicate this + version of BFCP. + + Reserved: At this point, the 5 bits in the reserved field SHOULD be + set to zero by the sender of the message and MUST be ignored by the + receiver. + + Primitive: This 8-bit field identifies the main purpose of the + message. The following primitive values are defined: + + +-------+--------------------+------------------+ + | Value | Primitive | Direction | + +-------+--------------------+------------------+ + | 1 | FloorRequest | P -> S | + | 2 | FloorRelease | P -> S | + | 3 | FloorRequestQuery | P -> S ; Ch -> S | + | 4 | FloorRequestStatus | P <- S ; Ch <- S | + | 5 | UserQuery | P -> S ; Ch -> S | + | 6 | UserStatus | P <- S ; Ch <- S | + | 7 | FloorQuery | P -> S ; Ch -> S | + | 8 | FloorStatus | P <- S ; Ch <- S | + | 9 | ChairAction | Ch -> S | + | 10 | ChairActionAck | Ch <- S | + | 11 | Hello | P -> S ; Ch -> S | + | 12 | HelloAck | P <- S ; Ch <- S | + | 13 | Error | P <- S ; Ch <- S | + +-------+--------------------+------------------+ + S: Floor Control Server + P: Floor Participant + Ch: Floor Chair + + Table 1: BFCP primitives + + + +Camarillo, et al. Standards Track [Page 15] + +RFC 4582 BFCP November 2006 + + + Payload Length: This 16-bit field contains the length of the message + in 4-octet units, excluding the common header. + + Conference ID: This 32-bit field identifies the conference the + message belongs to. + + Transaction ID: This field contains a 16-bit value that allows users + to match a given message with its response. The value of the + Transaction ID in server-initiated transactions is 0 (see Section 8). + + User ID: This field contains a 16-bit value that uniquely identifies + a participant within a conference. + + The identity used by a participant in BFCP, which is carried in + the User ID field, is generally mapped to the identity used by the + same participant in the session establishment protocol (e.g., in + SIP). The way this mapping is performed is outside the scope of + this specification. + +5.2. Attribute Format + + BFCP attributes are encoded in TLV (Type-Length-Value) format. + Attributes are 32-bit aligned. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type |M| Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + / Attribute Contents / + / / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Attribute format + + Type: This 7-bit field contains the type of the attribute. Each + attribute, identified by its type, has a particular format. The + attribute formats defined are: + + Unsigned16: The contents of the attribute consist of a 16-bit + unsigned integer. + + OctetString16: The contents of the attribute consist of 16 bits of + arbitrary data. + + + + + +Camarillo, et al. Standards Track [Page 16] + +RFC 4582 BFCP November 2006 + + + OctetString: The contents of the attribute consist of arbitrary + data of variable length. + + Grouped: The contents of the attribute consist of a sequence of + attributes. + + Note that extension attributes defined in the future may define + new attribute formats. + + The following attribute types are defined: + + +------+---------------------------+---------------+ + | Type | Attribute | Format | + +------+---------------------------+---------------+ + | 1 | BENEFICIARY-ID | Unsigned16 | + | 2 | FLOOR-ID | Unsigned16 | + | 3 | FLOOR-REQUEST-ID | Unsigned16 | + | 4 | PRIORITY | OctetString16 | + | 5 | REQUEST-STATUS | OctetString16 | + | 6 | ERROR-CODE | OctetString | + | 7 | ERROR-INFO | OctetString | + | 8 | PARTICIPANT-PROVIDED-INFO | OctetString | + | 9 | STATUS-INFO | OctetString | + | 10 | SUPPORTED-ATTRIBUTES | OctetString | + | 11 | SUPPORTED-PRIMITIVES | OctetString | + | 12 | USER-DISPLAY-NAME | OctetString | + | 13 | USER-URI | OctetString | + | 14 | BENEFICIARY-INFORMATION | Grouped | + | 15 | FLOOR-REQUEST-INFORMATION | Grouped | + | 16 | REQUESTED-BY-INFORMATION | Grouped | + | 17 | FLOOR-REQUEST-STATUS | Grouped | + | 18 | OVERALL-REQUEST-STATUS | Grouped | + +------+---------------------------+---------------+ + + Table 2: BFCP attributes + + M: The 'M' bit, known as the Mandatory bit, indicates whether support + of the attribute is required. If an unrecognized attribute with the + 'M' bit set is received, the message is rejected. The 'M' bit is + significant for extension attributes defined in other documents only. + All attributes specified in this document MUST be understood by the + receiver so that the setting of the 'M' bit is irrelevant for these. + In all other cases, the unrecognised attribute is ignored but the + message is processed. + + Length: This 8-bit field contains the length of the attribute in + octets, excluding any padding defined for specific attributes. The + length of attributes that are not grouped includes the Type, 'M' bit, + + + +Camarillo, et al. Standards Track [Page 17] + +RFC 4582 BFCP November 2006 + + + and Length fields. The Length in grouped attributes is the length of + the grouped attribute itself (including Type, 'M' bit, and Length + fields) plus the total length (including padding) of all the included + attributes. + + Attribute Contents: The contents of the different attributes are + defined in the following sections. + +5.2.1. BENEFICIARY-ID + + The following is the format of the BENEFICIARY-ID attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: BENEFICIARY-ID format + + Beneficiary ID: This field contains a 16-bit value that uniquely + identifies a user within a conference. + + Note that although the formats of the Beneficiary ID and of the + User ID field in the common header are similar, their semantics + are different. The Beneficiary ID is used in third-party floor + requests and to request information about a particular + participant. + +5.2.2. FLOOR-ID + + The following is the format of the FLOOR-ID attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: FLOOR-ID format + + Floor ID: This field contains a 16-bit value that uniquely identifies + a floor within a conference. + + + + + + + + +Camarillo, et al. Standards Track [Page 18] + +RFC 4582 BFCP November 2006 + + +5.2.3. FLOOR-REQUEST-ID + + The following is the format of the FLOOR-REQUEST-ID attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: FLOOR-REQUEST-ID format + + Floor Request ID: This field contains a 16-bit value that identifies + a floor request at the floor control server. + +5.2.4. PRIORITY + + The following is the format of the PRIORITY attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: PRIORITY format + + Prio: This field contains a 3-bit priority value, as shown in + Table 3. Senders SHOULD NOT use values higher than 4 in this field. + Receivers MUST treat values higher than 4 as if the value received + were 4 (Highest). The default priority value when the PRIORITY + attribute is missing is 2 (Normal). + + +-------+----------+ + | Value | Priority | + +-------+----------+ + | 0 | Lowest | + | 1 | Low | + | 2 | Normal | + | 3 | High | + | 4 | Highest | + +-------+----------+ + + Table 3: Priority values + + Reserved: At this point, the 13 bits in the reserved field SHOULD be + set to zero by the sender of the message and MUST be ignored by the + receiver. + + + +Camarillo, et al. Standards Track [Page 19] + +RFC 4582 BFCP November 2006 + + +5.2.5. REQUEST-STATUS + + The following is the format of the REQUEST-STATUS attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 11: REQUEST-STATUS format + + Request Status: This 8-bit field contains the status of the request, + as described in the following table. + + +-------+-----------+ + | Value | Status | + +-------+-----------+ + | 1 | Pending | + | 2 | Accepted | + | 3 | Granted | + | 4 | Denied | + | 5 | Cancelled | + | 6 | Released | + | 7 | Revoked | + +-------+-----------+ + + Table 4: Request Status values + + Queue Position: This 8-bit field contains, when applicable, the + position of the floor request in the floor request queue at the + server. If the Request Status value is different from Accepted, if + the floor control server does not implement a floor request queue, or + if the floor control server does not want to provide the client with + this information, all the bits of this field SHOULD be set to zero. + + A floor request is in Pending state if the floor control server needs + to contact a floor chair in order to accept the floor request, but + has not done it yet. Once the floor control chair accepts the floor + request, the floor request is moved to the Accepted state. + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 20] + +RFC 4582 BFCP November 2006 + + +5.2.6. ERROR-CODE + + The following is the format of the ERROR-CODE attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 1 0|M| Length | Error Code | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + | Error Specific Details | + / / + / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 12: ERROR-CODE format + + Error Code: This 8-bit field contains an error code from the + following table. If an error code is not recognised by the receiver, + then the receiver MUST assume that an error exists, and therefore + that the message is processed, but the nature of the error is + unclear. + + +-------+-----------------------------------------------------------+ + | Value | Meaning | + +-------+-----------------------------------------------------------+ + | 1 | Conference does not Exist | + | 2 | User does not Exist | + | 3 | Unknown Primitive | + | 4 | Unknown Mandatory Attribute | + | 5 | Unauthorized Operation | + | 6 | Invalid Floor ID | + | 7 | Floor Request ID Does Not Exist | + | 8 | You have Already Reached the Maximum Number of Ongoing | + | | Floor Requests for this Floor | + | 9 | Use TLS | + +-------+-----------------------------------------------------------+ + + Table 5: Error Code meaning + + Error Specific Details: Present only for certain Error Codes. In + this document, only for Error Code 4 (Unknown Mandatory Attribute). + See Section 5.2.6.1 for its definition. + + Padding: One, two, or three octets of padding added so that the + contents of the ERROR-CODE attribute is 32-bit aligned. If the + attribute is already 32-bit aligned, no padding is needed. + + + +Camarillo, et al. Standards Track [Page 21] + +RFC 4582 BFCP November 2006 + + + The Padding bits SHOULD be set to zero by the sender and MUST be + ignored by the receiver. + +5.2.6.1. Error-Specific Details for Error Code 4 + + The following is the format of the Error-Specific Details field for + Error Code 4. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Unknown Type|R| Unknown Type|R| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Unknown Type|R| Unknown Type|R| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 13: Unknown attributes format + + Unknown Type: These 7-bit fields contain the Types of the attributes + (which were present in the message that triggered the Error message) + that were unknown to the receiver. + + R: At this point, this bit is reserved. It SHOULD be set to zero by + the sender of the message and MUST be ignored by the receiver. + +5.2.7. ERROR-INFO + + The following is the format of the ERROR-INFO attribute. + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 1 1|M| Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + / Text / + / +-+-+-+-+-+-+-+-+ + | | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 14: ERROR-INFO format + + Text: This field contains UTF-8 [6] encoded text. + + + +Camarillo, et al. Standards Track [Page 22] + +RFC 4582 BFCP November 2006 + + + In some situations, the contents of the Text field may be generated + by an automaton. If this automaton has information about the + preferred language of the receiver of a particular ERROR-INFO + attribute, it MAY use this language to generate the Text field. + + Padding: One, two, or three octets of padding added so that the + contents of the ERROR-INFO attribute is 32-bit aligned. The Padding + bits SHOULD be set to zero by the sender and MUST be ignored by the + receiver. If the attribute is already 32-bit aligned, no padding is + needed. + +5.2.8. PARTICIPANT-PROVIDED-INFO + + The following is the format of the PARTICIPANT-PROVIDED-INFO + attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 0|M| Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + / Text / + / +-+-+-+-+-+-+-+-+ + | | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 15: PARTICIPANT-PROVIDED-INFO format + + Text: This field contains UTF-8 [6] encoded text. + + Padding: One, two, or three octets of padding added so that the + contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit + aligned. The Padding bits SHOULD be set to zero by the sender and + MUST be ignored by the receiver. If the attribute is already 32-bit + aligned, no padding is needed. + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 23] + +RFC 4582 BFCP November 2006 + + +5.2.9. STATUS-INFO + + The following is the format of the STATUS-INFO attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1 0 0 1|M| Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + / Text / + / +-+-+-+-+-+-+-+-+ + | | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 16: STATUS-INFO format + + Text: This field contains UTF-8 [6] encoded text. + + In some situations, the contents of the Text field may be generated + by an automaton. If this automaton has information about the + preferred language of the receiver of a particular STATUS-INFO + attribute, it MAY use this language to generate the Text field. + + Padding: One, two, or three octets of padding added so that the + contents of the STATUS-INFO attribute is 32-bit aligned. The Padding + bits SHOULD be set to zero by the sender and MUST be ignored by the + receiver. If the attribute is already 32-bit aligned, no padding is + needed. + +5.2.10. SUPPORTED-ATTRIBUTES + + The following is the format of the SUPPORTED-ATTRIBUTES attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / / + / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 17: SUPPORTED-ATTRIBUTES format + + + +Camarillo, et al. Standards Track [Page 24] + +RFC 4582 BFCP November 2006 + + + Supp. Attr.: These fields contain the Types of the attributes that + are supported by the floor control server in the following format: + + R: Reserved: This bit MUST be set to zero upon transmission and MUST + be ignored upon reception. + + Padding: Two octets of padding added so that the contents of the + SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute + is already 32-bit aligned, no padding is needed. + + The Padding bits SHOULD be set to zero by the sender and MUST be + ignored by the receiver. + +5.2.11. SUPPORTED-PRIMITIVES + + The following is the format of the SUPPORTED-PRIMITIVES attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1 0 1 1|M| Length | Primitive | Primitive | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Primitive | Primitive | Primitive | Primitive | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / / + / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 18: SUPPORTED-PRIMITIVES format + + Primitive: These fields contain the types of the BFCP messages that + are supported by the floor control server. See Table 1 for the list + of BFCP primitives. + + Padding: One, two, or three octets of padding added so that the + contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If + the attribute is already 32-bit aligned, no padding is needed. + + The Padding bits SHOULD be set to zero by the sender and MUST be + ignored by the receiver. + + + + + + + + + +Camarillo, et al. Standards Track [Page 25] + +RFC 4582 BFCP November 2006 + + +5.2.12. USER-DISPLAY-NAME + + The following is the format of the USER-DISPLAY-NAME attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1 1 0 0|M| Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + / Text / + / +-+-+-+-+-+-+-+-+ + | | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 19: USER-DISPLAY-NAME format + + Text: This field contains the UTF-8 encoded name of the user. + + Padding: One, two, or three octets of padding added so that the + contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The + Padding bits SHOULD be set to zero by the sender and MUST be ignored + by the receiver. If the attribute is already 32-bit aligned, no + padding is needed. + +5.2.13. USER-URI + + The following is the format of the USER-URI attribute. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1 1 0 1|M| Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + / Text / + / +-+-+-+-+-+-+-+-+ + | | Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 20: USER-URI format + + Text: This field contains the UTF-8 encoded user's contact URI, that + is, the URI used by the user to set up the resources (e.g., media + streams) that are controlled by BFCP. For example, in the context of + a conference set up by SIP, the USER-URI attribute would carry the + SIP URI of the user. + + + + +Camarillo, et al. Standards Track [Page 26] + +RFC 4582 BFCP November 2006 + + + Messages containing a user's URI in a USER-URI attribute also + contain the user's User ID. This way, a client receiving such a + message can correlate the user's URI (e.g., the SIP URI the user + used to join a conference) with the user's User ID. + + Padding: One, two, or three octets of padding added so that the + contents of the USER-URI attribute is 32-bit aligned. The Padding + bits SHOULD be set to zero by the sender and MUST be ignored by the + receiver. If the attribute is already 32-bit aligned, no padding is + needed. + +5.2.14. BENEFICIARY-INFORMATION + + The BENEFICIARY-INFORMATION attribute is a grouped attribute that + consists of a header, which is referred to as BENEFICIARY- + INFORMATION-HEADER, followed by a sequence of attributes. The + following is the format of the BENEFICIARY-INFORMATION-HEADER: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1 1 1 0|M| Length | Beneficiary ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 21: BENEFICIARY-INFORMATION-HEADER format + + Beneficiary ID: This field contains a 16-bit value that uniquely + identifies a user within a conference. + + The following is the ABNF (Augmented Backus-Naur Form) [2] of the + BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE + refers to extension attributes that may be defined in the future.) + + BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) + [USER-DISPLAY-NAME] + [USER-URI] + *[EXTENSION-ATTRIBUTE] + + Figure 22: BENEFICIARY-INFORMATION format + +5.2.15. FLOOR-REQUEST-INFORMATION + + The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that + consists of a header, which is referred to as FLOOR-REQUEST- + INFORMATION-HEADER, followed by a sequence of attributes. The + following is the format of the FLOOR-REQUEST-INFORMATION-HEADER: + + + + + +Camarillo, et al. Standards Track [Page 27] + +RFC 4582 BFCP November 2006 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 1 1 1 1|M| Length | Floor Request ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 23: FLOOR-REQUEST-INFORMATION-HEADER format + + Floor Request ID: This field contains a 16-bit value that identifies + a floor request at the floor control server. + + The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped + attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that + may be defined in the future.) + + FLOOR-REQUEST-INFORMATION = (FLOOR-REQUEST-INFORMATION-HEADER) + [OVERALL-REQUEST-STATUS] + 1*(FLOOR-REQUEST-STATUS) + [BENEFICIARY-INFORMATION] + [REQUESTED-BY-INFORMATION] + [PRIORITY] + [PARTICIPANT-PROVIDED-INFO] + *[EXTENSION-ATTRIBUTE] + + Figure 24: FLOOR-REQUEST-INFORMATION format + +5.2.16. REQUESTED-BY-INFORMATION + + The REQUESTED-BY-INFORMATION attribute is a grouped attribute that + consists of a header, which is referred to as REQUESTED-BY- + INFORMATION-HEADER, followed by a sequence of attributes. The + following is the format of the REQUESTED-BY-INFORMATION-HEADER: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 1 0 0 0 0|M| Length | Requested-by ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 25: REQUESTED-BY-INFORMATION-HEADER format + + Requested-by ID: This field contains a 16-bit value that uniquely + identifies a user within a conference. + + The following is the ABNF of the REQUESTED-BY-INFORMATION grouped + attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that + may be defined in the future.) + + + + +Camarillo, et al. Standards Track [Page 28] + +RFC 4582 BFCP November 2006 + + + REQUESTED-BY-INFORMATION = (REQUESTED-BY-INFORMATION-HEADER) + [USER-DISPLAY-NAME] + [USER-URI] + *[EXTENSION-ATTRIBUTE] + + Figure 26: REQUESTED-BY-INFORMATION format + +5.2.17. FLOOR-REQUEST-STATUS + + The FLOOR-REQUEST-STATUS attribute is a grouped attribute that + consists of a header, which is referred to as + FLOOR-REQUEST-STATUS-HEADER, followed by a sequence of attributes. + The following is the format of the FLOOR-REQUEST-STATUS-HEADER: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 1 0 0 0 1|M| Length | Floor ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 27: FLOOR-REQUEST-STATUS-HEADER format + + Floor ID: this field contains a 16-bit value that uniquely identifies + a floor within a conference. + + The following is the ABNF of the FLOOR-REQUEST-STATUS grouped + attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that + may be defined in the future.) + + FLOOR-REQUEST-STATUS = (FLOOR-REQUEST-STATUS-HEADER) + [REQUEST-STATUS] + [STATUS-INFO] + *[EXTENSION-ATTRIBUTE] + + Figure 28: FLOOR-REQUEST-STATUS format + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 29] + +RFC 4582 BFCP November 2006 + + +5.2.18. OVERALL-REQUEST-STATUS + + The OVERALL-REQUEST-STATUS attribute is a grouped attribute that + consists of a header, which is referred to as + OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes. + The following is the format of the OVERALL-REQUEST-STATUS-HEADER: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 1 0 0 1 0|M| Length | Floor Request ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 29: OVERALL-REQUEST-STATUS-HEADER format + + Floor Request ID: this field contains a 16-bit value that identifies + a floor request at the floor control server. + + The following is the ABNF of the OVERALL-REQUEST-STATUS grouped + attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that + may be defined in the future.) + + OVERALL-REQUEST-STATUS = (OVERALL-REQUEST-STATUS-HEADER) + [REQUEST-STATUS] + [STATUS-INFO] + *[EXTENSION-ATTRIBUTE] + + Figure 30: OVERALL-REQUEST-STATUS format + +5.3. Message Format + + This section contains the normative ABNF (Augmented Backus-Naur Form) + [2] of the BFCP messages. Extension attributes that may be defined + in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF. + + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 30] + +RFC 4582 BFCP November 2006 + + +5.3.1. FloorRequest + + Floor participants request a floor by sending a FloorRequest message + to the floor control server. The following is the format of the + FloorRequest message: + + FloorRequest = (COMMON-HEADER) + 1*(FLOOR-ID) + [BENEFICIARY-ID] + [PARTICIPANT-PROVIDED-INFO] + [PRIORITY] + *[EXTENSION-ATTRIBUTE] + + Figure 31: FloorRequest format + +5.3.2. FloorRelease + + Floor participants release a floor by sending a FloorRelease message + to the floor control server. Floor participants also use the + FloorRelease message to cancel pending floor requests. The following + is the format of the FloorRelease message: + + FloorRelease = (COMMON-HEADER) + (FLOOR-REQUEST-ID) + *[EXTENSION-ATTRIBUTE] + + Figure 32: FloorRelease format + +5.3.3. FloorRequestQuery + + Floor participants and floor chairs request information about a floor + request by sending a FloorRequestQuery message to the floor control + server. The following is the format of the FloorRequestQuery + message: + + FloorRequestQuery = (COMMON-HEADER) + (FLOOR-REQUEST-ID) + *[EXTENSION-ATTRIBUTE] + + Figure 33: FloorRequestQuery format + +5.3.4. FloorRequestStatus + + The floor control server informs floor participants and floor chairs + about the status of their floor requests by sending them + FloorRequestStatus messages. The following is the format of the + FloorRequestStatus message: + + + + +Camarillo, et al. Standards Track [Page 31] + +RFC 4582 BFCP November 2006 + + + FloorRequestStatus = (COMMON-HEADER) + (FLOOR-REQUEST-INFORMATION) + *[EXTENSION-ATTRIBUTE] + + Figure 34: FloorRequestStatus format + +5.3.5. UserQuery + + Floor participants and floor chairs request information about a + participant and the floor requests related to this participant by + sending a UserQuery message to the floor control server. The + following is the format of the UserQuery message: + + UserQuery = (COMMON-HEADER) + [BENEFICIARY-ID] + *[EXTENSION-ATTRIBUTE] + + Figure 35: UserQuery format + +5.3.6. UserStatus + + The floor control server provides information about participants and + their related floor requests to floor participants and floor chairs + by sending them UserStatus messages. The following is the format of + the UserStatus message: + + UserStatus = (COMMON-HEADER) + [BENEFICIARY-INFORMATION] + *(FLOOR-REQUEST-INFORMATION) + *[EXTENSION-ATTRIBUTE] + + Figure 36: UserStatus format + +5.3.7. FloorQuery + + Floor participants and floor chairs request information about a floor + or floors by sending a FloorQuery message to the floor control + server. The following is the format of the FloorRequest message: + + FloorQuery = (COMMON-HEADER) + *(FLOOR-ID) + *[EXTENSION-ATTRIBUTE] + + Figure 37: FloorQuery format + + + + + + + +Camarillo, et al. Standards Track [Page 32] + +RFC 4582 BFCP November 2006 + + +5.3.8. FloorStatus + + The floor control server informs floor participants and floor chairs + about the status (e.g., the current holder) of a floor by sending + them FloorStatus messages. The following is the format of the + FloorStatus message: + + FloorStatus = (COMMON-HEADER) + *1(FLOOR-ID) + *[FLOOR-REQUEST-INFORMATION] + *[EXTENSION-ATTRIBUTE] + + Figure 38: FloorStatus format + +5.3.9. ChairAction + + Floor chairs send instructions to floor control servers by sending + ChairAction messages. The following is the format of the ChairAction + message: + + ChairAction = (COMMON-HEADER) + (FLOOR-REQUEST-INFORMATION) + *[EXTENSION-ATTRIBUTE] + + Figure 39: ChairAction format + +5.3.10. ChairActionAck + + Floor control servers confirm that they have accepted a ChairAction + message by sending a ChairActionAck message. The following is the + format of the ChairActionAck message: + + ChairActionAck = (COMMON-HEADER) + *[EXTENSION-ATTRIBUTE] + + Figure 40: ChairActionAck format + +5.3.11. Hello + + Floor participants and floor chairs check the liveliness of floor + control servers by sending a Hello message. The following is the + format of the Hello message: + + + Hello = (COMMON-HEADER) + *[EXTENSION-ATTRIBUTE] + + Figure 41: Hello format + + + +Camarillo, et al. Standards Track [Page 33] + +RFC 4582 BFCP November 2006 + + +5.3.12. HelloAck + + Floor control servers confirm that they are alive on reception of a + Hello message by sending a HelloAck message. The following is the + format of the HelloAck message: + + HelloAck = (COMMON-HEADER) + (SUPPORTED-PRIMITIVES) + (SUPPORTED-ATTRIBUTES) + *[EXTENSION-ATTRIBUTE] + + Figure 42: HelloAck format + +5.3.13. Error + + Floor control servers inform floor participants and floor chairs + about errors processing requests by sending them Error messages. The + following is the format of the Error message: + + Error = (COMMON-HEADER) + (ERROR-CODE) + [ERROR-INFO] + *[EXTENSION-ATTRIBUTE] + + Figure 43: Error format + +6. Transport + + BFCP entities exchange BFCP messages using TCP connections. TCP + provides an in-order reliable delivery of a stream of bytes. + Consequently, message framing is implemented in the application + layer. BFCP implements application-layer framing using TLV-encoded + attributes. + + A client MUST NOT use more than one TCP connection to communicate + with a given floor control server within a conference. Nevertheless, + if the same physical box handles different clients (e.g., a floor + chair and a floor participant), which are identified by different + User IDs, a separate connection per client is allowed. + + If a BFCP entity (a client or a floor control server) receives data + from TCP that cannot be parsed, the entity MUST close the TCP + connection, and the connection SHOULD be reestablished. Similarly, + if a TCP connection cannot deliver a BFCP message and times out, the + TCP connection SHOULD be reestablished. + + + + + + +Camarillo, et al. Standards Track [Page 34] + +RFC 4582 BFCP November 2006 + + + The way connection reestablishment is handled depends on how the + client obtains information to contact the floor control server (e.g., + using an SDP offer/answer exchange [7]). Once the TCP connection is + reestablished, the client MAY resend those messages for which it did + not get a response from the floor control server. + + If a floor control server detects that the TCP connection towards one + of the floor participants is lost, it is up to the local policy of + the floor control server what to do with the pending floor requests + of the floor participant. In any case, it is RECOMMENDED that the + floor control server keep the floor requests (i.e., that it does not + cancel them) while the TCP connection is reestablished. + + If a client wishes to end its BFCP connection with a floor control + server, the client closes (i.e., a graceful close) the TCP connection + towards the floor control server. If a floor control server wishes + to end its BFCP connection with a client (e.g., the Focus of the + conference informs the floor control server that the client has been + kicked out from the conference), the floor control server closes + (i.e., a graceful close) the TCP connection towards the client. + +7. Lower-Layer Security + + BFCP relies on lower-layer security mechanisms to provide replay and + integrity protection and confidentiality. BFCP floor control servers + and clients (which include both floor participants and floor chairs) + MUST support TLS [3]. Any BFCP entity MAY support other security + mechanisms. + + BFCP entities MUST support, at a minimum, the TLS + TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [5]. + + Which party, the client or the floor control server, acts as the TLS + server depends on how the underlying TCP connection is established. + For example, when the TCP connection is established using an SDP + offer/answer exchange [7], the answerer (which may be the client or + the floor control server) always acts as the TLS server. + +8. Protocol Transactions + + In BFCP, there are two types of transactions: client-initiated + transactions and server-initiated transactions (notifications). + Client-initiated transactions consist of a request from a client to a + floor control server and a response from the floor control server to + the client. The request carries a Transaction ID in its common + header, which the floor control server copies into the response. + Clients use Transaction ID values to match responses with previously + issued requests. + + + +Camarillo, et al. Standards Track [Page 35] + +RFC 4582 BFCP November 2006 + + + Server-initiated transactions consist of a single message from a + floor control server to a client. Since they do not trigger any + response, their Transaction ID is set to 0. + +8.1. Client Behavior + + A client starting a client-initiated transaction MUST set the + Conference ID in the common header of the message to the Conference + ID for the conference that the client obtained previously. + + The client MUST set the Transaction ID value in the common header to + a number that is different from 0 and that MUST NOT be reused in + another message from the client until a response from the server is + received for the transaction. The client uses the Transaction ID + value to match this message with the response from the floor control + server. + +8.2. Server Behavior + + A floor control server sending a response within a client-initiated + transaction MUST copy the Conference ID, the Transaction ID, and the + User ID from the request received from the client into the response. + Server-initiated transactions MUST contain a Transaction ID equal to + 0. + +9. Authentication and Authorization + + BFCP clients SHOULD authenticate the floor control server before + sending any BFCP message to it or accepting any BFCP message from it. + Similarly, floor control servers SHOULD authenticate a client before + accepting any BFCP message from it or sending any BFCP message to it. + + BFCP supports TLS-based mutual authentication between clients and + floor control servers, as specified in Section 9.1. This is the + RECOMMENDED authentication mechanism in BFCP. + + Note that future extensions may define additional authentication + mechanisms. + + In addition to authenticating BFCP messages, floor control servers + need to authorize them. On receiving an authenticated BFCP message, + the floor control server checks whether the client sending the + message is authorized. If the client is not authorized to perform + the operation being requested, the floor control server generates an + Error message, as described in Section 13.8, with an Error code with + a value of 5 (Unauthorized Operation). Messages from a client that + cannot be authorized MUST NOT be processed further. + + + + +Camarillo, et al. Standards Track [Page 36] + +RFC 4582 BFCP November 2006 + + +9.1. TLS-Based Mutual Authentication + + BFCP supports TLS-based mutual authentication between clients and + floor control servers. BFCP assumes that there is an integrity- + protected channel between the client and the floor control server + that can be used to exchange their self-signed certificates or, more + commonly, the fingerprints of these certificates. These certificates + are used at TLS establishment time. + + The implementation of such an integrity-protected channel using + SIP and the SDP offer/answer model is described in [7]. + + BFCP messages received over an authenticated TLS connection are + considered authenticated. A floor control server that receives a + BFCP message over TCP (no TLS) can request the use of TLS by + generating an Error message, as described in Section 13.8, with an + Error code with a value of 9 (Use TLS). Clients SHOULD simply ignore + unauthenticated messages. + + Note that future extensions may define additional authentication + mechanisms that may not require an initial integrity-protected + channel (e.g., authentication based on certificates signed by a + certificate authority). + + As described in Section 9, floor control servers need to perform + authorization before processing any message. In particular, the + floor control server SHOULD check that messages arriving over a given + authenticated TLS connection use an authorized User ID (i.e., a User + ID that the user that established the authenticated TLS connection is + allowed to use). + +10. Floor Participant Operations + + This section specifies how floor participants can perform different + operations, such as requesting a floor, using the protocol elements + described in earlier sections. Section 11 specifies operations that + are specific to floor chairs, such as instructing the floor control + server to grant or revoke a floor, and Section 12 specifies + operations that can be performed by any client (i.e., both floor + participants and floor chairs). + +10.1. Requesting a Floor + + A floor participant that wishes to request one or more floors does so + by sending a FloorRequest message to the floor control server. + + + + + + +Camarillo, et al. Standards Track [Page 37] + +RFC 4582 BFCP November 2006 + + +10.1.1. Sending a FloorRequest Message + + The ABNF in Section 5.3.1 describes the attributes that a + FloorRequest message can contain. In addition, the ABNF specifies + normatively which of these attributes are mandatory, and which ones + are optional. + + The floor participant sets the Conference ID and the Transaction ID + in the common header following the rules given in Section 8.1. + + The floor participant sets the User ID in the common header to the + floor participant's identifier. This User ID will be used by the + floor control server to authenticate and authorize the request. If + the sender of the FloorRequest message (identified by the User ID) is + not the participant that would eventually get the floor (i.e., a + third-party floor request), the sender SHOULD add a BENEFICIARY-ID + attribute to the message identifying the beneficiary of the floor. + + Note that the name space for both the User ID and the Beneficiary + ID is the same. That is, a given participant is identified by a + single 16-bit value that can be used in the User ID in the common + header and in several attributes: BENEFICIARY-ID, BENEFICIARY- + INFORMATION, and REQUESTED-BY-INFORMATION. + + The floor participant must insert at least one FLOOR-ID attribute in + the FloorRequest message. If the client inserts more than one + FLOOR-ID attribute, the floor control server will treat all the floor + requests as an atomic package. That is, the floor control server + will either grant or deny all the floors in the FloorRequest message. + + The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute + to state the reason why the floor or floors are being requested. The + Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for + human consumption. + + The floor participant may request that the server handle the floor + request with a certain priority using a PRIORITY attribute. + +10.1.2. Receiving a Response + + A message from the floor control server is considered a response to + the FloorRequest message if the message from the floor control server + has the same Conference ID, Transaction ID, and User ID as the + FloorRequest message, as described in Section 8.1. On receiving such + a response, the floor participant follows the rules in Section 9 that + relate to floor control server authentication. + + + + + +Camarillo, et al. Standards Track [Page 38] + +RFC 4582 BFCP November 2006 + + + The successful processing of a FloorRequest message at the floor + control server involves generating one or several FloorRequestStatus + messages. The floor participant obtains a Floor Request ID in the + Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in + the first FloorRequestStatus message from the floor control server. + Subsequent FloorRequestStatus messages from the floor control server + regarding the same floor request will carry the same Floor Request ID + in a FLOOR-REQUEST-INFORMATION attribute as the initial + FloorRequestStatus message. This way, the floor participant can + associate subsequent incoming FloorRequestStatus messages with the + ongoing floor request. + + The floor participant obtains information about the status of the + floor request in the FLOOR-REQUEST-INFORMATION attribute of each of + the FloorRequestStatus messages received from the floor control + server. This attribute is a grouped attribute, and as such it + includes a number of attributes that provide information about the + floor request. + + The OVERALL-REQUEST-STATUS attribute provides information about the + overall status of the floor request. If the Request Status value is + Granted, all the floors that were requested in the FloorRequest + message have been granted. If the Request Status value is Denied, + all the floors that were requested in the FloorRequest message have + been denied. A floor request is considered to be ongoing while it is + in the Pending, Accepted, or Granted states. If the floor request + value is unknown, then the response is still processed. However, no + meaningful value can be reported to the user. + + The STATUS-INFO attribute, if present, provides extra information + that the floor participant MAY display to the user. + + The FLOOR-REQUEST-STATUS attributes provide information about the + status of the floor request as it relates to a particular floor. The + STATUS-INFO attribute, if present, provides extra information that + the floor participant MAY display to the user. + + The BENEFICIARY-INFORMATION attribute identifies the beneficiary of + the floor request in third-party floor requests. The + REQUESTED-BY-INFORMATION attribute need not be present in + FloorRequestStatus messages received by the floor participant that + requested the floor, as this floor participant is already identified + by the User ID in the common header. + + The PRIORITY attribute, when present, contains the priority that was + requested by the generator of the FloorRequest message. + + + + + +Camarillo, et al. Standards Track [Page 39] + +RFC 4582 BFCP November 2006 + + + If the response is an Error message, the floor control server could + not process the FloorRequest message for some reason, which is + described in the Error message. + +10.2. Cancelling a Floor Request and Releasing a Floor + + A floor participant that wishes to cancel an ongoing floor request + does so by sending a FloorRelease message to the floor control + server. The FloorRelease message is also used by floor participants + that hold a floor and would like to release it. + +10.2.1. Sending a FloorRelease Message + + The ABNF in Section 5.3.2 describes the attributes that a + FloorRelease message can contain. In addition, the ABNF specifies + normatively which of these attributes are mandatory, and which ones + are optional. + + The floor participant sets the Conference ID and the Transaction ID + in the common header following the rules given in Section 8.1. The + floor participant sets the User ID in the common header to the floor + participant's identifier. This User ID will be used by the floor + control server to authenticate and authorize the request. + + Note that the FloorRelease message is used to release a floor or + floors that were granted and to cancel ongoing floor requests + (from the protocol perspective, both are ongoing floor requests). + Using the same message in both situations helps resolve the race + condition that occurs when the FloorRelease message and the + FloorGrant message cross each other on the wire. + + The floor participant uses the FLOOR-REQUEST-ID that was received in + the response to the FloorRequest message that the FloorRelease + message is cancelling. + + Note that if the floor participant requested several floors as an + atomic operation (i.e., in a single FloorRequest message), all the + floors are released as an atomic operation as well (i.e., all are + released at the same time). + +10.2.2. Receiving a Response + + A message from the floor control server is considered a response to + the FloorRelease message if the message from the floor control server + has the same Conference ID, Transaction ID, and User ID as the + FloorRequest message, as described in Section 8.1. On receiving such + a response, the floor participant follows the rules in Section 9 that + relate to floor control server authentication. + + + +Camarillo, et al. Standards Track [Page 40] + +RFC 4582 BFCP November 2006 + + + If the response is a FloorRequestStatus message, the Request Status + value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR- + REQUEST-INFORMATION grouped attribute) will be Cancelled or Released. + + If the response is an Error message, the floor control server could + not process the FloorRequest message for some reason, which is + described in the Error message. + + It is possible that the FloorRelease message crosses on the wire with + a FloorRequestStatus message from the server with a Request Status + different from Cancelled or Released. In any case, such a + FloorRequestStatus message will not be a response to the FloorRelease + message, as its Transaction ID will not match that of the + FloorRelease. + +11. Chair Operations + + This section specifies how floor chairs can instruct the floor + control server to grant or revoke a floor using the protocol elements + described in earlier sections. + + Floor chairs that wish to send instructions to a floor control server + do so by sending a ChairAction message. + +11.1. Sending a ChairAction Message + + The ABNF in Section 5.3.9 describes the attributes that a ChairAction + message can contain. In addition, the ABNF specifies normatively + which of these attributes are mandatory, and which ones are optional. + + The floor chair sets the Conference ID and the Transaction ID in the + common header following the rules given in Section 8.1. The floor + chair sets the User ID in the common header to the floor + participant's identifier. This User ID will be used by the floor + control server to authenticate and authorize the request. + + The ChairAction message contains instructions that apply to one or + more floors within a particular floor request. The floor or floors + are identified by the FLOOR-REQUEST-STATUS attributes and the floor + request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which + are carried in the ChairAction message. + + For example, if a floor request consists of two floors that depend on + different floor chairs, each floor chair will grant its floor within + the floor request. Once both chairs have granted their floor, the + floor control server will grant the floor request as a whole. On the + other hand, if one of the floor chairs denies its floor, the floor + + + + +Camarillo, et al. Standards Track [Page 41] + +RFC 4582 BFCP November 2006 + + + control server will deny the floor request as a whole, regardless of + the other floor chair's decision. + + The floor chair provides the new status of the floor request as it + relates to a particular floor using a FLOOR-REQUEST-STATUS attribute. + If the new status of the floor request is Accepted, the floor chair + MAY use the Queue Position field to provide a queue position for the + floor request. If the floor chair does not wish to provide a queue + position, all the bits of the Queue Position field SHOULD be set to + zero. The floor chair SHOULD use the Status Revoked to revoke a + floor that was granted (i.e., Granted status) and SHOULD use the + Status Denied to reject floor requests in any other status (e.g., + Pending and Accepted). + + The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the + ChairAction message to provide a new overall status for the floor + request. If the new overall status of the floor request is Accepted, + the floor chair MAY use the Queue Position field to provide a queue + position for the floor request. + + Note that a particular floor control server may implement a + different queue for each floor containing all the floor requests + that relate to that particular floor, a general queue for all + floor requests, or both. Also note that a floor request may + involve several floors and that a ChairAction message may only + deal with a subset of these floors (e.g., if a single floor chair + is not authorized to manage all the floors). In this case, the + floor control server will combine the instructions received from + the different floor chairs in FLOOR-REQUEST-STATUS attributes to + come up with the overall status of the floor request. + + Note that, while the action of a floor chair may communicate + information in the OVERALL-REQUEST-STATUS attribute, the floor + control server may override, modify, or ignore this field's + content. + + The floor chair may use STATUS-INFO attributes to state the reason + why the floor or floors are being accepted, granted, or revoked. The + Text in the STATUS-INFO attribute is intended for human consumption. + +11.2. Receiving a Response + + A message from the floor control server is considered a response to + the ChairAction message if the message from the server has the same + Conference ID, Transaction ID, and User ID as the ChairAction + message, as described in Section 8.1. On receiving such a response, + the floor chair follows the rules in Section 9 that relate to floor + control server authentication. + + + +Camarillo, et al. Standards Track [Page 42] + +RFC 4582 BFCP November 2006 + + + A ChairActionAck message from the floor control server confirms that + the floor control server has accepted the ChairAction message. An + Error message indicates that the floor control server could not + process the ChairAction message for some reason, which is described + in the Error message. + +12. General Client Operations + + This section specifies operations that can be performed by any + client. That is, they are not specific to floor participants or + floor chairs. They can be performed by both. + +12.1. Requesting Information about Floors + + A client can obtain information about the status of a floor or floors + in different ways, which include using BFCP and using out-of-band + mechanisms. Clients using BFCP to obtain such information use the + procedures described in this section. + + Clients request information about the status of one or several floors + by sending a FloorQuery message to the floor control server. + +12.1.1. Sending a FloorQuery Message + + The ABNF in Section 5.3.7 describes the attributes that a FloorQuery + message can contain. In addition, the ABNF specifies normatively + which of these attributes are mandatory, and which ones are optional. + + The client sets the Conference ID and the Transaction ID in the + common header following the rules given in Section 8.1. The client + sets the User ID in the common header to the client's identifier. + This User ID will be used by the floor control server to authenticate + and authorize the request. + + The client inserts in the message all the Floor IDs it wants to + receive information about. The floor control server will send + periodic information about all of these floors. If the client does + not want to receive information about a particular floor any longer, + it sends a new FloorQuery message removing the FLOOR-ID of this + floor. If the client does not want to receive information about any + floor any longer, it sends a FloorQuery message with no FLOOR-ID + attribute. + +12.1.2. Receiving a Response + + A message from the floor control server is considered a response to + the FloorQuery message if the message from the floor control server + has the same Conference ID, Transaction ID, and User ID as the + + + +Camarillo, et al. Standards Track [Page 43] + +RFC 4582 BFCP November 2006 + + + FloorRequest message, as described in Section 8.1. On receiving such + a response, the client follows the rules in Section 9 that relate to + floor control server authentication. + + On reception of the FloorQuery message, the floor control server will + respond with a FloorStatus message or with an Error message. If the + response is a FloorStatus message, it will contain information about + one of the floors the client requested information about. If the + client did not include any FLOOR-ID attribute in its FloorQuery + message (i.e., the client does not want to receive information about + any floor any longer), the FloorStatus message from the floor control + server will not include any FLOOR-ID attribute either. + + FloorStatus messages that carry information about a floor contain a + FLOOR-ID attribute that identifies the floor. After this attribute, + FloorStatus messages contain information about existing (one or more) + floor requests that relate to that floor. The information about each + particular floor request is encoded in a FLOOR-REQUEST-INFORMATION + attribute. This grouped attribute carries a Floor Request ID that + identifies the floor request, followed by a set of attributes that + provide information about the floor request. + + After the first FloorStatus, the floor control server will continue + sending FloorStatus messages, periodically informing the client about + changes on the floors the client requested information about. + +12.2. Requesting Information about Floor Requests + + A client can obtain information about the status of one or several + floor requests in different ways, which include using BFCP and using + out-of-band mechanisms. Clients using BFCP to obtain such + information use the procedures described in this section. + + Clients request information about the current status of a floor + request by sending a FloorRequestQuery message to the floor control + server. + + Requesting information about a particular floor request is useful in + a number of situations. For example, on reception of a FloorRequest + message, a floor control server may choose to return + FloorRequestStatus messages only when the floor request changes its + state (e.g., from Accepted to Granted), but not when the floor + request advances in its queue. In this situation, if the user + requests it, the floor participant can use a FloorRequestQuery + message to poll the floor control server for the status of the floor + request. + + + + + +Camarillo, et al. Standards Track [Page 44] + +RFC 4582 BFCP November 2006 + + +12.2.1. Sending a FloorRequestQuery Message + + The ABNF in Section 5.3.3 describes the attributes that a + FloorRequestQuery message can contain. In addition, the ABNF + specifies normatively which of these attributes are mandatory, and + which ones are optional. + + The client sets the Conference ID and the Transaction ID in the + common header following the rules given in Section 8.1. The client + sets the User ID in the common header to the client's identifier. + This User ID will be used by the floor control server to authenticate + and authorize the request. + + The client must insert a FLOOR-REQUEST-ID attribute that identifies + the floor request at the floor control server. + +12.2.2. Receiving a Response + + A message from the floor control server is considered a response to + the FloorRequestQuery message if the message from the floor control + server has the same Conference ID, Transaction ID, and User ID as the + FloorRequestQuery message, as described in Section 8.1. On receiving + such a response, the client follows the rules in Section 9 that + relate to floor control server authentication. + + If the response is a FloorRequestStatus message, the client obtains + information about the status of the FloorRequest the client requested + information about in a FLOOR-REQUEST-INFORMATION attribute. + + If the response is an Error message, the floor control server could + not process the FloorRequestQuery message for some reason, which is + described in the Error message. + +12.3. Requesting Information about a User + + A client can obtain information about a participant and the floor + requests related to this participant in different ways, which include + using BFCP and using out-of-band mechanisms. Clients using BFCP to + obtain such information use the procedures described in this section. + + Clients request information about a participant and the floor + requests related to this participant by sending a UserQuery message + to the floor control server. + + This functionality may be useful for floor chairs or floor + participants interested in the display name and the URI of a + particular floor participant. In addition, a floor participant may + find it useful to request information about itself. For example, a + + + +Camarillo, et al. Standards Track [Page 45] + +RFC 4582 BFCP November 2006 + + + floor participant, after experiencing connectivity problems (e.g., + its TCP connection with the floor control server was down for a while + and eventually was re-established), may need to request information + about all the floor requests associated to itself that still exist. + +12.3.1. Sending a UserQuery Message + + The ABNF in Section 5.3.5 describes the attributes that a UserQuery + message can contain. In addition, the ABNF specifies normatively + which of these attributes are mandatory, and which ones are optional. + + The client sets the Conference ID and the Transaction ID in the + common header following the rules given in Section 8.1. The client + sets the User ID in the common header to the client's identifier. + This User ID will be used by the floor control server to authenticate + and authorize the request. + + If the floor participant the client is requesting information about + is not the client issuing the UserQuery message (which is identified + by the User ID in the common header of the message), the client MUST + insert a BENEFICIARY-ID attribute. + +12.3.2. Receiving a Response + + A message from the floor control server is considered a response to + the UserQuery message if the message from the floor control server + has the same Conference ID, Transaction ID, and User ID as the + UserQuery message, as described in Section 8.1. On receiving such a + response, the client follows the rules in Section 9 that relate to + floor control server authentication. + + If the response is a UserStatus message, the client obtains + information about the floor participant in a BENEFICIARY-INFORMATION + grouped attribute and about the status of the floor requests + associated with the floor participant in FLOOR-REQUEST-INFORMATION + attributes. + + If the response is an Error message, the floor control server could + not process the UserQuery message for some reason, which is described + in the Error message. + +12.4. Obtaining the Capabilities of a Floor Control Server + + A client that wishes to obtain the capabilities of a floor control + server does so by sending a Hello message to the floor control + server. + + + + + +Camarillo, et al. Standards Track [Page 46] + +RFC 4582 BFCP November 2006 + + +12.4.1. Sending a Hello Message + + The ABNF in Section 5.3.11 describes the attributes that a Hello + message can contain. In addition, the ABNF specifies normatively + which of these attributes are mandatory, and which ones are optional. + + The client sets the Conference ID and the Transaction ID in the + common header following the rules given in Section 8.1. The client + sets the User ID in the common header to the client's identifier. + This User ID will be used by the floor control server to authenticate + and authorize the request. + +12.4.2. Receiving Responses + + A message from the floor control server is considered a response to + the Hello message by the client if the message from the floor control + server has the same Conference ID, Transaction ID, and User ID as the + Hello message, as described in Section 8.1. On receiving such a + response, the client follows the rules in Section 9 that relate to + floor control server authentication. + + If the response is a HelloAck message, the floor control server could + process the Hello message successfully. The SUPPORTED-PRIMITVIES and + SUPPORTED-ATTRIBUTES attributes indicate which primitives and + attributes, respectively, are supported by the server. + + If the response is an Error message, the floor control server could + not process the Hello message for some reason, which is described in + the Error message. + +13. Floor Control Server Operations + + This section specifies how floor control servers can perform + different operations, such as granting a floor, using the protocol + elements described in earlier sections. + + On reception of a message from a client, the floor control server + MUST check whether the value of the Primitive is supported. If it + does not, the floor control server SHOULD send an Error message, as + described in Section 13.8, with Error code 3 (Unknown Primitive). + + On reception of a message from a client, the floor control server + MUST check whether the value of the Conference ID matched an existing + conference. If it does not, the floor control server SHOULD send an + Error message, as described in Section 13.8, with Error code 1 + (Conference does not Exist). + + + + + +Camarillo, et al. Standards Track [Page 47] + +RFC 4582 BFCP November 2006 + + + On reception of a message from a client, the floor control server + follows the rules in Section 9 that relate to the authentication of + the message. + + On reception of a message from a client, the floor control server + MUST check whether it understands all the mandatory ('M' bit set) + attributes in the message. If the floor control server does not + understand all of them, the floor control server SHOULD send an Error + message, as described in Section 13.8, with Error code 2 + (Authentication Failed). The Error message SHOULD list the + attributes that were not understood. + +13.1. Reception of a FloorRequest Message + + On reception of a FloorRequest message, the floor control server + follows the rules in Section 9 that relate to client authentication + and authorization. If while processing the FloorRequest message, the + floor control server encounters an error, it SHOULD generate an Error + response following the procedures described in Section 13.8. + + BFCP allows floor participants to have several ongoing floor + requests for the same floor (e.g., the same floor participant can + occupy more than one position in a queue at the same time). A + floor control server that only supports a certain number of + ongoing floor requests per floor participant (e.g., one) can use + Error Code 8 (You have Already Reached the Maximum Number of + Ongoing Floor Requests for this Floor) to inform the floor + participant. + +13.1.1. Generating the First FloorRequestStatus Message + + The successful processing of a FloorRequest message by a floor + control server involves generating one or several FloorRequestStatus + messages, the first of which SHOULD be generated as soon as possible. + If the floor control server cannot accept, grant, or deny the floor + request right away (e.g., a decision from a chair is needed), it + SHOULD use a Request Status value of Pending in the OVERALL-REQUEST- + STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped + attribute) of the first FloorRequestStatus message it generates. + + The policy that a floor control server follows to grant or deny + floors is outside the scope of this document. A given floor + control server may perform these decisions automatically while + another may contact a human acting as a chair every time a + decision needs to be made. + + The floor control server MUST copy the Conference ID, the Transaction + ID, and the User ID from the FloorRequest into the + + + +Camarillo, et al. Standards Track [Page 48] + +RFC 4582 BFCP November 2006 + + + FloorRequestStatus, as described in Section 8.2. Additionally, the + floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped + attribute to the FloorRequestStatus. The attributes contained in + this grouped attribute carry information about the floor request. + + The floor control server MUST assign an identifier that is unique + within the conference to this floor request, and MUST insert it in + the Floor Request ID field of the FLOOR-REQUEST-INFORMATION + attribute. This identifier will be used by the floor participant (or + by a chair or chairs) to refer to this specific floor request in the + future. + + The floor control server MUST copy the Floor IDs in the FLOOR-ID + attributes of the FloorRequest into the FLOOR-REQUEST-STATUS + attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These + Floor IDs identify the floors being requested (i.e., the floors + associated with this particular floor request). + + The floor control server SHOULD copy (if present) the contents of the + BENEFICIARY-ID attribute from the FloorRequest into a + BENEFICIARY-INFORMATION attribute inside the + FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, the floor + control server MAY provide the display name and the URI of the + beneficiary in this BENEFICIARY-INFORMATION attribute. + + The floor control server MAY provide information about the requester + of the floor in a REQUESTED-BY-INFORMATION attribute inside the + FLOOR-REQUEST-INFORMATION grouped attribute. + + The floor control server MAY copy (if present) the PARTICIPANT- + PROVIDED-INFO attribute from the FloorRequest into the FLOOR- + REQUEST-INFORMATION grouped attribute. + + Note that this attribute carries the priority requested by the + participant. The priority that the floor control server assigns + to the floor request depends on the priority requested by the + participant and the rights the participant has according to the + policy of the conference. For example, a participant that is only + allowed to use the Normal priority may request Highest priority + for a floor request. In that case, the floor control server would + ignore the priority requested by the participant. + + The floor control server MAY copy (if present) the + PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the + FLOOR-REQUEST-INFORMATION grouped attribute. + + + + + + +Camarillo, et al. Standards Track [Page 49] + +RFC 4582 BFCP November 2006 + + +13.1.2. Generation of Subsequent FloorRequestStatus Messages + + A floor request is considered to be ongoing as long as it is not in + the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST- + STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped + attribute) of the first FloorRequestStatus message generated by the + floor control server did not indicate any of these states, the floor + control server will need to send subsequent FloorRequestStatus + messages. + + When the status of the floor request changes, the floor control + server SHOULD send new FloorRequestStatus messages with the + appropriate Request Status. The floor control server MUST add a + FLOOR-REQUEST-INFORMATION attribute with a Floor Request ID equal to + the one sent in the first FloorRequestStatus message to any new + FloorRequestStatus related to the same floor request. (The Floor + Request ID identifies the floor request to which the + FloorRequestStatus applies.) + + The floor control server MUST set the Transaction ID of subsequent + FloorRequestStatus messages to 0. + + The rate at which the floor control server sends + FloorRequestStatus messages is a matter of local policy. A floor + control server may choose to send a new FloorRequestStatus message + every time the floor request moves in the floor request queue, + while another may choose only to send a new FloorRequestStatus + message when the floor request is Granted or Denied. + + The floor control server may add a STATUS-INFO attribute to any of + the FloorRequestStatus messages it generates to provide extra + information about its decisions regarding the floor request (e.g., + why it was denied). + + Floor participants and floor chairs may request to be informed + about the status of a floor following the procedures in + Section 12.1. If the processing of a floor request changes the + status of a floor (e.g., the floor request is granted and + consequently the floor has a new holder), the floor control server + needs to follow the procedures in Section 13.5 to inform the + clients that have requested that information. + + The common header and the rest of the attributes are the same as in + the first FloorRequestStatus message. + + The floor control server can discard the state information about a + particular floor request when this reaches a status of Cancelled, + Released, or Revoked. + + + +Camarillo, et al. Standards Track [Page 50] + +RFC 4582 BFCP November 2006 + + +13.2. Reception of a FloorRequestQuery Message + + On reception of a FloorRequestQuery message, the floor control server + follows the rules in Section 9 that relate to client authentication + and authorization. If while processing the FloorRequestQuery + message, the floor control server encounters an error, it SHOULD + generate an Error response following the procedures described in + Section 13.8. + + The successful processing of a FloorRequestQuery message by a floor + control server involves generating a FloorRequestStatus message, + which SHOULD be generated as soon as possible. + + The floor control server MUST copy the Conference ID, the Transaction + ID, and the User ID from the FloorRequestQuery message into the + FloorRequestStatus message, as described in Section 8.2. + Additionally, the floor control server MUST include information about + the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute + to the FloorRequestStatus. + + The floor control server MUST copy the contents of the + FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into + the Floor Request ID field of the FLOOR-REQUEST-INFORMATION + attribute. + + The floor control server MUST add FLOOR-REQUEST-STATUS attributes to + the FLOOR-REQUEST-INFORMATION grouped attribute identifying the + floors being requested (i.e., the floors associated with the floor + request identified by the FLOOR-REQUEST-ID attribute). + + The floor control server SHOULD add a BENEFICIARY-ID attribute to the + FLOOR-REQUEST-INFORMATION grouped attribute identifying the + beneficiary of the floor request. Additionally, the floor control + server MAY provide the display name and the URI of the beneficiary in + this BENEFICIARY-INFORMATION attribute. + + The floor control server MAY provide information about the requester + of the floor in a REQUESTED-BY-INFORMATION attribute inside the + FLOOR-REQUEST-INFORMATION grouped attribute. + + The floor control server MAY provide the reason why the floor + participant requested the floor in a PARTICIPANT-PROVIDED-INFO. + + The floor control server MAY also add to the + FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with + the Priority value requested for the floor request and a STATUS-INFO + attribute with extra information about the floor request. + + + + +Camarillo, et al. Standards Track [Page 51] + +RFC 4582 BFCP November 2006 + + + The floor control server MUST add an OVERALL-REQUEST-STATUS attribute + to the FLOOR-REQUEST-INFORMATION grouped attribute with the current + status of the floor request. The floor control server MAY provide + information about the status of the floor request as it relates to + each of the floors being requested in the FLOOR-REQUEST-STATUS + attributes. + +13.3. Reception of a UserQuery Message + + On reception of a UserQuery message, the floor control server follows + the rules in Section 9 that relate to client authentication and + authorization. If while processing the UserQuery message, the floor + control server encounters an error, it SHOULD generate an Error + response following the procedures described in Section 13.8. + + The successful processing of a UserQuery message by a floor control + server involves generating a UserStatus message, which SHOULD be + generated as soon as possible. + + The floor control server MUST copy the Conference ID, the Transaction + ID, and the User ID from the UserQuery message into the USerStatus + message, as described in Section 8.2. + + The sender of the UserQuery message is requesting information about + all the floor requests associated with a given participant (i.e., the + floor requests where the participant is either the beneficiary or the + requester). This participant is identified by a BENEFICIARY-ID + attribute or, in the absence of a BENEFICIARY-ID attribute, by a the + User ID in the common header of the UserQuery message. + + The floor control server MUST copy, if present, the contents of the + BENEFICIARY-ID attribute from the UserQuery message into a + BENEFICIARY-INFORMATION attribute in the UserStatus message. + Additionally, the floor control server MAY provide the display name + and the URI of the participant about which the UserStatus message + provides information in this BENEFICIARY-INFORMATION attribute. + + The floor control server SHOULD add to the UserStatus message a + FLOOR-REQUEST-INFORMATION grouped attribute for each floor request + related to the participant about which the message provides + information (i.e., the floor requests where the participant is either + the beneficiary or the requester). For each + FLOOR-REQUEST-INFORMATION attribute, the floor control server follows + the following steps. + + The floor control server MUST identify the floor request the + FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor + Request ID field of the FLOOR-REQUEST-INFORMATION attribute. + + + +Camarillo, et al. Standards Track [Page 52] + +RFC 4582 BFCP November 2006 + + + The floor control server MUST add FLOOR-REQUEST-STATUS attributes to + the FLOOR-REQUEST-INFORMATION grouped attribute identifying the + floors being requested (i.e., the floors associated with the floor + request identified by the FLOOR-REQUEST-ID attribute). + + The floor control server SHOULD add a BENEFICIARY-ID attribute to the + FLOOR-REQUEST-INFORMATION grouped attribute identifying the + beneficiary of the floor request. Additionally, the floor control + server MAY provide the display name and the URI of the beneficiary in + this BENEFICIARY-INFORMATION attribute. + + The floor control server MAY provide information about the requester + of the floor in a REQUESTED-BY-INFORMATION attribute inside the + FLOOR-REQUEST-INFORMATION grouped attribute. + + The floor control server MAY provide the reason why the floor + participant requested the floor in a PARTICIPANT-PROVIDED-INFO. + + The floor control server MAY also add to the FLOOR-REQUEST- + INFORMATION grouped attribute a PRIORITY attribute with the Priority + value requested for the floor request. + + The floor control server MUST include the current status of the floor + request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST- + INFORMATION grouped attribute. The floor control server MAY add a + STATUS-INFO attribute with extra information about the floor request. + + The floor control server MAY provide information about the status of + the floor request as it relates to each of the floors being requested + in the FLOOR-REQUEST-STATUS attributes. + +13.4. Reception of a FloorRelease Message + + On reception of a FloorRelease message, the floor control server + follows the rules in Section 9 that relate to client authentication + and authorization. If while processing the FloorRelease message, the + floor control server encounters an error, it SHOULD generate an Error + response following the procedures described in Section 13.8. + + The successful processing of a FloorRelease message by a floor + control server involves generating a FloorRequestStatus message, + which SHOULD be generated as soon as possible. + + The floor control server MUST copy the Conference ID, the Transaction + ID, and the User ID from the FloorRelease message into the + FloorRequestStatus message, as described in Section 8.2. + + + + + +Camarillo, et al. Standards Track [Page 53] + +RFC 4582 BFCP November 2006 + + + The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped + attribute to the FloorRequestStatus. The attributes contained in + this grouped attribute carry information about the floor request. + + The FloorRelease message identifies the floor request it applies to + using a FLOOR-REQUEST-ID. The floor control server MUST copy the + contents of the FLOOR-REQUEST-ID attribute from the FloorRelease + message into the Floor Request ID field of the + FLOOR-REQUEST-INFORMATION attribute. + + The floor control server MUST identify the floors being requested + (i.e., the floors associated with the floor request identified by the + FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the + FLOOR-REQUEST-INFORMATION grouped attribute. + + The floor control server MUST add an OVERALL-REQUEST-STATUS attribute + to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request + Status value SHOULD be Released, if the floor (or floors) had been + previously granted, or Cancelled, if the floor (or floors) had not + been previously granted. The floor control server MAY add a STATUS- + INFO attribute with extra information about the floor request. + +13.5. Reception of a FloorQuery Message + + On reception of a FloorQuery message, the floor control server + follows the rules in Section 9 that relate to client authentication. + If while processing the FloorRelease message, the floor control + server encounters an error, it SHOULD generate an Error response + following the procedures described in Section 13.8. + + A floor control server receiving a FloorQuery message from a client + SHOULD keep this client informed about the status of the floors + identified by FLOOR-ID attributes in the FloorQuery message. Floor + Control Servers keep clients informed by using FloorStatus messages. + + An individual FloorStatus message carries information about a single + floor. So, when a FloorQuery message requests information about more + than one floor, the floor control server needs to send separate + FloorStatus messages for different floors. + + The information FloorQuery messages carry may depend on the user + requesting the information. For example, a chair may be able to + receive information about pending requests, while a regular user may + not be authorized to do so. + + + + + + + +Camarillo, et al. Standards Track [Page 54] + +RFC 4582 BFCP November 2006 + + +13.5.1. Generation of the First FloorStatus Message + + The successful processing of a FloorQuery message by a floor control + server involves generating one or several FloorStatus messages, the + first of which SHOULD be generated as soon as possible. + + The floor control server MUST copy the Conference ID, the Transaction + ID, and the User ID from the FloorQuery message into the FloorStatus + message, as described in Section 8.2. + + If the FloorQuery message did not contain any FLOOR-ID attribute, the + floor control server sends the FloorStatus message without adding any + additional attribute and does not send any subsequent FloorStatus + message to the floor participant. + + If the FloorQuery message contained one or more FLOOR-ID attributes, + the floor control server chooses one from among them and adds this + FLOOR-ID attribute to the FloorStatus message. The floor control + server SHOULD add a FLOOR-REQUEST-INFORMATION grouped attribute for + each floor request associated to the floor. Each + FLOOR-REQUEST-INFORMATION grouped attribute contains a number of + attributes that provide information about the floor request. For + each FLOOR-REQUEST-INFORMATION attribute, the floor control server + follows the following steps. + + The floor control server MUST identify the floor request the + FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor + Request ID field of the FLOOR-REQUEST-INFORMATION attribute. + + The floor control server MUST add FLOOR-REQUEST-STATUS attributes to + the FLOOR-REQUEST-INFORMATION grouped attribute identifying the + floors being requested (i.e., the floors associated with the floor + request identified by the FLOOR-REQUEST-ID attribute). + + The floor control server SHOULD add a BENEFICIARY-ID attribute to the + FLOOR-REQUEST-INFORMATION grouped attribute identifying the + beneficiary of the floor request. Additionally, the floor control + server MAY provide the display name and the URI of the beneficiary in + this BENEFICIARY-INFORMATION attribute. + + The floor control server MAY provide information about the requester + of the floor in a REQUESTED-BY-INFORMATION attribute inside the + FLOOR-REQUEST-INFORMATION grouped attribute. + + + + + + + + +Camarillo, et al. Standards Track [Page 55] + +RFC 4582 BFCP November 2006 + + + The floor control server MAY provide the reason why the floor + participant requested the floor in a PARTICIPANT-PROVIDED-INFO. + + The floor control server MAY also add to the FLOOR-REQUEST- + INFORMATION grouped attribute a PRIORITY attribute with the Priority + value requested for the floor request. + + The floor control server MUST add an OVERALL-REQUEST-STATUS attribute + to the FLOOR-REQUEST-INFORMATION grouped attribute with the current + status of the floor request. The floor control server MAY add a + STATUS-INFO attribute with extra information about the floor request. + + The floor control server MAY provide information about the status of + the floor request as it relates to each of the floors being requested + in the FLOOR-REQUEST-STATUS attributes. + +13.5.2. Generation of Subsequent FloorStatus Messages + + If the FloorQuery message carried more than one FLOOR-ID attribute, + the floor control server SHOULD generate a FloorStatus message for + each of them (except for the FLOOR-ID attribute chosen for the first + FloorStatus message) as soon as possible. These FloorStatus messages + are generated following the same rules as those for the first + FloorStatus message (see Section 13.5.1), but their Transaction ID is + 0. + + After generating these messages, the floor control server sends + FloorStatus messages, periodically keeping the client informed about + all the floors for which the client requested information. The + Transaction ID of these messages MUST be 0. + + The rate at which the floor control server sends FloorStatus + messages is a matter of local policy. A floor control server may + choose to send a new FloorStatus message every time a new floor + request arrives, while another may choose to only send a new + FloorStatus message when a new floor request is Granted. + +13.6. Reception of a ChairAction Message + + On reception of a ChairAction message, the floor control server + follows the rules in Section 9 that relate to client authentication + and authorization. If while processing the ChairAction message, the + floor control server encounters an error, it SHOULD generate an Error + response following the procedures described in Section 13.8. + + The successful processing of a ChairAction message by a floor control + server involves generating a ChairActionAck message, which SHOULD be + generated as soon as possible. + + + +Camarillo, et al. Standards Track [Page 56] + +RFC 4582 BFCP November 2006 + + + The floor control server MUST copy the Conference ID, the Transaction + ID, and the User ID from the ChairAction message into the + ChairActionAck message, as described in Section 8.2. + + The floor control server needs to take into consideration the + operation requested in the ChairAction message (e.g., granting a + floor) but does not necessarily need to perform it as requested by + the floor chair. The operation that the floor control server + performs depends on the ChairAction message and on the internal state + of the floor control server. + + For example, a floor chair may send a ChairAction message granting a + floor that was requested as part of an atomic floor request operation + that involved several floors. Even if the chair responsible for one + of the floors instructs the floor control server to grant the floor, + the floor control server will not grant it until the chairs + responsible for the other floors agree to grant them as well. + + So, the floor control server is ultimately responsible for keeping a + coherent floor state using instructions from floor chairs as input to + this state. + + If the new Status in the ChairAction message is Accepted and all the + bits of the Queue Position field are zero, the floor chair is + requesting that the floor control server assign a queue position + (e.g., the last in the queue) to the floor request based on the local + policy of the floor control server. (Of course, such a request only + applies if the floor control server implements a queue.) + +13.7. Reception of a Hello Message + + On reception of a Hello message, the floor control server follows the + rules in Section 9 that relate to client authentication. If while + processing the Hello message, the floor control server encounters an + error, it SHOULD generate an Error response following the procedures + described in Section 13.8. + + The successful processing of a Hello message by a floor control + server involves generating a HelloAck message, which SHOULD be + generated as soon as possible. The floor control server MUST copy + the Conference ID, the Transaction ID, and the User ID from the Hello + into the HelloAck, as described in Section 8.2. + + The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to + the HelloAck message listing all the primitives (i.e., BFCP messages) + supported by the floor control server. + + + + + +Camarillo, et al. Standards Track [Page 57] + +RFC 4582 BFCP November 2006 + + + The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to + the HelloAck message listing all the attributes supported by the + floor control server. + +13.8. Error Message Generation + + Error messages are always sent in response to a previous message from + the client as part of a client-initiated transaction. The ABNF in + Section 5.3.13 describes the attributes that an Error message can + contain. In addition, the ABNF specifies normatively which of these + attributes are mandatory and which ones are optional. + + The floor control server MUST copy the Conference ID, the Transaction + ID, and the User ID from the message from the client into the Error + message, as described in Section 8.2. + + The floor control server MUST add an ERROR-CODE attribute to the + Error message. The ERROR-CODE attribute contains an Error Code from + Table 5. Additionally, the floor control server may add an + ERROR-INFO attribute with extra information about the error. + +14. Security Considerations + + BFCP uses TLS to provide mutual authentication between clients and + servers. TLS also provides replay and integrity protection and + confidentiality. It is RECOMMENDED that TLS with non-null encryption + always be used. BFCP entities MAY use other security mechanisms as + long as they provide similar security properties. + + The remainder of this section analyzes some of the threats against + BFCP and how they are addressed. + + An attacker may attempt to impersonate a client (a floor participant + or a floor chair) in order to generate forged floor requests or to + grant or deny existing floor requests. Client impersonation is + avoided by having servers only accept BFCP messages over + authenticated TLS connections. The floor control server assumes that + attackers cannot highjack the TLS connection and, therefore, that + messages over the TLS connection come from the client that was + initially authenticated. + + An attacker may attempt to impersonate a floor control server. A + successful attacker would be able to make clients think that they + hold a particular floor so that they would try to access a resource + (e.g., sending media) without having legitimate rights to access it. + Floor control server impersonation is avoided by having servers only + accept BFCP messages over authenticated TLS connections. + + + + +Camarillo, et al. Standards Track [Page 58] + +RFC 4582 BFCP November 2006 + + + Attackers may attempt to modify messages exchanged by a client and a + floor control server. The integrity protection provided by TLS + connections prevents this attack. + + An attacker may attempt to fetch a valid message sent by a client to + a floor control server and replay it over a connection between the + attacker and the floor control server. This attack is prevented by + having floor control servers check that messages arriving over a + given authenticated TLS connection use an authorized user ID (i.e., a + user ID that the user that established the authenticated TLS + connection is allowed to use). + + Attackers may attempt to pick messages from the network to get access + to confidential information between the floor control server and a + client (e.g., why a floor request was denied). TLS confidentiality + prevents this attack. Therefore, it is RECOMMENDED that TLS be used + with a non-null encryption algorithm. + +15. IANA Considerations + + The IANA has created a new registry for BFCP parameters called + "Binary Floor Control Protocol (BFCP) Parameters". This new registry + has a number of subregistries, which are described in the following + sections. + +15.1. Attribute Subregistry + + This section establishes the Attribute subregistry under the BFCP + Parameters registry. As per the terminology in RFC 2434 [4], the + registration policy for BFCP attributes shall be "Specification + Required". For the purposes of this subregistry, the BFCP attributes + for which IANA registration is requested MUST be defined by a + standards-track RFC. Such an RFC MUST specify the attribute's type, + name, format, and semantics. + + For each BFCP attribute, the IANA registers its type, its name, and + the reference to the RFC where the attribute is defined. The + following table contains the initial values of this subregistry. + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 59] + +RFC 4582 BFCP November 2006 + + + +------+---------------------------+------------+ + | Type | Attribute | Reference | + +------+---------------------------+------------+ + | 1 | BENEFICIARY-ID | [RFC 4582] | + | 2 | FLOOR-ID | [RFC 4582] | + | 3 | FLOOR-REQUEST-ID | [RFC 4582] | + | 4 | PRIORITY | [RFC 4582] | + | 5 | REQUEST-STATUS | [RFC 4582] | + | 6 | ERROR-CODE | [RFC 4582] | + | 7 | ERROR-INFO | [RFC 4582] | + | 8 | PARTICIPANT-PROVIDED-INFO | [RFC 4582] | + | 9 | STATUS-INFO | [RFC 4582] | + | 10 | SUPPORTED-ATTRIBUTES | [RFC 4582] | + | 11 | SUPPORTED-PRIMITIVES | [RFC 4582] | + | 12 | USER-DISPLAY-NAME | [RFC 4582] | + | 13 | USER-URI | [RFC 4582] | + | 14 | BENEFICIARY-INFORMATION | [RFC 4582] | + | 15 | FLOOR-REQUEST-INFORMATION | [RFC 4582] | + | 16 | REQUESTED-BY-INFORMATION | [RFC 4582] | + | 17 | FLOOR-REQUEST-STATUS | [RFC 4582] | + | 18 | OVERALL-REQUEST-STATUS | [RFC 4582] | + +------+---------------------------+------------+ + + Table 6: Initial values of the BFCP Attribute subregistry + +15.2. Primitive Subregistry + + This section establishes the Primitive subregistry under the BFCP + Parameters registry. As per the terminology in RFC 2434 [4], the + registration policy for BFCP primitives shall be "Specification + Required". For the purposes of this subregistry, the BFCP primitives + for which IANA registration is requested MUST be defined by a + standards-track RFC. Such an RFC MUST specify the primitive's value, + name, format, and semantics. + + For each BFCP primitive, the IANA registers its value, its name, and + the reference to the RFC where the primitive is defined. The + following table contains the initial values of this subregistry. + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 60] + +RFC 4582 BFCP November 2006 + + + +-------+--------------------+------------+ + | Value | Primitive | Reference | + +-------+--------------------+------------+ + | 1 | FloorRequest | [RFC 4582] | + | 2 | FloorRelease | [RFC 4582] | + | 3 | FloorRequestQuery | [RFC 4582] | + | 4 | FloorRequestStatus | [RFC 4582] | + | 5 | UserQuery | [RFC 4582] | + | 6 | UserStatus | [RFC 4582] | + | 7 | FloorQuery | [RFC 4582] | + | 8 | FloorStatus | [RFC 4582] | + | 9 | ChairAction | [RFC 4582] | + | 10 | ChairActionAck | [RFC 4582] | + | 11 | Hello | [RFC 4582] | + | 12 | HelloAck | [RFC 4582] | + | 13 | Error | [RFC 4582] | + +-------+--------------------+------------+ + + Table 7: Initial values of the BFCP primitive subregistry + +15.3. Request Status Subregistry + + This section establishes the Request Status subregistry under the + BFCP Parameters registry. As per the terminology in RFC 2434 [4], + the registration policy for BFCP request status shall be + "Specification Required". For the purposes of this subregistry, the + BFCP request status for which IANA registration is requested MUST be + defined by a standards-track RFC. Such an RFC MUST specify the value + and the semantics of the request status. + + For each BFCP request status, the IANA registers its value, its + meaning, and the reference to the RFC where the request status is + defined. The following table contains the initial values of this + subregistry. + + +-------+-----------+------------+ + | Value | Status | Reference | + +-------+-----------+------------+ + | 1 | Pending | [RFC 4582] | + | 2 | Accepted | [RFC 4582] | + | 3 | Granted | [RFC 4582] | + | 4 | Denied | [RFC 4582] | + | 5 | Cancelled | [RFC 4582] | + | 6 | Released | [RFC 4582] | + | 7 | Revoked | [RFC 4582] | + +-------+-----------+------------+ + + Table 8: Initial values of the Request Status subregistry + + + +Camarillo, et al. Standards Track [Page 61] + +RFC 4582 BFCP November 2006 + + +15.4. Error Code Subregistry + + This section establishes the Error Code subregistry under the BFCP + Parameters registry. As per the terminology in RFC 2434 [4], the + registration policy for BFCP error codes shall be "Specification + Required". For the purposes of this subregistry, the BFCP error + codes for which IANA registration is requested MUST be defined by a + standards-track RFC. Such an RFC MUST specify the value and the + semantics of the error code, and any Error Specific Details that + apply to it. + + For each BFCP primitive, the IANA registers its value, its meaning, + and the reference to the RFC where the primitive is defined. The + following table contains the initial values of this subregistry. + + +-------+-----------------------------------------------+------------+ + | Value | Meaning | Reference | + +-------+-----------------------------------------------+------------+ + | 1 | Conference does not Exist | [RFC 4582] | + | 2 | User does not Exist | [RFC 4582] | + | 3 | Unknown Primitive | [RFC 4582] | + | 4 | Unknown Mandatory Attribute | [RFC 4582] | + | 5 | Unauthorized Operation | [RFC 4582] | + | 6 | Invalid Floor ID | [RFC 4582] | + | 7 | Floor Request ID Does Not Exist | [RFC 4582] | + | 8 | You have Already Reached the Maximum Number | [RFC 4582] | + | | of Ongoing Floor Requests for this Floor | | + | 9 | Use TLS | [RFC 4582] | + +-------+-----------------------------------------------+-----------+ + + Table 9: Initial Values of the Error Code subregistry + +16. Acknowledgements + + The XCON WG chairs, Adam Roach and Alan Johnston, provided useful + ideas for this document. Additionally, Xiaotao Wu, Paul Kyzivat, + Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben + Campbell, Dave Morgan, and Oscar Novo provided useful comments. + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 62] + +RFC 4582 BFCP November 2006 + + +17. References + +17.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.1", RFC 4346, April 2006. + + [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for + Transport Layer Security (TLS)", RFC 3268, June 2002. + + [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD + 63, RFC 3629, November 2003. + + [7] Camarillo, G., "Session Description Protocol (SDP) Format for + Binary Floor Control Protocol (BFCP) Streams", RFC 4583, + November 2006. + +17.2. Informational References + + [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + [9] Koskelainen, P., Ott, J., Schulzrinne, H., and X. Wu, + "Requirements for Floor Control Protocols", RFC 4376, February + 2006. + + [10] Barnes, M. and C. Boulton, "A Framework and Data Model for + Centralized Conferencing", Work in Progress, February 2005. + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 63] + +RFC 4582 BFCP November 2006 + + +Authors' Addresses + + Gonzalo Camarillo + Ericsson + Hirsalantie 11 + Jorvas 02420 + Finland + + EMail: Gonzalo.Camarillo@ericsson.com + + + Joerg Ott + Helsinki University of Technology + Department for Electrical and Communications Engineering + Networking Laboratory + PO Box 3000 + 02015 TKK + Finland + + EMail: jo@netlab.hut.fi + + + Keith Drage + Lucent Technologies + Windmill Hill Business Park + Swindon + Wiltshire SN5 6PP + UK + + EMail: drage@lucent.com + + + + + + + + + + + + + + + + + + + + + +Camarillo, et al. Standards Track [Page 64] + +RFC 4582 BFCP November 2006 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, + AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY + IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR + PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + +Camarillo, et al. Standards Track [Page 65] + |