The IESG has approved the following document: - 'The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)' (draft-ietf-bfcpbis-bfcp-websocket-15.txt) as Proposed Standard
This document is the product of the Binary Floor Control Protocol Bis Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket/ Technical Summary: The WebSocket [RFC6455] protocol enables two-way message exchange between clients and servers on top of a persistent TCP connection, optionally secured with Transport Layer Security (TLS) [RFC5246]. This document specifies a new WebSocket sub-protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. The initial protocol handshake makes use of Hypertext Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure. Working Group Summary: The document was initially presented in DISPATCH where it was decided there was sufficient interest in the problem to extend the BFCPBIS charter and milestones to include it. There were no competing documents and the draft was quickly adopted as a working group document. Within the working group the scope was clarified to include BFCP over TCP only. It was challenging at times to find reviewers for the draft, so it progressed slowly despite there being few technical issues. The most significant discussions were around SDP procedures, including the decision to create another draft [draft-ietf-bfcpbis-sdp-ws-uri] covering the specification of the SDP ws-uri since this URI is not specific to BFCP. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The authors are aware of two server-side implementations and one client-side â none of them is open source. There are also partial client and server implementations that exercise what is covered in this draft. Other companies indicated plans to implement this in their WebRTC gateway. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Charles Eckel <[email protected]> is the document shepherd. Alissa Cooper <[email protected]> is the responsible Area Director. RFC Editor Note In Section 9, please make the following change: OLD: An attacker attempting to impersonate a floor control server is avoided by having servers accept BFCP messages over WSS only. As with any other web connection, the clients will verify the servers certificate. [â¦] NEW: An attacker can attempt to impersonate a floor control server. Floor control server impersonation is avoided by having WSS between client and server. As with any other web connection, the clients will verify the servers certificate. [â¦]
