XCON Working Group G. Camarillo Internet-Draft Ericsson Expires: September 30, 2004 J. Ott Universitaet Bremen K. Drage Lucent Technologies April 2004 The Binary Floor Control Protocol (BFCP) draft-camarillo-xcon-bfcp-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specicies the Binary Floor Control Protocol (BFCP). BFCP is used between conference participants and floor control servers, and between floor chairs and floor control servers. Camarillo, et al. Expires September 30, 2004 [Page 1] Internet-Draft BFCP April 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Operation . . . . . . . . . . . . . . . . . . . 5 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 FIXED-HEADER Format . . . . . . . . . . . . . . . . . . . 5 4.2 Attribute Format . . . . . . . . . . . . . . . . . . . . . 6 4.2.1 FLOOR-ID . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2 USER-ID . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.3 REQUEST-ID . . . . . . . . . . . . . . . . . . . . . . 7 4.2.4 HUMAN-READABLE-INFO . . . . . . . . . . . . . . . . . 7 4.2.5 TOKEN . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.6 REQUEST-STATUS . . . . . . . . . . . . . . . . . . . . 8 4.2.7 ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . 9 4.2.8 USER-DISPLAY-NAME . . . . . . . . . . . . . . . . . . 11 4.2.9 USER-URI . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.10 PRIORITY . . . . . . . . . . . . . . . . . . . . . . 11 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 FloorRequest . . . . . . . . . . . . . . . . . . . . . . . 11 5.2 FloorRelease . . . . . . . . . . . . . . . . . . . . . . . 12 5.3 FloorRequestStatus . . . . . . . . . . . . . . . . . . . . 12 5.4 FloorStatus . . . . . . . . . . . . . . . . . . . . . . . 12 5.5 ChairAction . . . . . . . . . . . . . . . . . . . . . . . 13 5.6 Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.7 PingAck . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.8 Error . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. bfcp and bfcps URI Definitions . . . . . . . . . . . . . . . 14 7. Contacting a bfcp or bfcps URI . . . . . . . . . . . . . . . 15 7.1 Selecting a Transport Protocol . . . . . . . . . . . . . . 15 7.2 Determining Port and IP Address . . . . . . . . . . . . . 16 7.3 Lower-Layer Security . . . . . . . . . . . . . . . . . . . 17 7.4 Conference ID, User ID, and Token Values . . . . . . . . . 17 8. Client Operations . . . . . . . . . . . . . . . . . . . . . 18 8.1 Requesting a Floor . . . . . . . . . . . . . . . . . . . . 18 8.1.1 Receiving Responses . . . . . . . . . . . . . . . . . 19 8.2 Cancelling a Floor Request . . . . . . . . . . . . . . . . 19 8.2.1 Receiving Responses . . . . . . . . . . . . . . . . . 20 8.3 Releasing Floors . . . . . . . . . . . . . . . . . . . . . 20 8.3.1 Receiving Responses . . . . . . . . . . . . . . . . . 21 8.4 Checking the Liveness of a Server . . . . . . . . . . . . 21 8.4.1 Receiving Responses . . . . . . . . . . . . . . . . . 21 8.5 Responding to a Ping Message . . . . . . . . . . . . . . . 22 9. Chair Operations . . . . . . . . . . . . . . . . . . . . . . 22 9.1 Obtaining Information about Floor Requests . . . . . . . . 22 9.2 Instructing the Floor Control Server . . . . . . . . . . . 22 10. Server Operations . . . . . . . . . . . . . . . . . . . . . 23 10.1 Reception of a FloorRequest Message . . . . . . . . . . 23 Camarillo, et al. Expires September 30, 2004 [Page 2] Internet-Draft BFCP April 2004 10.2 Checking the Liveness of a Client or Chair . . . . . . . 24 10.2.1 Receiving a PingAck Message . . . . . . . . . . . . 25 10.3 Responding to a Ping Message . . . . . . . . . . . . . . 25 10.4 Informing about the Status of a Floor . . . . . . . . . 25 10.5 Receiving a ChairAction Message . . . . . . . . . . . . 25 10.6 Error Message Generation . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26 12.1 bfcp and bfcps URI Schemes Registration . . . . . . . . 26 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14.1 Normative References . . . . . . . . . . . . . . . . . . . 27 14.2 Informational References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . 30 Camarillo, et al. Expires September 30, 2004 [Page 3] Internet-Draft BFCP April 2004 1. Introduction Conference applications may need to manage the access to a set of shared resources such as the right to send media over a particular media stream. Floor control enables such applications to provide users with safe access to these resources. The Requirements for Floor Control Protocol [11] 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. BFCP provides a means for a floor control server to grant or deny requests to access a given resource from users. Nevertheless, BFCP does not allow floor control servers to keep a particular user or set of users from actually accessing the resource. Enforcing policy decisions is outside the scope of BFCP. In any case, one possible way to implement policy enforcement is to have the floor control server provide the conference policy server (e.g., using CPCP [12]) with policies that the conference policy server will apply to the conference. Floor control servers identify users using a 32-bit user ID. The way a conference server provides a user with its 32-bit user ID is out of the scope of this document. BFCP assumes that conference servers, after authenticating a user, provides this user with a token, in addition to the user's user ID. The user's client needs to include this token in its requests to prove that they belong to the same user as the conference server authenticated previously. The way a conference server provides a user with such a token in a secure fashion falls outside the scope of this document. Section 2 defines the terminology used throughout this document, Section 3 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. Floor: A permission to temporarily access or manipulate a specific shared resource or set of resources. Camarillo, et al. Expires September 30, 2004 [Page 4] Internet-Draft BFCP April 2004 Floor chair: A user (or an entity) who manages one floor (grants, denies, or revokes a floor). The floor chair does not have to be a member in a conference. 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. 3. Overview of Operation TBD: the Introduction and this section need more work. 4. Packet Format BFCP packets consist of an 8-byte fixed header followed by attributes. All the protocol values MUST be sent in network byte order. 4.1 FIXED-HEADER Format The following is the FIXED-HEADER format. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Camarillo, et al. Expires September 30, 2004 [Page 5] Internet-Draft BFCP April 2004 _________________________________________________________ 0 FloorRequest C -> S 1 FloorRelease C -> S 2 FloorRequestStatus S -> C 3 FloorStatus S -> C ; S -> Ch 4 ChairAction Ch -> S 5 Ping C <-> S ; Ch <-> S 6 PingAck C <-> S ; Ch <-> S 7 Error S -> C ; S -> Ch S: Server C: Client Ch: Chair Payload Length: this 16-bit field contains length of the message in 4-byte units excluding the fixed header. Conference ID: this 32-bit identifies the conference the message belongs to. 4.2 Attribute Format BFCP attributes are encoded in TLV (Type-Length-Value) format. TLVs 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 / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: this 7-bit field contains the code for the attribute. 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. Length: this 8-bit field contains the length of the attribute in bytes, excluding any padding defined for specific attributes. The Type, 'M' bit, and Length fields are included. Attribute Contents: the contents of the different TLVs are defined in the following sections. Camarillo, et al. Expires September 30, 2004 [Page 6] Internet-Draft BFCP April 2004 4.2.1 FLOOR-ID The following is the format of the contents of the FLOOR-ID attribute, whose attribute type is 1. 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 = 1 |M| Length | Floor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Floor ID: this field contains a 16-bit value that uniquely identifies a floor within a conference. 4.2.2 USER-ID The following is the format of the contents of the USER-ID attribute, whose attribute type is 2. 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 = 2 |M| Length | User ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ User ID: this field contains a 16-bit value that uniquely identifies a user within a conference. 4.2.3 REQUEST-ID The following is the format of the contents of the REQUEST-ID attribute, whose attribute type is 3. 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 = 3 |M| Length | Request ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request ID: this field contains a 16-bit value that allows users to match a given message with its responses. 4.2.4 HUMAN-READABLE-INFO The following is the format of the contents of the Camarillo, et al. Expires September 30, 2004 [Page 7] Internet-Draft BFCP April 2004 HUMAN-READABLE-INFO attribute, whose attribute type is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 |M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Text: this field contains UTF-8 [10] encoded text. In some situations, the contents of the Text field may be generated by an automata. If such automata has information about the preferred language of the receiver of a particular HUMAN-READABLE-INFO TLV, it may use this language to generate the Text field. Padding: one, two, or three bytes of padding added so that the contents of the HUMAN-READABLE-INFO TLV is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. If the TLV is already 32-bit aligned, no padding is needed. 4.2.5 TOKEN The following is the format of the contents of the TOKEN attribute, whose attribute type is 5. 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 = 5 |M| Length | Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Token: this field contains a 16-bit token used to authenticate the user. 4.2.6 REQUEST-STATUS The following is the format of the contents of the REQUEST-STATUS attribute, whose attribute type is 6. Camarillo, et al. Expires September 30, 2004 [Page 8] Internet-Draft BFCP April 2004 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 = 6 |M| Length | Request Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Position | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request Status: this 16-bit field contains the status of the request, as described in the following table. Value Status ______________________________ 0 Pending 1 Accepted 2 Granted 3 Denied 4 Cancelled 5 Released 6 Revoked Queue Position: this 16-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, the floor control server does not implement a floor request queue, or 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. Padding: two bytes of padding added so that the contents of the REQUEST-STATUS TLV is 32-bit aligned. The Padding bits SHOULD be set to zero by the sender and MUST be ignored by the receiver. 4.2.7 ERROR-CODE The following is the format of the contents of the ERROR-CODE attribute, whose attribute type is 7. 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 = 7 |M| Length | Error Code | Camarillo, et al. Expires September 30, 2004 [Page 9] Internet-Draft BFCP April 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Error Specific Details | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code: this 16-bit field contains an error code from the following table. Value Meaning ______________________________ 0 Conference does not Exist 1 Authentication Failed 2 Unknown Mandatory TLV 3 Floor Request does not Exist 4 Unauthorized Operation 5 User does not Exist 6 Invalid Request-ID Error Specific Details: Present only for certain Error Codes. In this document, only for Error Code 2 (Unknown Mandatory TLV). For Error Code 2, this field contains the Types of the TLVs (which were present in the message that triggered the Error message) that were unknown to the receiver, encoded as follows. 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 TLV Type | Unknown TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Unknown TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unknown TLV Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Padding: one, two, or three bytes of padding added so that the contents of the ERROR-CODE TLV is 32-bit aligned. If the TLV 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. Note all the Error Codes defined in this document but Error Code 2, result in a TLV which is already 32-bit Camarillo, et al. Expires September 30, 2004 [Page 10] Internet-Draft BFCP April 2004 aligned (i.e., no need of padding). Error Code 2 results in a TLV that may need 2 bytes of padding. 4.2.8 USER-DISPLAY-NAME The USER-DISPLAY-NAME attribute type is 8 and its format is the same as the HUMAN-READABLE-INFO attribute. The Text field in the USER-DISPLAY-NAME attribute contains the name of the user. 4.2.9 USER-URI The USER-URI attribute type is 9 and its format is the same as the HUMAN-READABLE-INFO attribute. The Text field in the USER-URI attribute contains the URI of the user. 4.2.10 PRIORITY The following is the format of the contents of the PRIORITY attribute, whose attribute type is 10. 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 = 7 |M| Length | Priority | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Priority: the higher the 8-bit value, the more priority is requested for a given floor request. Reserved: at this point, the 8 bits in the reserved field SHOULD be set to zero by the sender of the message and MUST be ignored by the receiver. 5. Message Format This section contains the ABNF [2] of the BFCP messages. 5.1 FloorRequest Clients request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message: FloorRequest = (FIXED-HEADER) (REQUEST-ID) 1*(FLOOR-ID) Camarillo, et al. Expires September 30, 2004 [Page 11] Internet-Draft BFCP April 2004 (USER-ID) (TOKEN) [PRIORITY] [USER-DISPLAY-NAME] [USER-URI] [HUMAN-READABLE-INFO] 5.2 FloorRelease Clients release a floor by sending a FloorRelease message to the floor control server. Clients also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message: FloorRelease = (FIXED-HEADER) (REQUEST-ID) 1*(FLOOR-ID) (USER-ID) (TOKEN) 5.3 FloorRequestStatus The floor control server informs clients about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRelease message: FloorRequestStatus = (FIXED-HEADER) (REQUEST-ID) 1*(FLOOR-ID) (USER-ID) (REQUEST-STATUS) 5.4 FloorStatus The floor control server informs clients about the holder of a floor by sending them FloorStatus messages. The following is the format of the FloorStatus message: FloorStatus = (FIXED-HEADER) (FLOOR-ID) *( (REQUEST-ID) (USER-ID) Camarillo, et al. Expires September 30, 2004 [Page 12] Internet-Draft BFCP April 2004 [PRIORITY] [USER-DISPLAY-NAME] [USER-URI] [HUMAN-READABLE-INFO] (REQUEST-STATUS) ) 5.5 ChairAction Chairs send instructions to floor control servers by sending ChairAction messages. The following is the format of the ChairAction message: ChairAction = (FIXED-HEADER) (REQUEST-ID) (USER-ID) (TOKEN) (FLOOR-ID) (REQUEST-ID) (USER-ID) (REQUEST-STATUS) [HUMAN-READABLE-INFO] 5.6 Ping Clients check the liveness of servers, and servers of clients, by sending a Ping message. The following is the format of the Ping message: Ping = (FIXED-HEADER) (REQUEST-ID) (USER-ID) (TOKEN) 5.7 PingAck Clients and servers confirm that they are alive on reception of a Ping message by sending a PingAck message. The following is the format of the PingAck message: PingAck = (FIXED-HEADER) (REQUEST-ID) (USER-ID) Camarillo, et al. Expires September 30, 2004 [Page 13] Internet-Draft BFCP April 2004 [TOKEN] 5.8 Error The floor control server informs clients about errors processing requests by sending them Error messages. The following is the format of the Error message: Error = (FIXED-HEADER) (REQUEST-ID) (USER-ID) (ERROR-CODE) (HUMAN-READABLE-INFO) 6. bfcp and bfcps URI Definitions The following is the ABNF [2] for the "bfcp" and "bfcps" URIs: bfcpURI = "bfcp://" server "/" conf-id [ uri-parameters ] bfcpsURI = "bfcps://" server "/" conf-id [ uri-parameters ] server = [ user "@" ] hostport user = user-id [ ":" token ] user-id = 1*DIGIT token = 1*DIGIT conf-id = 1*DIGIT uri-parameters = *( "?" uri-parameter) uri-parameter = transport-param / other-param transport-param = "transport=" ( "tcp" / other-transport ) other-transport = pvalue other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" unreserved = alphanum / mark alphanum = ALPHA / DIGIT mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" escaped = "%" HEXDIG HEXDIG Camarillo, et al. Expires September 30, 2004 [Page 14] Internet-Draft BFCP April 2004 We import several definitions from RFC 2396 [4] and RFC 2732 [6], but we make them complatible with RFC 2234 [2]: hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6reference = "[" IPv6address "]" IPv6address = hexpart [ ":" IPv4address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG port = 1*DIGIT The following are examples of bfcp and bfcps URIs: bfcp://1234:472@server34.example.com/4321 bfcp://5678:243@server45.example.com:20000/9876?transport=tcp bfcps://server57.example.com/5643 7. Contacting a bfcp or bfcps URI A client contacting a bfcp or bfcps follows the rules described in the following sections. 7.1 Selecting a Transport Protocol XXX: Once we resolve Issue 3 in the tracker, we will edit this section. If the URI specifies a transport protocol in the transport parameter, that transport protocol SHOULD be used. Otherwise, if no transport protocol is specified, but the host part of the URI is a numeric IP address, the client SHOULD use TCP. Similarly, if no transport protocol is specified, the host part is not numeric, but an explicit port is provided, the client SHOULD use TCP. Otherwise, if no transport protocol or port is specified, and the Camarillo, et al. Expires September 30, 2004 [Page 15] Internet-Draft BFCP April 2004 host part of the URI is not a numeric IP address, the client SHOULD perform a NAPTR [9] query for the domain in the URI. The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "BFCP+D2X" and "BFCPS+D2X", where X is a letter that corresponds to a transport protocol supported by the domain. This specification defines D2T for TCP. These NAPTR records provide a mapping from a domain to the SRV [7] record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record will contain an empty regular expression and a replacement value, which is the SRV record for that particular transport protocol. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value. A client resolving a BFCPS URI MUST discard any services that do not contain "BFCPS" as the protocol in the service field. On the other hand, a client resolving a BFCP URI SHOULD retain records with "BFCPS" as the protocol, if the client supports TLS. The client MUST discard any service fields that identify a resolution service whose value is not "D2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 3403 [9] will result in the discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier "_bfcp" for bfcp URIs and "_bfcps" for bfcps URIs. If the client supports TLS and wishes to use it, it SHOULD also query using the service identifier "_bfcps", even when handling floor URIs. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires which is supported by the server. If no SRV records are found, the client SHOULD use TCP to contact the server. 7.2 Determining Port and IP Address Once the transport protocol has been determined, the next step is to determine the IP address and port. If the host part of the URI is a numeric IP address, the client uses that address. If the URI also contains a port, the client uses that port. If no port is specified, the client uses the default port for the particular transport protocol. Camarillo, et al. Expires September 30, 2004 [Page 16] Internet-Draft BFCP April 2004 If the host part of the URI was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously. The client SHOULD try the first record. If an attempt should fail, the next SHOULD be tried, and if that should fail, the next SHOULD be tried, and so on. If the host part of the URI was not a numeric IP address, and no port was present in the URI, the client performs an SRV query on the record returned from the NAPTR processing of Section 7.1, if such processing was performed. If it was not, because a transport was specified explicitly, the client performs an SRV query for that specific transport, using the service identifiers as described in Section 7.1. If the NAPTR processing was not done because no NAPTR records were found, but an SRV query for a supported transport protocol was successful, those SRV records are selected. Regardless of how the SRV records were determined, the procedures of RFC 2782 [7], as described in the section titled "Usage rules" are followed. If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously, at the default port for that transport. 7.3 Lower-Layer Security SFTP relies on lower-layer security mechanisms to provide integrity and replay protection, and confidentiality. SFTP servers MUST support TLS [3], and clients SHOULD support TLS. Clients and servers MAY support other security mechanisms. Servers and clients that implement TLS MUST support XXX: cypher and hash algorithm. If a client is contacting a BFCPS URI, the client MUST use TLS towards the server. If a client is contacting a BFCP URI, and the client wishes to use TLS, the client MAY use TLS towards the server. If the client is contacting a BFCP URI, and the client does not wish to use or does not support TLS, it SHOULD use a different security mechanism which SHOULD provide integrity and replay protection, and confidentiality. 7.4 Conference ID, User ID, and Token Values Once the client has determined the transport protocol to use, the IP address and port number of the server, and the security mechanism to use, the client SHOULD establish the transport and security Camarillo, et al. Expires September 30, 2004 [Page 17] Internet-Draft BFCP April 2004 connections needed to contact the server. At this point, the client is ready to send BFCP messages to the server. In order to do this, the client needs to fill a set of fields. In particular, the client needs to fill the Conference ID field in the FIXED-HEADER, and the User ID and Token fields in their respective TLVs. The conf-id of the BFCP or BFCPS URI contains the integer representation of the 32-bit Conference ID to be used in the FIXED-HEADER. If the conf-id contains an integer too large to be represented using 32 bits, the client MUST only use the least significant 32 bits of its representation. The values to be used in the USER-ID and TOKEN parameters may be obtained from the URI. If the URI does not contain these values, they are obtained by the client using a mechanism which is outside the scope of this document. Examples of such a mechanism are using the Conference Event Package [13] and using the SIP [8] Call-Info header field. 8. Client Operations This section specifies how clients can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. Chair operations, such as instructing the floor server to grant or revoke a floor, are described in Section 9. 8.1 Requesting a Floor A client that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server. The ABNF in Section 5.1 describes the TLVs that a FloorRequest message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. The client MUST set the Conference ID in the FIXED-HEADER of the FloorRequest to the Conference ID for the conference that the client obtained previously. The client MUST set the Request ID value in the REQUEST-ID TLV to a random number. The Request ID value is used by the client to match this floor request with the responses received from the floor control server. The Request ID value is also used by the server to match this floor request with eventual FloorRelease messages from the client cancelling the floor request. The client MUST NOT reuse the same Request ID value for new messages different than FloorRelease until the floor request is granted or denied or an Error message for this Camarillo, et al. Expires September 30, 2004 [Page 18] Internet-Draft BFCP April 2004 FloorRequest is received. If the client inserts more than one FLOOR-ID TLVs in the FloorRequest message, the 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 USER-ID and the TOKEN TLVs in the FloorRequest message are used by the server to authenticate and authorize the request. The USER-DISPLAY-NAME and the USER-URI TLVs in the FloorRequest message, if present, provide extra information about the user requesting the floor. The client can request the server to handle the floor request with a certain priority using a PRIORITY TLV. The client MAY use a HUMAN-READABLE-INFO TLV to state the reason why the floor or floors are being requested. The Text in the HUMAN-READABLE-INFO TLV is intended for human consumption. 8.1.1 Receiving Responses A message from the server is considered a response to the FloorRequest message by the client if the message from the server has the same Conference ID, Request ID, and User ID as the FloorRequest message. If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest in a REQUEST-STATUS TLV. If the Request Status value is Granted, the client has been granted all the floors that were requested in the FloorRequest message. If the Request Status value is Denied, the client has been denied all the floors that were requested in the FloorRequest message. The HUMAN-READABLE-INFO TLV, if present, provides extra information which the client MAY display to the user. If the response is an Error message, the server could not process the FloorRequest message for some reason, which is described in the Error message. 8.2 Cancelling a Floor Request A client that wishes to cancel a pending floor request does so by sending a FloorRelease message to the floor control server. The ABNF in Section 5.2 describes the TLVs that a FloorRelease message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. Camarillo, et al. Expires September 30, 2004 [Page 19] Internet-Draft BFCP April 2004 The client MUST set the Conference ID in the FIXED-HEADER of the FloorRelease to the Conference ID for the conference that the client obtained previously. Note that the FloorRelease message is also used to release a floor or floors that were granted to the client. Using the same message for both situations helps resolve the race condition that occurs when the FloorRelease message and the FloorGrant message cross each other on the wire. The client MUST copy the REQUEST-ID, FLOOR-ID, USER-ID, and TOKEN TLVs from the FloorRequest message that the FloorRelease message is cancelling into the FloorRelease message. 8.2.1 Receiving Responses A message from the server is considered a response to the FloorRelease message by the client if the message from the server has the same Conference ID, Request ID, and User ID as the FloorRelease message. If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest in a REQUEST-STATUS TLV. If the Request Status value is different from Cancelled, the FloorRelease message and the FloorRequestStatus crossed on the wire. The client does not need to resend the FloorRelease message, because the server will send a new FloorRequestStatus message with a Request Status value of Cancelled as soon as it receives the original FloorRelease message. The HUMAN-READABLE-INFO TLV, if present, provides extra information which the client MAY display to the user. If the response is an Error message, the server could not process the FloorRelease message for some reason, which is described in the Error message. 8.3 Releasing Floors A client that wishes to release one or more floors, which were granted to it before, does so by sending a FloorRelease message. The ABNF in Section 5.2 describes the TLVs that a FloorRelease message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. The client MUST set the Conference ID in the FIXED-HEADER of the FloorRelease to the Conference ID for the conference that the client obtained previously. The client MUST copy the REQUEST-ID, FLOOR-ID, USER-ID, and TOKEN Camarillo, et al. Expires September 30, 2004 [Page 20] Internet-Draft BFCP April 2004 TLVs from the FloorRequest message that resulted in the floor being granted into the FloorRelease message. 8.3.1 Receiving Responses A message from the server is considered a response to the FloorRelease message by the client if the message from the server has the same Conference ID, Request ID, and User ID as the FloorRelease message. If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest in a REQUEST-STATUS TLV. The server will send a FloorRequestStatus with a Request Status value of Released as soon as it receives the FloorRelease message. The HUMAN-READABLE-INFO TLV, if present, provides extra information which the client MAY display to the user. If the response is an Error message, the server could not process the FloorRelease message for some reason, which is described in the Error message. 8.4 Checking the Liveness of a Server A client that wishes to check the liveness of a server does so by sending a Ping message to the floor control server. The ABNF in Section 5.6 describes the TLVs that a Ping message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. The client MUST set the Conference ID in the FIXED-HEADER of the Ping to the Conference ID for the conference that the client obtained previously. The client MUST set the Request ID value of the REQUEST-ID TLV to a random number. The Request ID value is used by the client to match this ping request with the response received from the floor control server. The client MUST NOT reuse the same Request ID value for new messages until the client receives a PingAck or an Error message for this request. The server uses the values of the USER-ID and TOKEN TLVs in the Ping message to authenticate and authorize the message. 8.4.1 Receiving Responses A message from the server is considered a response to the Ping message by the client if the message from the server has the same Conference ID, Request ID, and User ID as the Ping message. Camarillo, et al. Expires September 30, 2004 [Page 21] Internet-Draft BFCP April 2004 If the response is a PingAck message, the server is alive and the User ID and Token values sent by the client were acceptable. If the response is an Error message, the server could not process the Ping message for some reason, which is described in the Error message. 8.5 Responding to a Ping Message The processing of a Ping message by a client involves generating a PingAck message. The PingAck message is constructed by copying the Conference ID, Request ID, and User ID values from the Ping message into the PingAck message. The PingAck message MUST also contain a TOKEN TLV. 9. Chair Operations This section specifies how clients acting as chairs can perform different operations, such as instructing the floor server to grant or revoke a floor, using the protocol elements described in earlier sections. 9.1 Obtaining Information about Floor Requests A chair can obtain information about the floor requests that the floor control server receives in different ways, which include using out-of-band mechanisms. Chairs using BFCP to obtain such information receive it in FloorStatus messages from the floor control server. 9.2 Instructing the Floor Control Server Chairs that wish to send instructions to a floor control server does so by sending a ChairAction message. The ABNF in Section 5.5 describes the TLVs that a ChairAction message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. The client MUST set the Conference ID in the FIXED-HEADER of the ChairAction to the Conference ID for the conference that the client obtained previously. The client MUST set the Request ID value of the REQUEST-ID TLV to a random number. The Request ID value is used by the chair to match this ChairAction message with the responses received from the floor control server. The chair MUST NOT reuse the same Request ID value for new messages until the floor server has performed the instructions sent in the ChairAction message or until an Error response is received. Camarillo, et al. Expires September 30, 2004 [Page 22] Internet-Draft BFCP April 2004 The server uses the values of the USER-ID and TOKEN TLVs to authenticate and authorize the request. The chair MUST identify the floor the instructions in the message apply to using a FLOOR-ID TLV. Additionally, the chair MUST identify the floor request the instructions in the message apply to using a REQUEST-ID and a USER-ID TLVs. The chair MUST provide the new status of the floor request using a REQUEST-STATUS TLV. If the new status of the floor request is Accepted, the chair MAY use the Queue Position field to provide a queue position for the floor request. If the chair does not wish to provide a queue position, all the bits of the Queue Position field SHOULD be set to zero. The chair SHOULD use the Status Revoked to revoke a floor that was granted (i.e., Granted status) and to reject floor requests in any other status (e.g., Pending and Accepted). The chair MAY use a HUMAN-READABLE-INFO TLV to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the HUMAN-READABLE-INFO TLV is intended for human consumption. 10. Server Operations This section specifies how servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections. Section 10.6 On reception of a message from a client, the floor control server MUST check whether or not the values of the Conference ID, User ID, and Token identify a valid user. If they do not, the floor server SHOULD send an Error message, as described in Section 10.6, with Error code 1 (Authentication Failed). On reception of a message from a client, the floor control server MUST check whether or not it understands all the mandatory ( 'M' bit set) TLVs in the message. If the server does not understand all of them, the floor server SHOULD send an Error message, as described in Section 10.6, with Error code 2 (Authentication Failed). The Error message SHOULD list the TLVs that were not understood. 10.1 Reception of a FloorRequest Message The processing of a FloorRequest message by a server involves generating one or more FloorRequestStatus messages. The floor control server SHOULD generate a FloorRequestStatus message as soon as possible. If the floor server cannot accept, grant or deny the floor request right away, it SHOULD use a Request Status value of Pending. Camarillo, et al. Expires September 30, 2004 [Page 23] Internet-Draft BFCP April 2004 At any time, when the status of the floor request changes, the floor control server SHOULD send a FloorRequest message with the appropriate Request Status. On reception of a FloorRelease message, the server SHOULD send a FloorRequestStatus message with a Request Status value of Released, if the floor had been previously granted, or of Cancelled, if it had not. The server constructs the FloorRequestStatus messages by copying the Conference ID, Request ID, and User ID values from the FloorRequest message into the response message. The server MAY add a HUMAN-READABLE-INFO TLV to provide extra information to the user about its decision. The floor control server MAY use the PRIORITY TLV, if present in the FloorRequest, to give higher or lower priority to the floor request. 10.2 Checking the Liveness of a Client or Chair A server that wishes to check the liveness of a client does so by sending a Ping message to the client or chair. Such a Ping message makes the client return a PingAck message, which contains the client's or chair's User ID and Token. So, the server can use Ping messages to re-authenticate the client (e.g., a new token is sent to the client or chair out-of-band and the Ping message makes the client show the server that the client or chair received it). The ABNF in Section 5.6 describes the TLVs that a Ping message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. The server MUST set the Conference ID in the FIXED-HEADER of the Ping to the Conference ID for the conference that the client or chair is part of. The server MUST set the Request ID valie of the REQUEST-ID TLV to a random number. The Request ID value is used by the server to match this ping request with the response received from the client or chair. The server MUST NOT reuse the same Request ID value for new messages until the server receives a PingAck message for this request. The server MUST set the User ID value of the USER-ID TLV to the User ID of the destination client or chair. Camarillo, et al. Expires September 30, 2004 [Page 24] Internet-Draft BFCP April 2004 10.2.1 Receiving a PingAck Message A PingAck message from the client is considered a response to the Ping message by the server if the PingAck message has the same Conference ID, Request ID, and User ID as the Ping message. The PingAck message sent by the client in response to the Ping message sent by the server will contain the client's User ID and Token. The server authenticates this message as any other message, which may involve returning an Error message if the authentication is not succesful. 10.3 Responding to a Ping Message The processing of a Ping message by a server involves generating a PingAck message. The PingAck message is constructed by copying the Conference ID, Request ID, and User ID values from the Ping message into the PingAck message. 10.4 Informing about the Status of a Floor Floor control servers send information to clients and chairs about the status of a floor by sending FloorStatus messages. The server MUST set the Conference ID in the FIXED-HEADER of the FloorStatus to the Conference ID for the conference that the client or chair is part of. The chair MUST identify the floor the FloorStatus message applies to using a FLOOR-ID TLV. The server MAY provide information about a number of floor requests in a single FloorStatus message. For each floor request, the server MUST include in the FloorStatus the request's REQUEST-ID, USER-ID, and REQUEST-STATUS, and MAY include its USER-DISPLAY-NAME, USER-URI, HUMAN-READABLE-INFO, and requested PRIORITY. 10.5 Receiving a ChairAction Message On reception of a ChairAction message, the floor control server checks whether the chair that send the message is authorized to perform the operation being requested. If the chair is authorized, the floor control server performs the operation. If the new Status is Accepted and all the bits of the Queue Position field are zero, the server assigns a queue position (e.g., the last in the queue) to the floor request based on local policy (in case the server implements a queue). Camarillo, et al. Expires September 30, 2004 [Page 25] Internet-Draft BFCP April 2004 If the floor control server cannot find a floor request that matches the request the operation in the ChairAction message applies to, the floor control server generates an Error message, as described in Section 10.6, with an Error code with a value of 3 (Floor Request does not Exist). If the chair is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in Section 10.6, with an Error code with a value of 4 (Unauthorized Operation). 10.6 Error Message Generation Error messages are always sent in response to a previous message from the client. Servers construct Error messages by copying the Conference ID, Request ID, and User ID values from the client's message into the Error message. The ABNF in Section 5.8 describes the TLVs that a Error message can contain. In addition, the ABNF specifies which of these TLVs are mandatory, and which ones are optional. 11. Security Considerations TBD. 12. IANA Considerations TBD 12.1 bfcp and bfcps URI Schemes Registration This section registers the bfcp and bfcps URI schemes following the template given in RFC 2717 [5]. URI scheme names: "bfcp" and "bfcps" URI scheme syntax: specified in Section 6 of RFC XXXX (substitute XXXX with the number of this RFC). Character encoding considerations: The "bfcp" and "bfcps" URIs support the UTF-8 encoding scheme. Intended use: common within floor control protocols. Applications and/or protocols which use these URI scheme: BFCP, which is specified in this document. Camarillo, et al. Expires September 30, 2004 [Page 26] Internet-Draft BFCP April 2004 Interoperability considerations: none known. Security considerations: the "bfcps" URI scheme indicates a requirement to use TLS to contact the floor control server. Relevant publications: RFC XXXX (substitute XXXX with the number of this RFC). Contact information: the IETF XCON Working group. In case the WG does no exist anymore, any person appointed by the IETF Transport Area Director(s). Registered-by: Gonzalo Camarillo Change control: extensions, new parameters and new values to these URIs have to be documented in an RFC. The IETF XCON Working Group or, in case the WG does no exist anymore, any person appointed by the IETF Transport Area Director(s), will provide expert review and advise to the change control process. 13. Acknowledgments The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas for this document. 14. References 14.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. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [5] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999. [6] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. Camarillo, et al. Expires September 30, 2004 [Page 27] Internet-Draft BFCP April 2004 [7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [9] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 14.2 Informational References [11] Schulzrinne, H., "Requirements for Floor Control Protocol", draft-ietf-xcon-floor-control-req-00 (work in progress), January 2004. [12] Koskelainen, P. and H. Khartabil, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Conference Policy Manipulation", draft-koskelainen-xcon-xcap-cpcp-usage-02 (work in progress), February 2004. [13] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-03 (work in progress), February 2004. Authors' Addresses Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Camarillo, et al. Expires September 30, 2004 [Page 28] Internet-Draft BFCP April 2004 Joerg Ott Universitaet Bremen MZH 5180 Bibliothekstr. 1 Bremen D-28359 Germany EMail: jo@tzi.org Keith Drage Lucent Technologies Windmill Hill Business Park Swindon Wiltshire SN5 6PP UK EMail: drage@lucent.com Camarillo, et al. Expires September 30, 2004 [Page 29] Internet-Draft BFCP April 2004 Intellectual Property Statement 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 IETF's procedures with respect to rights in IETF 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Camarillo, et al. Expires September 30, 2004 [Page 30]