<?xmlversion="1.0" encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. --> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --> <!-- Normative References --> <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!-- MUST, SHOULD, MAY --> <!ENTITY RFC7235 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7235.xml"> <!-- HTTP Over TLS --> <!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml"> <!-- SIP --> <!ENTITY RFC3263 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3263.xml"> <!-- Locating SIP Servers --> <!ENTITY RFC3403 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3403.xml"> <!-- NAPTR --> <!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml"> <!-- ABNF --> <!ENTITY RFC6455 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml"> <!-- WebSocket --> <!ENTITY RFC7525 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7525.xml"> <!-- Recommendations for TLS --> <!ENTITY RFC5018 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5018.xml"> <!-- TCP --> <!ENTITY RFC4582 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4582.xml"> <!-- BFCP --> <!ENTITY RFC4583 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4583.xml"> <!-- BFCP SDP --> <!ENTITY BFCPbis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfcpbis-rfc4582bis.xml"> <!-- rfc4582bis --> <!ENTITY SDPBFCPbis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-bfcpbis-rfc4583bis.xml"> <!-- rfc4583bis --> <!-- Informative References --> <!ENTITY RFC2606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2606.xml"> <!-- Reserved Top Level DNS Names --> <!ENTITY RFC7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml"> <!ENTITY RFC7616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7616.xml"> <!ENTITY RFC7617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7617.xml"> <!ENTITY RFC7486 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7486.xml"> <!-- HTTP --> <!ENTITY RFC3327 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3327.xml"> <!-- Path --> <!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"> <!-- URI --> <!ENTITY RFC4168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4168.xml"> <!-- SIP STCP --> <!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"> <!-- TLS --> <!ENTITY RFC5626 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5626.xml"> <!-- Outbound --> <!ENTITY RFC5627 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5627.xml"> <!-- GRUU --> <!ENTITY RFC6223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6223.xml"> <!-- SUpport for Keep-Alive --> <!ENTITY RFC6265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml"> <!-- HTTP State Management Mechanism --> <!ENTITY RFC4145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4145.xml"> <!-- TCP-Based Media Transport in SDP --> ]> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --> <?rfc strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?rfc tocdepth="4"?> <!-- the number of levels of subsections in ToC. default: 3 --> <!-- control references --> <?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --> <?rfc sortrefs="yes" ?> <!-- sort the reference entries alphabetically --> <!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --> <?rfc compact="yes" ?> <!-- do not start each main section on a new page --> <?rfc subcompact="no" ?> <!-- keep one blank line between list items --> <!-- end of list of popular I-D processing instructions --> <?rfc tocappendix="yes" ?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-bfcpbis-bfcp-websocket-15"ipr="trust200902"> <!-- category values: std, bcp, info, exp, and historic ipr values: full3667, noModification3667, noDerivatives3667 you can add the attributes updates="NNNN" and obsoletes="NNNN" they will automatically be output with "(if approved)" --> <!-- ***** FRONT MATTER ***** -->indexInclude="true" ipr="trust200902" number="8857" prepTime="2021-01-18T22:45:44" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket-15" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8857" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters --><title abbrev="WebSocket as a Transport for BFCP">The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)</title><!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --><seriesInfo name="RFC" value="8857" stream="IETF"/> <author fullname="Victor Pascual"initials="V.P."initials="V." surname="Pascual"><organization>Genaker</organization><organization showOnFrontPage="true">Nokia</organization> <address> <postal><street/> <code/><city>Barcelona</city><region/><country>Spain</country> </postal><email>victor.pascual@genaker.net</email><email>victor.pascual_avila@nokia.com</email> </address> </author> <authorfullname="Antón Román" initials="A.R." surname="Román"> <organization>Quobis</organization>fullname="Antón Román" initials="A." surname="Román"> <organization showOnFrontPage="true">Quobis</organization> <address> <postal> <extaddr>Pol. Ind. A Granxa, Casa de Pedra</extaddr> <city>O Porriño</city> <code>36475</code> <country>Spain</country> </postal> <email>anton.roman@quobis.com</email> </address> </author> <authorfullname="Stéphanefullname="Stéphane Cazeaux"initials="S.C."initials="S." surname="Cazeaux"><organization>France Telecom Orange</organization><organization showOnFrontPage="true">Orange</organization> <address> <postal> <street>42 rue des Coutures</street> <city>Caen</city> <code>14000</code> <country>France</country> </postal> <email>stephane.cazeaux@orange.com</email> </address> </author> <author fullname="Gonzalo Salgueiro"initials="G.S."initials="G." surname="Salgueiro"> <organizationabbrev="Cisco">Ciscoabbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</organization> <address> <postal> <street>7200-12 Kit Creek Road</street> <city>Research Triangle Park</city> <region>NC</region> <code>27709</code> <country>US</country> </postal> <email>gsalguei@cisco.com</email> </address> </author> <authorinitials="R"initials="R." surname="Ravindranath" fullname="Ram Mohan Ravindranath"> <organizationabbrev="Cisco">Ciscoabbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</organization> <address> <postal><street>Cessna<extaddr>Cessna BusinessPark,</street> <street>KadabeesanahalliPark</extaddr> <extaddr>Kadabeesanahalli Village, VarthurHobli,</street>Hobli,</extaddr> <street>Sarjapur-Marathahalli Outer Ring Road</street> <city>Bangalore</city> <region>Karnataka</region> <code>560103</code> <country>India</country> </postal> <email>rmohanr@cisco.com</email> </address> </author> <dateyear="2017"/> <!-- If the month and year are both specified and are the current ones, xml2rfc will fill in the current day for you. If only the current year is specified, xml2rfc will fill in the current day and month for you. If the year is not the current one, it is necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the purpose of calculating the expiry date). With drafts it is normally sufficient to specify just the year. --> <!-- Meta-data Declarations -->month="01" year="2021"/> <area>IETF</area> <workgroup>BFCPBIS Working Group</workgroup><!-- WG name at the upperleft corner of the doc, IETF is fine for individual submissions. If this element is not present, the default is "Network Working Group", which is used by the RFC Editor as a nod to the history of the IETF. --><keyword>BFCP</keyword> <keyword>WebSocket</keyword><!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. --> <abstract> <t><abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1"> The WebSocket protocol enables two-wayrealtimereal-time communication between clients and servers. This document specifies the use of Binary Floor ControlProtocol(BFCP)Protocol (BFCP) as a new WebSocketsub-protocolsubprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios. </t> </abstract></front> <middle><boilerplate> <sectionanchor="introduction" title="Introduction"> <t>The WebSocket(WS) <xref target="RFC6455"/> protocol enables two-way message exchange between clients and servers on topanchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status ofa persistent TCP connection, optionally secured with TransportThis Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t indent="0" pn="section-boilerplate.1-2"> This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. </t> <t indent="0" pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc8857" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t indent="0" pn="section-boilerplate.2-1"> Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t indent="0" pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2"> <li pn="section-toc.1-1.2.2.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-definitions">Definitions</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.3"> <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-the-websocket-protocol">The WebSocket Protocol</xref></t> </li> <li pn="section-toc.1-1.4"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-the-websocket-bfcp-subproto">The WebSocket BFCP Subprotocol</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2"> <li pn="section-toc.1-1.4.2.1"> <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-handshake">Handshake</xref></t> </li> <li pn="section-toc.1-1.4.2.2"> <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-bfcp-encoding">BFCP Encoding</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.5"> <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-reliability">Transport Reliability</xref></t> </li> <li pn="section-toc.1-1.6"> <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-considerations">SDP Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-negotiation">Transport Negotiation</xref></t> </li> <li pn="section-toc.1-1.6.2.2"> <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-media-attributes">SDP Media Attributes</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.7"> <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sdp-offer-answer-procedures">SDP Offer/Answer Procedures</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2"> <li pn="section-toc.1-1.7.2.1"> <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-general">General</xref></t> </li> <li pn="section-toc.1-1.7.2.2"> <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-usage-of-websocket-">Example Usage of 'websocket-uri' SDP Attribute</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.8"> <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication">Authentication</xref></t> </li> <li pn="section-toc.1-1.9"> <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.10"> <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2"> <li pn="section-toc.1-1.10.2.1"> <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-of-the-websock">Registration of the WebSocket BFCP Subprotocol</xref></t> </li> <li pn="section-toc.1-1.10.2.2"> <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-registration-of-the-tcp-ws-">Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto" Values</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.11"> <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2"> <li pn="section-toc.1-1.11.2.1"> <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.11.2.2"> <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.12"> <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.13"> <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1">The WebSocket (WS) protocol <xref target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/> enables two-way message exchange between clients and servers on top of a persistent TCP connection, optionally secured with Transport Layer Security (TLS) <xreftarget="RFC5246"/>.target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>. The initial protocol handshake makes use of Hypertext Transfer Protocol (HTTP) <xreftarget="RFC7230"/>target="RFC7230" format="default" sectionFormat="of" derivedContent="RFC7230"/> semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure.</t><t>The<t indent="0" pn="section-1-2">The Binary Floor Control Protocol (BFCP) is a protocol to coordinate access to shared resources in a conference. It is defined in <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/> and is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.</t><t>Modern<t indent="0" pn="section-1-3">Modern web browsers include a WebSocket client stack complying with the WebSocket API <xreftarget="WS-API"/>target="WS-API" format="default" sectionFormat="of" derivedContent="WS-API"/> as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. This document extends the applicability of <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/> and <xreftarget="I-D.ietf-bfcpbis-rfc4583bis"/>target="RFC8856" format="default" sectionFormat="of" derivedContent="RFC8856"/> to enable the usage of BFCP in these scenarios.</t><t>The<t indent="0" pn="section-1-4">The transport over which BFCP entities exchange messages depends on how the clients obtain information to contact the floor control server(e.g.(e.g., usingana Session Description Protocol (SDP) offer/answer exchange per <xreftarget="I-D.ietf-bfcpbis-rfc4583bis"/>target="RFC8856" format="default" sectionFormat="of" derivedContent="RFC8856"/> or the procedure described inRFC5018 <xref target="RFC5018"/>).RFC 5018 <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>target="RFC5018" format="default" sectionFormat="of" derivedContent="RFC5018"/>). <xref target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/> defines two transports for BFCP: TCP and UDP. This specification defines a new WebSocketsub-protocolsubprotocol (as defined inSection 1.9 in<xreftarget="RFC6455"/>)target="RFC6455" section="1.9" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#section-1.9" derivedContent="RFC6455"/>) for transporting BFCP messages between a WebSocket client and server. Thissub-protocolsubprotocol provides a reliable andboundary preservingboundary-preserving transport for BFCP when run on top of TCP. Since WebSocket provides a reliable transport, the extensions defined in <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/> for sending BFCP over unreliable transports are not applicable. </t> </section> <section anchor="terminology"title="Terminology"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-terminology">Terminology</name> <t indent="0" pn="section-2-1">The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119"/>.</t>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <section anchor="definitions"title="Definitions"> <t><list hangIndent="6" style="hanging"> <t hangText="BFCP WebSocket Client:">Anynumbered="true" toc="include" removeInRFC="false" pn="section-2.1"> <name slugifiedName="name-definitions">Definitions</name> <dl newline="false" spacing="normal" indent="6" pn="section-2.1-1"> <dt pn="section-2.1-1.1">BFCP WebSocket Client:</dt> <dd pn="section-2.1-1.2">Any BFCP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket BFCPsub-protocolsubprotocol as defined by thisdocument.</t> <t hangText="BFCP WebSocket Server:">Anydocument.</dd> <dt pn="section-2.1-1.3">BFCP WebSocket Server:</dt> <dd pn="section-2.1-1.4">Any BFCP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket BFCPsub-protocolsubprotocol as defined by thisdocument.</t> </list></t>document.</dd> </dl> </section> </section> <section anchor="the_websocket_protocol"title="Thenumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-the-websocket-protocol">The WebSocketProtocol"> <t>TheProtocol</name> <t indent="0" pn="section-3-1">The WebSocket protocol <xreftarget="RFC6455"/>target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/> is a transport layer on top of TCP (optionally secured with TLS <xreftarget="RFC5246"/>)target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>) in which both client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocketsub-protocolsubprotocol and extensions negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes.</t><t>The<t indent="0" pn="section-3-2">The WebSocket connection handshake is based on HTTP <xreftarget="RFC7230"/>target="RFC7230" format="default" sectionFormat="of" derivedContent="RFC7230"/> and utilizes the HTTP GET method with an"Upgrade" request.Upgrade header field. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake iscompletedcompleted, the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, the client and server agree on the application protocol to use on top of the WebSocket transport. Such an application protocol (also known as a "WebSocketsub-protocol")subprotocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (as the WebSocket BFCPsub-protocolsubprotocol defined in this document). Once the HTTP 101 response isprocessedprocessed, both the client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can be used for multiple message exchanges.</t><t>The<t indent="0" pn="section-3-3">The WebSocket protocol defines message units to be used by applications for the exchange of data, so it provides a message boundary-preserving transport layer.</t> </section> <section anchor="the_websocket_bfcp_subprotocol"title="Thenumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-the-websocket-bfcp-subproto">The WebSocket BFCPSub-Protocol"> <t>TheSubprotocol</name> <t indent="0" pn="section-4-1">The term WebSocketsub-protocolsubprotocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket BFCPsub-protocolsubprotocol for carrying BFCP messages over a WebSocket connection.</t> <section anchor="handshake"title="Handshake"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-handshake">Handshake</name> <t indent="0" pn="section-4.1-1">The BFCP WebSocketClientclient and BFCP WebSocketServerserver negotiate usage of the WebSocket BFCPsub-protocolsubprotocol during the WebSocket handshake procedure as defined inSection 1.3 of<xreftarget="RFC6455"/>.target="RFC6455" section="1.3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#section-1.3" derivedContent="RFC6455"/>. TheClient MUSTclient <bcp14>MUST</bcp14> include the value"BFCP""bfcp" in the Sec-WebSocket-Protocol header field in its handshake request. The 101 reply from theServer MUSTserver <bcp14>MUST</bcp14> contain"BFCP""bfcp" in its corresponding Sec-WebSocket-Protocolheader.</t> <t>Belowheader field.</t> <t indent="0" pn="section-4.1-2">Below is an example of a WebSocket handshake in which theClientclient requests the WebSocket BFCPsub-protocolsubprotocol support from theServer:<figure> <artwork><![CDATA[server:</t> <artwork name="" type="" align="left" alt="" pn="section-4.1-3"> GET / HTTP/1.1 Host: bfcp-ws.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://www.example.com Sec-WebSocket-Protocol:BFCPbfcp Sec-WebSocket-Version: 13]]></artwork> </figure></t> <t>The</artwork> <t indent="0" pn="section-4.1-4">The handshake response from theServerserver accepting the WebSocket BFCPsub-protocolsubprotocol would look asfollows:<figure> <artwork><![CDATA[follows:</t> <artwork name="" type="" align="left" alt="" pn="section-4.1-5"> HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol:BFCP ]]></artwork> </figure></t> <t>Oncebfcp </artwork> <t indent="0" pn="section-4.1-6">Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of BFCP messages. </t> </section> <section anchor="bfcp_encoding"title="BFCP Encoding"> <t>BFCPnumbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-bfcp-encoding">BFCP Encoding</name> <t indent="0" pn="section-4.2-1">BFCP messages use a TLV (Type-Length-Value) binary encoding, therefore BFCP WebSocketClientsclients and BFCP WebSocketServers MUSTservers <bcp14>MUST</bcp14> be transported in unfragmented binary WebSocket frames(FIN:1,opcode:%x2)(FIN: 1, opcode: %x2) to exchange BFCP messages. The WebSocket frame dataMUST<bcp14>MUST</bcp14> be a validBCFPBFCP message, so the length of the payload of the WebSocket frameMUST<bcp14>MUST</bcp14> be lower than the maximum size allowed(2^16(2<sup>16</sup> +12 bytes) for aBCFPBFCP message as described in <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>.target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/>. In addition, the encoding rules for reliable protocols defined in <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/> MUSTtarget="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/> <bcp14>MUST</bcp14> be followed.</t><t>While<t indent="0" pn="section-4.2-2">While this specification assumes that BFCP encoding is only TLV binary, future documents may define othermechanismsmechanisms, like JSON serialization.ifIf encodingchangeschanges, a new subprotocol identifier would need to be selected.</t><t>Each<t indent="0" pn="section-4.2-3">Each BFCP messageMUST<bcp14>MUST</bcp14> be carried within a single WebSocket message, and a WebSocket messageMUST NOT<bcp14>MUST NOT</bcp14> contain more than one BFCP message.</t> </section> </section> <section anchor="bfcp_websocket_transport"title="Transport Reliability"> <t>WebSocketnumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-transport-reliability">Transport Reliability</name> <t indent="0" pn="section-5-1">The WebSocket protocol <xreftarget="RFC6455"/>target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/> provides a reliabletransporttransport, and therefore the BFCP WebSocketsub-protocolsubprotocol defined by this document also provides reliable BFCP transport. Thus, client and server transactions using the WebSocket protocol for transportMUST<bcp14>MUST</bcp14> follow the procedures for reliable transports as defined in <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/> and <xreftarget="I-D.ietf-bfcpbis-rfc4583bis"/>.</t> <t>BFCPtarget="RFC8856" format="default" sectionFormat="of" derivedContent="RFC8856"/>.</t> <t indent="0" pn="section-5-2">BFCP WebSocket clients cannot receive incoming WebSocket connections initiated by any other peer. This means that a BFCP WebSocket clientMUST<bcp14>MUST</bcp14> actively initiate a connection towards a BFCP WebSocket server. The BFCP serveris awill have a globally routable address and thus does not requireICEICE, as clients always initiate connections to it. </t> </section> <section anchor="sdp_con"title="SDP Considerations">numbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-sdp-considerations">SDP Considerations</name> <section anchor="updates_to_rfc_4583bis"title="Transport Negotiation"> <t>Rulesnumbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-transport-negotiation">Transport Negotiation</name> <t indent="0" pn="section-6.1-1">Rules to generate an'm'"m=" line for a BFCP stream are described in <xreftarget="I-D.ietf-bfcpbis-rfc4583bis"/>, Section 3</t> <t>Newtarget="RFC8856" section="4" sectionFormat="comma" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8856#section-4" derivedContent="RFC8856"/>.</t> <t indent="0" pn="section-6.1-2">New values are defined for thetransportSDP "proto" field:TCP/WS/BFCP'TCP/WS/BFCP' andTCP/WSS/BFCP. <list style="empty"> <t>TCP/WS/BFCP'TCP/WSS/BFCP'. </t> <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.1-3"> <li pn="section-6.1-3.1">'TCP/WS/BFCP' is used when BFCP runs on top of WS, which in turn runs on top ofTCP.</t> <t>TCP/WSS/BFCPTCP.</li> <li pn="section-6.1-3.2">'TCP/WSS/BFCP' is used when BFCP runs on top ofWSS,secure WebSocket (WSS), which in turn runs on top of TLS andTCP.</t> </list></t> <t>The portTCP.</li> </ul> <t indent="0" pn="section-6.1-4">The "port" field is set following the rules in Section3<xref target="RFC8856" section="4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8856#section-4" derivedContent="RFC8856"/> and Section8.1<xref target="RFC8856" section="7.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8856#section-7.1" derivedContent="RFC8856"/> of <xreftarget="I-D.ietf-bfcpbis-rfc4583bis"/>.target="RFC8856" format="default" sectionFormat="of" derivedContent="RFC8856"/>. Depending on the value of the SDP 'setup' attribute defined in <xreftarget="RFC4145"/>,target="RFC4145" format="default" sectionFormat="of" derivedContent="RFC4145"/>, theport"port" field contains the port to which the remote endpoint will direct BFCPmessagesmessages, or it is irrelevant (i.e., the endpoint will initiate the connection towards the remote endpoint) and should be set to a value of9,'9', which is the discard port.ConnectionThe 'connection' attribute and portMUST<bcp14>MUST</bcp14> follow the rules of <xreftarget="RFC4145"/></t> <t>Whiletarget="RFC4145" format="default" sectionFormat="of" derivedContent="RFC4145"/>.</t> <t indent="0" pn="section-6.1-5">While this document recommends the use of secureWebSockets (i.e.TCP/WSS)WebSocket (i.e., TCP/WSS) for security reasons, TCP/WS is also permitted so as to achieve maximum compatibility among clients.</t> </section> <section anchor="attribute"title="SDPnumbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-sdp-media-attributes">SDP MediaAttributes"> <t><xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/>Attributes</name> <t indent="0" pn="section-6.2-1"><xref target="RFC8124" format="default" sectionFormat="of" derivedContent="RFC8124"/> defines a new SDP attribute to indicate the connection Uniform Resource Identifier (URI) for the WebSocketClient.client. The SDP attribute 'websocket-uri' defined inSection 3 of<xreftarget="I-D.ietf-bfcpbis-sdp-ws-uri"/> MUSTtarget="RFC8124" section="3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8124#section-3" derivedContent="RFC8124"/> <bcp14>MUST</bcp14> be used when BFCP runs on top of WS or WSS. When the 'websocket-uri' attribute is present in the media section of the SDP, the procedures mentioned inSection 4 of<xreftarget="I-D.ietf-bfcpbis-sdp-ws-uri"/> MUSTtarget="RFC8124" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8124#section-4" derivedContent="RFC8124"/> <bcp14>MUST</bcp14> be followed.</t> </section> </section> <sectiontitle="SDPnumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-sdp-offer-answer-procedures">SDP Offer/AnswerProcedures">Procedures</name> <section anchor="general"title="General"> <t>numbered="true" toc="include" removeInRFC="false" pn="section-7.1"> <name slugifiedName="name-general">General</name> <t indent="0" pn="section-7.1-1"> An endpoint (i.e., both the offerer and the answerer)MUST<bcp14>MUST</bcp14> create an SDP media description ("m=" line) for each BFCP-over-WebSocket media stream andMUST<bcp14>MUST</bcp14> assign eitherTCP/WSS/BFCPa 'TCP/WSS/BFCP' orTCP/WS/BFCP'TCP/WS/BFCP' value to the "proto" field of the "m=" line depending on whether the endpoint wishes to use secure WebSocket or WebSocket. Furthermore, the server side, which could be either the offerer or answerer,MUST<bcp14>MUST</bcp14> addan "a=websocket-uri"a 'websocket-uri' attribute in the media section depending on whether it wishes to use WebSocket or secure WebSocket. This new attributeMUST<bcp14>MUST</bcp14> follow the syntax defined in <xreftarget="I-D.ietf-bfcpbis-sdp-ws-uri"/>.target="RFC8124" format="default" sectionFormat="of" derivedContent="RFC8124"/>. Additionally, the SDPOffer/Answeroffer/answer procedures defined inSection 4 of<xreftarget="I-D.ietf-bfcpbis-sdp-ws-uri"/> MUSTtarget="RFC8124" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8124#section-4" derivedContent="RFC8124"/> <bcp14>MUST</bcp14> be followed for the "m=" line associated with a BFCP-over-WebSocket media stream.</t> </section> <section anchor="example"title="Examplenumbered="true" toc="include" removeInRFC="false" pn="section-7.2"> <name slugifiedName="name-example-usage-of-websocket-">Example Usage of 'websocket-uri' SDPAttribute"> <t>TheAttribute</name> <t indent="0" pn="section-7.2-1">The following is an example of an "m=" line for a BFCP connection. In this example, the offerer sends the SDP with the "proto" field having a value ofTCP/WSS/BFCP *'TCP/WSS/BFCP', indicating that the offerer wishes to use secure WebSocket as a transport for the mediastream.</t> <t> <figure> <artwork><![CDATA[stream, and the "fmt" field having a value of '*' (for details on the "fmt" field, see <xref target="RFC8856" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8856#section-4" derivedContent="RFC8856"/>).</t> <sourcecode type="sdp" markers="false" pn="section-7.2-2"> Offer (browser): m=application 9 TCP/WSS/BFCP * a=setup:active a=connection:new a=floorctrl:c-only m=audio 55000 RTP/AVP 0 m=video 55002 RTP/AVP 31 Answer (server): m=application 50000 TCP/WSS/BFCP * a=setup:passive a=connection:new a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312 a=floorctrl:s-only a=confid:4321 a=userid:1234 a=floorid:1 m-stream:10 a=floorid:2 m-stream:11 m=audio 50002 RTP/AVP 0 a=label:10 m=video 50004 RTP/AVP 31 a=label:11]]></artwork> </figure></t> <t></sourcecode> <t indent="0" pn="section-7.2-3"> It is possible that an endpoint (e.g., a browser) sends an offerless INVITE to the server. In suchcasescases, the server will act as SDP offerer. The serverMUST<bcp14>MUST</bcp14> assign the SDP"setup"'setup' attribute with a value of"passive".'passive'. The serverMUST<bcp14>MUST</bcp14> havean "a=websocket-uri"a 'websocket-uri' attribute with a"ws-URI"'ws-URI' or"wss-URI"'wss-URI' value depending on whether the server wishes to use WebSocket or secure WebSocket. This attributeMUST<bcp14>MUST</bcp14> follow the syntax defined inSection 3 of<xreftarget="I-D.ietf-bfcpbis-sdp-ws-uri"/> .target="RFC8124" section="3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8124#section-3" derivedContent="RFC8124"/>. For BFCP application, the "proto" value in the "m=" lineMUST<bcp14>MUST</bcp14> beTCP/WSS/BFCP'TCP/WSS/BFCP' if WebSocket is over TLS, else itMUST<bcp14>MUST</bcp14> beTCP/WS/BFCP.'TCP/WS/BFCP'. </t> </section> </section> <section anchor="authentication"title="Authentication"> <t>Section 9 of <xref target="I-D.ietf-bfcpbis-rfc4582bis"/>numbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-authentication">Authentication</name> <t indent="0" pn="section-8-1"><xref target="RFC8855" section="9" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8855#section-9" derivedContent="RFC8855"/> states that BFCP clients and floor control serversSHOULD<bcp14>SHOULD</bcp14> authenticate each other prior to accepting messages, and RECOMMENDS that mutual TLS/DTLS authentication be used. However, browser-based WebSocket clients have no control over the use of TLS in the WebSocket API <xreftarget="WS-API"/>,target="WS-API" format="default" sectionFormat="of" derivedContent="WS-API"/>, so it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that standardWeb-basedweb-based methods for client and server authentication are used, as follows.</t><t>When<t indent="0" pn="section-8-2">When a BFCP WebSocket client connects to a BFCP WebSocket server, itSHOULD<bcp14>SHOULD</bcp14> use TCP/WSS as its transport. If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected,Securesecure WebSocket (WSS)MUST<bcp14>MUST</bcp14> be used, and the floor control serverMUST<bcp14>MUST</bcp14> authenticate the client. The WebSocket clientMUST<bcp14>MUST</bcp14> follow the procedures in <xreftarget="RFC7525"/>target="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525"/> while setting up TLS connection with the WebSocket server. The BFCP client validates the server by means of verifying the server certificate. This means the"websocket-uri"'websocket-uri' valueMUST<bcp14>MUST</bcp14> contain a hostname. The verification process does not usea=fingerprint.</t> <t>A"a=fingerprint".</t> <t indent="0" pn="section-8-3">A floor control server that receives a message over TCP/WS can mandate the use of TCP/WSS by generating an Error message, as described inSection 13.8 of<xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>,target="RFC8855" section="13.8" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8855#section-13.8" derivedContent="RFC8855"/>, with anErrorerror code with a value of 9(use(Use TLS).</t><t>Prior<t indent="0" pn="section-8-4">Prior to sending BFCP requests, a BFCP WebSocket client connects to a BFCP WebSocket server and performs the connection handshake. As described in <xreftarget="the_websocket_protocol"/>target="handshake" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, the handshake procedure involvesaan HTTP GET method request from the client and a response from the server including an HTTP 101 status code.</t><t>In<t indent="0" pn="section-8-5">In order to authorize the WebSocket connection, the BFCP WebSocket serverSHOULD<bcp14>SHOULD</bcp14> inspect any cookie header fields <xreftarget="RFC6265"/> headerstarget="RFC6265" format="default" sectionFormat="of" derivedContent="RFC6265"/> present in the HTTP GET request. For many webapplicationsapplications, the value of such a cookie is provided by the web server once the user has authenticated themselves to the web server, which could be done by many existing mechanisms. As an alternative method, the BFCP WebSocketServerserver could request HTTP authentication by replying to theClient'sclient's GET method request withaan HTTP 401 status code. The WebSocket protocol <xreftarget="RFC6455"/>target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/> covers this usage in Section4.1: <list style="empty"> <t>If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP<xreftarget="RFC7230"/> procedures, in particular the client might perform authentication if it receives 401 status code.</t> <t>Iftarget="RFC6455" section="4.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#section-4.1" derivedContent="RFC6455"/>: </t> <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-8-6"> <li pn="section-8-6.1">If the status code received from the server is not 101, the WebSocket client stack handles the response per HTTP <xreftarget="RFC7230"/> procedures,target="RFC7230" format="default" sectionFormat="of" derivedContent="RFC7230"/> procedures; inparticularparticular, the client might perform authentication if it receives an 401 status code. The WebSocket clients are vulnerable to the attacks of basic authentication (mentioned inSection 4 of<xreftarget="RFC7617"/>)target="RFC7617" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7617#section-4" derivedContent="RFC7617"/>) and digest authentication (mentioned inSection 5 of<xreftarget="RFC7616"/>]).target="RFC7616" section="5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7616#section-5" derivedContent="RFC7616"/>). To overcome some of theseweakness, theweaknesses, WebSocket clientsfor examplecan use the HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in <xreftarget="RFC7486"/>.</t> </list></t>target="RFC7486" format="default" sectionFormat="of" derivedContent="RFC7486"/>, for example.</li> </ul> </section> <section anchor="security_considerations"title="Security Considerations"> <t>Considerationsnumbered="true" toc="include" removeInRFC="false" pn="section-9"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-9-1">Considerations from <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>, <xref target="I-D.ietf-bfcpbis-rfc4583bis"/>target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/>, <xref target="RFC8856" format="default" sectionFormat="of" derivedContent="RFC8856"/>, andRFC5018<xreftarget="RFC5018"/>target="RFC5018" format="default" sectionFormat="of" derivedContent="RFC5018"/> apply.</t><t>BFCP<t indent="0" pn="section-9-2">BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the BFCP traffic transported overaWebSocketcommunicationbe protected by using asecureSecure WebSocket connection (using TLS <xreftarget="RFC5246"/>target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> over TCP). The security considerations in <xreftarget="RFC6455"/>target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/> apply for BFCP over WebSocket as well. The security model here is a typical webserver-client model where the client validates the server certificate and then connects to the server. <xreftarget="authentication"/>target="authentication" format="default" sectionFormat="of" derivedContent="Section 8"/> describes the authentication procedures between client and server.</t><t>When<t indent="0" pn="section-9-3">When using BFCP overwebsockets,WebSocket, the security mechanisms defined in <xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>target="RFC8855" format="default" sectionFormat="of" derivedContent="RFC8855"/> are not used. Instead, the application is required to build and rely on the security mechanisms in <xreftarget="RFC6455"/>.</t> <t>Thetarget="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/>.</t> <t indent="0" pn="section-9-4">The rest of this section analyses the threats described inSection 14 of<xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/>target="RFC8855" section="14" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8855#section-14" derivedContent="RFC8855"/> when WebSocket is used as a transport protocol for BFCP.</t><t>An<t indent="0" pn="section-9-5">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 theserversserver's certificate. Thefloor controlBFCP WebSocket clientMUST<bcp14>MUST</bcp14> follow the procedures in <xreftarget="RFC7525"/>target="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525"/> (including hostname verification as perSection 6.1 in<xreftarget="RFC7525"/>)target="RFC7525" section="6.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7525#section-6.1" derivedContent="RFC7525"/>) while setting up a TLS connection with floor controlwebSocketWebSocket server.</t><t>An<t indent="0" pn="section-9-6">An attacker attempting to impersonate a floor control client is avoided by having servers accept BFCP messages over WSS only. As described inSection 10.5 of<xreftarget="RFC6455"/>target="RFC6455" section="10.5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#section-10.5" derivedContent="RFC6455"/> the floor control server can use any client authentication mechanism and follow the steps in <xreftarget="authentication"/>target="authentication" format="default" sectionFormat="of" derivedContent="Section 8"/> of this document.</t><t>Attackers<t indent="0" pn="section-9-7">Attackers may attempt to modify messages exchanged by a client and a floor control server. This can be prevented by having WSS between client and server.</t><t>An<t indent="0" pn="section-9-8">An attacker trying to replay the messages is prevented by having floor control servers check that messages arriving over a given WSS connection use an authorized user ID. </t><t>Attackers may<t indent="0" pn="section-9-9">Attackers may eavesdrop on the network to get access to confidential information between the floor control server and a client (e.g., why a floor request was denied). In order to ensure that BFCP users are getting the level of protection that they would get usingtheBFCPprotocoldirectly, applications need to have a way to control thewebsocketWebSocket libraries to use encryption algorithms specified inSection 7 of<xreftarget="I-D.ietf-bfcpbis-rfc4582bis"/> .target="RFC8855" section="7" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8855#section-7" derivedContent="RFC8855"/>. Since the WebSocket API <xreftarget="WS-API"/>target="WS-API" format="default" sectionFormat="of" derivedContent="WS-API"/> does not have a way to allow an application to select the encryption algorithm to be used, the protection level provided when WSS is used is limited to the underlying TLS algorithm used by the WebSocket library.</t> </section> <section anchor="iana_considerations"title="IANA Considerations">numbered="true" toc="include" removeInRFC="false" pn="section-10"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <sectiontitle="Registrationnumbered="true" toc="include" removeInRFC="false" pn="section-10.1"> <name slugifiedName="name-registration-of-the-websock">Registration of the WebSocket BFCPSub-Protocol"> <t>This specification requests IANA to registerSubprotocol</name> <t indent="0" pn="section-10.1-1">IANA has registered the WebSocket BFCPsub-protocolsubprotocol under the "WebSocket SubprotocolName" Registry with the following data:</t> <t><list style="hanging"> <t hangText="Subprotocol Identifier:">BFCP</t> <t hangText="SubprotocolName Registry" as follows:</t> <dl newline="false" spacing="normal" indent="3" pn="section-10.1-2"> <dt pn="section-10.1-2.1">Subprotocol Identifier:</dt> <dd pn="section-10.1-2.2">bfcp</dd> <dt pn="section-10.1-2.3">Subprotocol CommonName:">WebSocketName:</dt> <dd pn="section-10.1-2.4">WebSocket Transport for BFCP (Binary Floor ControlProtocol)</t> <t hangText="Subprotocol Definition:">RFC&rfc.number;</t> </list></t> <t>[[NOTE TO RFC EDITOR: Please change &rfc.number; to the number assigned to this specification, and remove this paragraph on publication.]]</t>Protocol)</dd> <dt pn="section-10.1-2.5">Subprotocol Definition:</dt> <dd pn="section-10.1-2.6">RFC 8857</dd> </dl> </section> <sectiontitle="Registrationnumbered="true" toc="include" removeInRFC="false" pn="section-10.2"> <name slugifiedName="name-registration-of-the-tcp-ws-">Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP'proto' Values"> <t>This"proto" Values</name> <t indent="0" pn="section-10.2-1">This document defines two new values for the SDP'proto' field under"proto" subregistry within theSession"Session Description Protocol (SDP)ParametersParameters" registry. The resulting entries are shown in <xreftarget="IANA_SDP_proto"/> below:<figuretarget="IANA_SDP_proto" format="default" sectionFormat="of" derivedContent="Table 1"/>:</t> <table anchor="IANA_SDP_proto" align="center"title="Valuespn="table-1"> <name slugifiedName="name-values-for-the-sdp-proto-fi">Values for the SDP'proto' Field"> <artwork><![CDATA[ Value Reference ---------- ----------- TCP/WS/BFCP RFCXXXX; TCP/WSS/BFCP RFCXXXX; ]]></artwork> </figure></t> <t>[[NOTE TO RFC EDITOR: Please change &rfc.number; to the number assigned to this specification, and remove this paragraph on publication.]]</t>"proto" Field</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">TCP/WS/BFCP</td> <td align="left" colspan="1" rowspan="1">RFC 8857</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">TCP/WSS/BFCP</td> <td align="left" colspan="1" rowspan="1">RFC 8857</td> </tr> </tbody> </table> </section> </section><section anchor="acknowledgements" title="Acknowledgements"> <t>The authors want to thank Robert Welbourn, from Acme Packet and Sergio Garcia Murillo who made significant contributions</middle> <back> <references pn="section-11"> <name slugifiedName="name-references">References</name> <references pn="section-11.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words for use in RFCs tothe first versionIndicate Requirement Levels</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1997" month="March"/> <abstract> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC4145" target="https://www.rfc-editor.org/info/rfc4145" quoteTitle="true" derivedAnchor="RFC4145"> <front> <title>TCP-Based Media Transport in the Session Description Protocol (SDP)</title> <author initials="D." surname="Yon" fullname="D. Yon"> <organization showOnFrontPage="true"/> </author> <author initials="G." surname="Camarillo" fullname="G. Camarillo"> <organization showOnFrontPage="true"/> </author> <date year="2005" month="September"/> <abstract> <t indent="0">This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4145"/> <seriesInfo name="DOI" value="10.17487/RFC4145"/> </reference> <reference anchor="RFC5018" target="https://www.rfc-editor.org/info/rfc5018" quoteTitle="true" derivedAnchor="RFC5018"> <front> <title>Connection Establishment in the Binary Floor Control Protocol (BFCP)</title> <author initials="G." surname="Camarillo" fullname="G. Camarillo"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="September"/> <abstract> <t indent="0">This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5018"/> <seriesInfo name="DOI" value="10.17487/RFC5018"/> </reference> <reference anchor="RFC6455" target="https://www.rfc-editor.org/info/rfc6455" quoteTitle="true" derivedAnchor="RFC6455"> <front> <title>The WebSocket Protocol</title> <author initials="I." surname="Fette" fullname="I. Fette"> <organization showOnFrontPage="true"/> </author> <author initials="A." surname="Melnikov" fullname="A. Melnikov"> <organization showOnFrontPage="true"/> </author> <date year="2011" month="December"/> <abstract> <t indent="0">The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6455"/> <seriesInfo name="DOI" value="10.17487/RFC6455"/> </reference> <reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7525" quoteTitle="true" derivedAnchor="RFC7525"> <front> <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title> <author initials="Y." surname="Sheffer" fullname="Y. Sheffer"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Holz" fullname="R. Holz"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="May"/> <abstract> <t indent="0">Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t> </abstract> </front> <seriesInfo name="BCP" value="195"/> <seriesInfo name="RFC" value="7525"/> <seriesInfo name="DOI" value="10.17487/RFC7525"/> </reference> <reference anchor="RFC8124" target="https://www.rfc-editor.org/info/rfc8124" quoteTitle="true" derivedAnchor="RFC8124"> <front> <title>The Session Description Protocol (SDP) WebSocket Connection URI Attribute</title> <author initials="R." surname="Ravindranath" fullname="R. Ravindranath"> <organization showOnFrontPage="true"/> </author> <author initials="G." surname="Salgueiro" fullname="G. Salgueiro"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="March"/> <abstract> <t indent="0">The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.</t> </abstract> </front> <seriesInfo name="RFC" value="8124"/> <seriesInfo name="DOI" value="10.17487/RFC8124"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="May"/> <abstract> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8855" target="https://www.rfc-editor.org/info/rfc8855" quoteTitle="true" derivedAnchor="RFC8855"> <front> <title>The Binary Floor Control Protocol (BFCP)</title> <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo"> <organization showOnFrontPage="true"/> </author> <author initials="K." surname="Drage" fullname="Keith Drage"> <organization showOnFrontPage="true"/> </author> <author initials="T." surname="Kristensen" fullname="Tom Kristensen"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Ott" fullname="Jörg Ott"> <organization showOnFrontPage="true"/> </author> <author initials="C." surname="Eckel" fullname="Charles Eckel"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8855"/> <seriesInfo name="DOI" value="10.17487/RFC8855"/> </reference> <reference anchor="RFC8856" target="https://www.rfc-editor.org/info/rfc8856" quoteTitle="true" derivedAnchor="RFC8856"> <front> <title>Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams</title> <author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo"> <organization showOnFrontPage="true"/> </author> <author initials="T" surname="Kristensen" fullname="Tom Kristensen"> <organization showOnFrontPage="true"/> </author> <author initials="C." surname="Holmberg" fullname="Christer Holmberg"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8856"/> <seriesInfo name="DOI" value="10.17487/RFC8856"/> </reference> </references> <references pn="section-11.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="RFC6265" target="https://www.rfc-editor.org/info/rfc6265" quoteTitle="true" derivedAnchor="RFC6265"> <front> <title>HTTP State Management Mechanism</title> <author initials="A." surname="Barth" fullname="A. Barth"> <organization showOnFrontPage="true"/> </author> <date year="2011" month="April"/> <abstract> <t indent="0">This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6265"/> <seriesInfo name="DOI" value="10.17487/RFC6265"/> </reference> <reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7230" quoteTitle="true" derivedAnchor="RFC7230"> <front> <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title> <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2014" month="June"/> <abstract> <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="7230"/> <seriesInfo name="DOI" value="10.17487/RFC7230"/> </reference> <reference anchor="RFC7486" target="https://www.rfc-editor.org/info/rfc7486" quoteTitle="true" derivedAnchor="RFC7486"> <front> <title>HTTP Origin-Bound Authentication (HOBA)</title> <author initials="S." surname="Farrell" fullname="S. Farrell"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Hoffman" fullname="P. Hoffman"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Thomas" fullname="M. Thomas"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="March"/> <abstract> <t indent="0">HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.</t> </abstract> </front> <seriesInfo name="RFC" value="7486"/> <seriesInfo name="DOI" value="10.17487/RFC7486"/> </reference> <reference anchor="RFC7616" target="https://www.rfc-editor.org/info/rfc7616" quoteTitle="true" derivedAnchor="RFC7616"> <front> <title>HTTP Digest Access Authentication</title> <author initials="R." surname="Shekh-Yusef" fullname="R. Shekh-Yusef" role="editor"> <organization showOnFrontPage="true"/> </author> <author initials="D." surname="Ahrens" fullname="D. Ahrens"> <organization showOnFrontPage="true"/> </author> <author initials="S." surname="Bremer" fullname="S. Bremer"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="September"/> <abstract> <t indent="0">The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.</t> </abstract> </front> <seriesInfo name="RFC" value="7616"/> <seriesInfo name="DOI" value="10.17487/RFC7616"/> </reference> <reference anchor="RFC7617" target="https://www.rfc-editor.org/info/rfc7617" quoteTitle="true" derivedAnchor="RFC7617"> <front> <title>The 'Basic' HTTP Authentication Scheme</title> <author initials="J." surname="Reschke" fullname="J. Reschke"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="September"/> <abstract> <t indent="0">This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64.</t> </abstract> </front> <seriesInfo name="RFC" value="7617"/> <seriesInfo name="DOI" value="10.17487/RFC7617"/> </reference> <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author initials="E." surname="Rescorla" fullname="E. Rescorla"> <organization showOnFrontPage="true"/> </author> <date year="2018" month="August"/> <abstract> <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="WS-API" target="https://www.w3.org/TR/2012/CR-websockets-20120920/" quoteTitle="true" derivedAnchor="WS-API"> <front> <title>The WebSocket API</title> <author fullname="Ian Hickson" initials="I." role="editor" surname="Hickson"> </author> </front> <refcontent>W3C Candidate Recommendation, September 2012</refcontent> </reference> </references> </references> <section anchor="acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t indent="0" pn="section-appendix.a-1">The authors want to thank <contact fullname="Robert Welbourn"/> from Acme Packet and <contact fullname="Sergio Garcia Murillo"/>, who made significant contributions to the first draft version of this document. This work benefited from the thorough review and constructive comments ofCharles Eckel, Christer Holmberg, Paul Kyzivat, Dan Wing and Alissa Cooper.<contact fullname="Charles Eckel"/>, <contact fullname="Christer Holmberg"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Dan Wing"/>, and <contact fullname="Alissa Cooper"/>. Thanks toBert Wijnen, Robert Sparks and Mirja Kuehlewind<contact fullname="Bert Wijnen"/>, <contact fullname="Robert Sparks"/>, and <contact fullname="Mirja Kühlewind"/> for their reviews and comments on this document. </t><t><t indent="0" pn="section-appendix.a-2"> Thanksfor Spencers Dawkin, Ben Campbell, Kathleen Moriarty, Alexey Melnikov, Jari Arkko and Stephen Farrellto <contact fullname="Spencer Dawkins"/>, <contact fullname="Ben Campbell"/>, <contact fullname="Kathleen Moriarty"/>, <contact fullname="Alexey Melnikov"/>, <contact fullname="Jari Arkko"/>, and <contact fullname="Stephen Farrell"/> for their feedback and comments during IESG reviews. </t> </section></middle> <!-- *****BACK MATTER ***** --> <back> <!-- References split into informative and normative --> <!-- There are 2 ways to insert reference entries from the citation libraries: 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both are cited textually in the same manner: by using xref elements. If you use the PI option, xml2rfc will, by default, try to find included files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--> <references title="Normative References"> &RFC2119; &RFC4145; &RFC6455; &RFC5018; &BFCPbis; &RFC7525; &SDPBFCPbis; <?rfc include="reference.I-D.ietf-bfcpbis-sdp-ws-uri"?> </references> <references title="Informative References"> &RFC7230; &RFC5246; &RFC6265; &RFC7616; &RFC7617; &RFC7486; <reference anchor="WS-API"> <front> <title>The WebSocket API</title> <author> <organization>W3C</organization><section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Victor Pascual" initials="V." surname="Pascual"> <organization showOnFrontPage="true">Nokia</organization> <address> <postal> <city>Barcelona</city> <country>Spain</country> </postal> <email>victor.pascual_avila@nokia.com</email> </address> </author> <authorfullname="Ian Hickson" initials="I." role="editor" surname="Hickson"> <organization>Google,fullname="Antón Román" initials="A." surname="Román"> <organization showOnFrontPage="true">Quobis</organization> <address> <postal> <extaddr>Pol. Ind. A Granxa, Casa de Pedra</extaddr> <city>O Porriño</city> <code>36475</code> <country>Spain</country> </postal> <email>anton.roman@quobis.com</email> </address> </author> <author fullname="Stéphane Cazeaux" initials="S." surname="Cazeaux"> <organization showOnFrontPage="true">Orange</organization> <address> <postal> <street>42 rue des Coutures</street> <city>Caen</city> <code>14000</code> <country>France</country> </postal> <email>stephane.cazeaux@orange.com</email> </address> </author> <author fullname="Gonzalo Salgueiro" initials="G." surname="Salgueiro"> <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</organization> <address> <postal> <street>7200-12 Kit Creek Road</street> <city>Research Triangle Park</city> <region>NC</region> <code>27709</code> <country>US</country> </postal> <email>gsalguei@cisco.com</email> </address> </author> <author initials="R." surname="Ravindranath" fullname="Ram Mohan Ravindranath"> <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</organization> <address> <postal> <extaddr>Cessna Business Park</extaddr> <extaddr>Kadabeesanahalli Village, Varthur Hobli,</extaddr> <street>Sarjapur-Marathahalli Outer Ring Road</street> <city>Bangalore</city> <region>Karnataka</region> <code>560103</code> <country>India</country> </postal> <email>rmohanr@cisco.com</email> </address> </author><date month="May" year="2012"/> </front> </reference> </references></section> </back> </rfc>