<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> version='1.0' encoding='utf-8'?>
<!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" ?> "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-bfcpbis-bfcp-websocket-15"
     ipr="trust200902"> number="8857" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

<!-- 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 ***** xml2rfc v2v3 conversion 2.35.0 -->
    <!-- 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

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->
<seriesInfo name="RFC" value="8857"/>

    <author fullname="Victor Pascual" initials="V.P." initials="V." surname="Pascual">
    <author fullname="Ant&oacute;n Rom&aacute;n" initials="A.R."
            surname="Rom&aacute;n"> fullname="Antón Román" initials="A." surname="Román">
          <extaddr>Pol. Ind. A Granxa, Casa de Pedra</extaddr>
          <city>O Porriño</city>
    <author fullname="St&eacute;phane fullname="Stéphane Cazeaux" initials="S.C." initials="S." surname="Cazeaux">
      <organization>France Telecom Orange</organization>
        <street>42 rue des Coutures</street>
    <author fullname="Gonzalo Salgueiro" initials="G.S." initials="G." surname="Salgueiro">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
          <street>7200-12 Kit Creek Road</street>
          <city>Research Triangle Park</city>
    <author initials="R" initials="R." surname="Ravindranath" fullname="Ram Mohan Ravindranath">
      <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
          <extaddr>Cessna Business Park,</street>
					<street>Kadabeesanahalli Park</extaddr>
          <extaddr>Kadabeesanahalli Village, Varthur Hobli,</street>
					<street>Sarjapur-Marathahalli Outer Ring Road</street>

    <date year="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 --> Varthur Hobli,</extaddr>
          <street>Sarjapur-Marathahalli Outer Ring Road</street>
    <date month="May" year="2020"/>
    <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. -->

    <!-- 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. -->
      <t> The WebSocket protocol enables two-way realtime real-time communication
      between clients and servers. This document specifies the use of Binary Floor
       Control Protocol(BFCP) Protocol (BFCP) as a new WebSocket sub-protocol subprotocol enabling a reliable
       transport mechanism between BFCP entities in new scenarios. </t>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <t>The WebSocket(WS) <xref target="RFC6455"/> WebSocket (WS) protocol <xref target="RFC6455" format="default"/> enables
      two-way message exchange between clients and servers on top of a
      persistent TCP connection, optionally secured with Transport Layer Security (TLS)
      <xref target="RFC5246"/>. target="RFC8446" format="default"/>. The initial protocol handshake makes use of
      Hypertext Transfer Protocol (HTTP) <xref target="RFC7230"/> target="RFC7230" format="default"/> semantics, allowing the WebSocket
      protocol to reuse existing HTTP infrastructure.</t>
      <t>The Binary Floor Control Protocol (BFCP) is a protocol to
      coordinate access to shared resources in a conference. It is
      defined in <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> target="RFC8855" format="default"/> and is
      used between floor participants and floor control servers, and
      between floor chairs (i.e., moderators) and floor control
      <t>Modern web browsers include a WebSocket client stack
      complying with the WebSocket API <xref target="WS-API"/> target="WS-API" format="default"/> 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
      <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> target="RFC8855" format="default"/> and
      <xref target="I-D.ietf-bfcpbis-rfc4583bis"/> target="RFC8856" format="default"/> to enable the
      usage of BFCP in these scenarios.</t>
      <t>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., using an a Session Description Protocol (SDP)
      offer/answer exchange per <xref target="I-D.ietf-bfcpbis-rfc4583bis"/> target="RFC8856" format="default"/> or the
      procedure described in RFC5018 RFC 5018 <xref target="RFC5018"/>). target="RFC5018" format="default"/>).
      <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> target="RFC8855" format="default"/> defines two transports
      for BFCP: TCP and UDP. This specification defines a new
      WebSocket sub-protocol subprotocol (as defined in Section 1.9 in
      target="RFC6455"/>) target="RFC6455" section="1.9" sectionFormat="of" format="default"/>) for transporting BFCP messages between a
      WebSocket client and server. This sub-protocol subprotocol provides a reliable and boundary
      boundary-preserving transport for BFCP when run on top of TCP. Since WebSocket provides
      a reliable transport, the extensions defined in <xref
          target="I-D.ietf-bfcpbis-rfc4582bis"/> target="RFC8855" format="default"/> for sending BFCP over unreliable
          transports are not applicable. </t>
    <section anchor="terminology" title="Terminology"> numbered="true" toc="default">
      <t>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
      <xref target="RFC2119"/> <xref target="RFC2119"/>.</t> target="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 numbered="true" toc="default">
        <dl newline="false" spacing="normal" indent="6">
          <dt>BFCP WebSocket Client:">Any Client:</dt>
          <dd>Any BFCP entity capable
            of opening outbound connections to WebSocket servers and
            communicating using the WebSocket BFCP sub-protocol subprotocol as
            defined by this document.</t>

            <t hangText="BFCP document.</dd>
          <dt>BFCP WebSocket Server:">Any Server:</dt>
          <dd>Any BFCP entity capable
            of listening for inbound connections from WebSocket
            clients and communicating using the WebSocket BFCP
            subprotocol as defined by this document.</t>
          </list></t> document.</dd>
    <section anchor="the_websocket_protocol"
             title="The numbered="true" toc="default">
      <name>The WebSocket Protocol"> Protocol</name>
      <t>The WebSocket protocol <xref target="RFC6455"/> target="RFC6455" format="default"/> is a
      transport layer on top of TCP (optionally secured with
      TLS <xref
      target="RFC5246"/>) target="RFC8446" format="default"/>) in which both client and server exchange
      message units in both directions. The protocol defines a
      connection handshake, WebSocket sub-protocol subprotocol 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 WebSocket connection handshake is based on
      HTTP <xref
      target="RFC7230"/> target="RFC7230" format="default"/> 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 is completed completed, 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 "WebSocket
      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 BFCP sub-protocol subprotocol defined in
      this document). Once the HTTP 101 response is processed processed, 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 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 anchor="the_websocket_bfcp_subprotocol"
             title="The numbered="true" toc="default">
      <name>The WebSocket BFCP Sub-Protocol"> Subprotocol</name>
      <t>The term WebSocket sub-protocol subprotocol refers to an
      application-level protocol layered on top of a WebSocket
      connection. This document specifies the WebSocket BFCP
      subprotocol for carrying BFCP messages over a WebSocket
      <section anchor="handshake" title="Handshake"> numbered="true" toc="default">
        <t>The BFCP WebSocket Client client and BFCP WebSocket Server server
        negotiate usage of the WebSocket BFCP sub-protocol subprotocol during the
        WebSocket handshake procedure as defined in Section 1.3 of
        <xref target="RFC6455"/>. target="RFC6455" section="1.3" sectionFormat="of" format="default"/>.
        The Client MUST client <bcp14>MUST</bcp14> include the value
        "bfcp" in the Sec-WebSocket-Protocol header field in its handshake
        request. The 101 reply from the Server MUST server <bcp14>MUST</bcp14> contain "BFCP" "bfcp" in
        its corresponding Sec-WebSocket-Protocol header.</t> header field.</t>
        <t>Below is an example of a WebSocket handshake in which the
        client requests the WebSocket BFCP sub-protocol subprotocol support from
        the Server:<figure>
            <artwork><![CDATA[ server:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  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: BFCP bfcp
  Sec-WebSocket-Version: 13
        <t>The handshake response from the Server server accepting the
        WebSocket BFCP sub-protocol subprotocol would look as follows:<figure>
            <artwork><![CDATA[ follows:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  HTTP/1.1 101 Switching Protocols
  Upgrade: websocket
  Connection: Upgrade
  Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
  Sec-WebSocket-Protocol: BFCP bfcp
        <t>Once the negotiation has been completed, the WebSocket
        connection is established and can be used for the transport of
        BFCP messages. </t>
      <section anchor="bfcp_encoding" title="BFCP Encoding"> numbered="true" toc="default">
        <name>BFCP Encoding</name>
        <t>BFCP messages use a TLV (Type-Length-Value) binary
        encoding, therefore BFCP WebSocket Clients clients and BFCP WebSocket
        Servers MUST
        servers <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 data MUST <bcp14>MUST</bcp14> be a valid BCFP BFCP message, so the
        length of the payload of the WebSocket frame MUST <bcp14>MUST</bcp14> be lower
        than the maximum size allowed (2^16 (2<sup>16</sup> +12 bytes) for a BCFP BFCP
        message as described in <xref
        target="I-D.ietf-bfcpbis-rfc4582bis"/>. target="RFC8855" format="default"/>. In addition, the
        encoding rules for reliable protocols defined in <xref
        target="I-D.ietf-bfcpbis-rfc4582bis"/> MUST target="RFC8855" format="default"/>
        <bcp14>MUST</bcp14> be followed.</t>
        <t>While this specification assumes that BFCP encoding is only TLV binary,
          future documents may define other mechanisms mechanisms, like JSON serialization.
         If encoding changes changes, a new subprotocol identifier would need to be selected.</t>
        <t>Each BFCP message MUST <bcp14>MUST</bcp14> be carried within a single WebSocket
      message, and a WebSocket message MUST NOT <bcp14>MUST NOT</bcp14> contain more than one
      BFCP message.</t>
    <section anchor="bfcp_websocket_transport"
             title="Transport Reliability">
      <t>WebSocket numbered="true" toc="default">
      <name>Transport Reliability</name>
      <t>The WebSocket protocol <xref target="RFC6455"/> target="RFC6455" format="default"/> provides a reliable transport transport, and
      therefore the BFCP WebSocket sub-protocol subprotocol defined by this
      document also provides reliable BFCP transport. Thus, client and server
      transactions using the WebSocket protocol for transport MUST <bcp14>MUST</bcp14> follow the
      procedures for reliable transports as defined in <xref
      target="I-D.ietf-bfcpbis-rfc4582bis"/> target="RFC8855" format="default"/>
      and <xref
      target="I-D.ietf-bfcpbis-rfc4583bis"/>.</t> target="RFC8856" format="default"/>.</t>
      <t>BFCP WebSocket clients cannot receive incoming WebSocket
      connections initiated by any other peer. This means that a BFCP
      WebSocket client MUST <bcp14>MUST</bcp14> actively initiate a connection towards a
      BFCP WebSocket server. The BFCP server is a will have a globally routable address
      and thus does not require ICE ICE, as clients always initiate connections to it. </t>
    <section anchor="sdp_con"
    title="SDP Considerations"> numbered="true" toc="default">
      <name>SDP Considerations</name>
      <section anchor="updates_to_rfc_4583bis"
        title="Transport Negotiation"> numbered="true" toc="default">
        <name>Transport Negotiation</name>
        <t>Rules to generate an 'm' "m=" line for a BFCP stream are described
      in <xref target="I-D.ietf-bfcpbis-rfc4583bis"/>, Section 3</t> target="RFC8856" section="4" sectionFormat="comma" format="default"/>.</t>

        <t>New values are defined for the transport SDP "proto" field: TCP/WS/BFCP 'TCP/WS/BFCP'
      and TCP/WSS/BFCP. <list style="empty">
          <t>TCP/WS/BFCP 'TCP/WSS/BFCP'. </t>
        <ul empty="true" spacing="normal">
          <li>'TCP/WS/BFCP' is used when BFCP runs on top of WS, which in
          turn runs on top of TCP.</t>

          <t>TCP/WSS/BFCP TCP.</li>
          <li>'TCP/WSS/BFCP' is used when BFCP runs on top of WSS, secure WebSocket (WSS), which
          in turn runs on top of TLS and TCP.</t>
        </list></t> TCP.</li>
        <t>The port "port" field is set following the rules in Section 3
      <xref target="RFC8856" section="4" sectionFormat="bare" format="default"/> and Section 8.1
      <xref target="RFC8856" section="7.1" sectionFormat="bare" format="default"/>
      of <xref
      target="I-D.ietf-bfcpbis-rfc4583bis"/>. target="RFC8856" format="default"/>. Depending on the value
      of the SDP 'setup' attribute defined in <xref target="RFC4145"/>, target="RFC4145" format="default"/>,
      the port "port" field contains the port to which the remote endpoint will
      direct BFCP messages messages, or it is irrelevant (i.e., the endpoint will initiate the connection
      towards the remote endpoint) and should be set to a value of 9, '9',
      which is the discard port. Connection The 'connection' attribute and port MUST <bcp14>MUST</bcp14>
      follow the rules of <xref target="RFC4145"/></t> target="RFC4145" format="default"/>.</t>
        <t>While this document recommends the use of secure WebSockets (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 anchor="attribute"
          title="SDP numbered="true" toc="default">
        <name>SDP Media Attributes"> Attributes</name>
        <t><xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/> target="RFC8124" format="default"/> defines a new SDP attribute
      to indicate the connection Uniform Resource Identifier (URI) for the WebSocket Client. client.
      The SDP attribute 'websocket-uri' defined in Section 3 of <xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/>
      MUST target="RFC8124" section="3" sectionFormat="of" format="default"/>
      <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 in Section 4 of <xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/>
      MUST target="RFC8124" section="4" sectionFormat="of" format="default"/>
      <bcp14>MUST</bcp14> be followed.</t>
    <section title="SDP numbered="true" toc="default">
      <name>SDP Offer/Answer Procedures"> Procedures</name>
      <section anchor="general" title="General"> numbered="true" toc="default">

        <t> 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 and MUST <bcp14>MUST</bcp14> assign either TCP/WSS/BFCP a 'TCP/WSS/BFCP' or TCP/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> add an "a=websocket-uri" a 'websocket-uri'
      attribute in the media section depending on whether it wishes to use WebSocket or secure WebSocket. This new
      attribute MUST <bcp14>MUST</bcp14> follow the syntax defined in <xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/>. target="RFC8124" format="default"/>. Additionally,
      the SDP Offer/Answer offer/answer procedures defined in Section 4 of <xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/> MUST target="RFC8124" section="4" sectionFormat="of" format="default"/> <bcp14>MUST</bcp14>
      be followed for the "m=" line associated with a BFCP-over-WebSocket media stream.</t>
      <section anchor="example"  title="Example numbered="true" toc="default">
        <name>Example Usage of 'websocket-uri' SDP Attribute"> Attribute</name>
        <t>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 of TCP/WSS/BFCP * 'TCP/WSS/BFCP', indicating that the offerer wishes to use secure
WebSocket as a transport for the media stream.</t>
          <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"/>).</t>

        <sourcecode type="sdp"><![CDATA[
Offer (browser):
m=application 9 TCP/WSS/BFCP *
m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31

Answer (server):
m=application 50000 TCP/WSS/BFCP *
a=floorid:1 m-stream:10
a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0
m=video 50004 RTP/AVP 31
          It is possible that an endpoint (e.g., a browser) sends an offerless INVITE to the server.
          In such cases cases, the server will act as SDP offerer. The server MUST <bcp14>MUST</bcp14> assign the SDP "setup" 'setup'
          attribute with a value of "passive". 'passive'. The server MUST <bcp14>MUST</bcp14> have an "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 attribute MUST <bcp14>MUST</bcp14> follow the syntax defined in Section 3 of
          <xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/> . target="RFC8124" section="3" sectionFormat="of" format="default"/>.
          For BFCP application, the "proto"  value in the "m=" line MUST <bcp14>MUST</bcp14> be TCP/WSS/BFCP 'TCP/WSS/BFCP' if WebSocket is over TLS,
          else it MUST <bcp14>MUST</bcp14> be TCP/WS/BFCP. 'TCP/WS/BFCP'.
    <section anchor="authentication" title="Authentication">
      <t>Section 9 of <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> numbered="true" toc="default">
      <t><xref target="RFC8855" section="9" sectionFormat="of" format="default"/>
      states that BFCP clients and floor control servers SHOULD <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 <xref target="WS-API"/>, target="WS-API" format="default"/>, so it is
      <bcp14>RECOMMENDED</bcp14> that standard Web-based web-based methods for client and
      server authentication are used, as follows.</t>
      <t>When a BFCP WebSocket client connects to a BFCP WebSocket
      server, it SHOULD <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, Secure secure WebSocket (WSS) MUST <bcp14>MUST</bcp14> be used,
      and the floor control server MUST <bcp14>MUST</bcp14> authenticate the client. The WebSocket client
      <bcp14>MUST</bcp14> follow the procedures in <xref target="RFC7525"/> target="RFC7525" format="default"/> 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' value MUST <bcp14>MUST</bcp14> contain a hostname.
      The verification process does not use a=fingerprint.</t> "a=fingerprint".</t>
      <t>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 in Section 13.8 of <xref
      target="I-D.ietf-bfcpbis-rfc4582bis"/>, target="RFC8855" section="13.8" sectionFormat="of" format="default"/>,
      with an Error error code with a value of 9 (use (Use TLS).</t>
      <t>Prior to sending BFCP requests, a BFCP WebSocket client
      connects to a BFCP WebSocket server and performs the connection
      handshake. As described in <xref
      target="the_websocket_protocol"/> target="handshake" format="default"/>, the handshake procedure
      involves a an HTTP GET method request from the client and a
      response from the server including an HTTP 101 status code.</t>
      <t>In order to authorize the WebSocket connection, the BFCP
      WebSocket server SHOULD <bcp14>SHOULD</bcp14> inspect any cookie header fields
      <xref target="RFC6265"/>
      headers target="RFC6265" format="default"/> present in the HTTP GET request. For many web
      applications, 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 WebSocket Server could request HTTP
      authentication by replying to the Client's GET method request
      with a HTTP 401 status code. The WebSocket protocol <xref
      target="RFC6455"/> covers this usage in Section 4.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
          <xref target="RFC7230"/> procedures, in particular the
          client might perform could request HTTP
      authentication if it receives by replying to the client's GET method request
      with an HTTP 401 status code.</t>
          <t>If code. The WebSocket protocol <xref target="RFC6455" format="default"/>
      covers this usage in Section <xref target="RFC6455" section="4.1" sectionFormat="bare" format="default"/>:
      <ul empty="true" spacing="normal">
        <li>If the status code received from the server is not 101,
          the WebSocket client stack handles the response per HTTP
          <xref target="RFC7230"/> procedures, target="RFC7230" format="default"/> procedures; in particular particular, the
          client might perform authentication if it receives an 401
          status code.  The WebSocket clients are vulnerable to the attacks
         of basic authentication (mentioned in Section 4 of <xref target="RFC7617"/>) target="RFC7617" section="4" sectionFormat="of" format="default"/>) and
        digest authentication (mentioned in Section 5 of <xref target="RFC7616"/>]). target="RFC7616" section="5" sectionFormat="of" format="default"/>). To overcome
        some of these weakness, the weaknesses, WebSocket clients for example can use the
        HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in
        <xref target="RFC7486"/>.</t>
        </list></t> target="RFC7486" format="default"/>, for example.</li>
    <section anchor="security_considerations"
             title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Considerations from <xref
      target="I-D.ietf-bfcpbis-rfc4582bis"/>, target="RFC8855" format="default"/>,
      target="I-D.ietf-bfcpbis-rfc4583bis"/> target="RFC8856" format="default"/>, and RFC5018 <xref
      target="RFC5018"/> target="RFC5018" format="default"/> apply.</t>
      <t>BFCP relies on lower-layer security mechanisms to provide
      replay and integrity protection and confidentiality. It is
      <bcp14>RECOMMENDED</bcp14> that the BFCP traffic transported over a WebSocket
      be protected by using a secure Secure WebSocket
      connection (using TLS <xref target="RFC5246"/> target="RFC8446" format="default"/> over TCP). The security
      considerations in <xref target="RFC6455"/> target="RFC6455" format="default"/> 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.
      <xref target="authentication"/> target="authentication" format="default"/> describes the authentication procedures between client
      and server.</t>
      <t>When using BFCP over websockets, WebSocket, the security mechanisms defined in
    <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> target="RFC8855" format="default"/> are not used. Instead, the
    application is required to build and rely on the security mechanisms in <xref target="RFC6455"/>.</t> target="RFC6455" format="default"/>.</t>
      <t>The rest of this section analyses the threats described in Section 14 of
      <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> target="RFC8855" section="14" sectionFormat="of" format="default"/> when WebSocket is used as a transport
      protocol for BFCP.</t>

      <t>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 server's
      certificate. The floor control BFCP WebSocket client MUST <bcp14>MUST</bcp14> follow the
      procedures in <xref target="RFC7525"/> target="RFC7525" format="default"/> (including hostname verification as per
      Section 6.1 in
      <xref target="RFC7525"/>) target="RFC7525" section="6.1" sectionFormat="of" format="default"/>) while setting up a TLS connection with floor
      control webSocket WebSocket server.</t>
      <t>An attacker attempting to impersonate a floor control client is avoided by
        having servers accept BFCP messages over WSS only. As described in
        Section 10.5 of
        <xref target="RFC6455"/> target="RFC6455" section="10.5" sectionFormat="of" format="default"/> the floor control server can use
        any client authentication mechanism and follow the steps in <xref target="authentication"/> target="authentication" format="default"/>
        of this document.</t>
      <t>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 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 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 using
   BFCP protocol directly, applications need to have a way to
   control the websocket WebSocket libraries to use encryption algorithms specified in
   Section 7 of
   <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> . target="RFC8855" section="7" sectionFormat="of" format="default"/>. Since the
   WebSocket API <xref target="WS-API"/> target="WS-API" format="default"/> 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 anchor="iana_considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="Registration numbered="true" toc="default">
        <name>Registration of the WebSocket BFCP Sub-Protocol">
        <t>This specification requests IANA to register Subprotocol</name>
        <t>IANA has registered the WebSocket
        BFCP sub-protocol subprotocol under the "WebSocket Subprotocol Name"
        Registry with the following data:</t>

        <t><list style="hanging">
            <t hangText="Subprotocol Identifier:">BFCP</t>

            <t hangText="Subprotocol Name Registry"
        as follows:</t>
        <dl newline="false" spacing="normal">
          <dt>Subprotocol Identifier:</dt>
          <dt>Subprotocol Common Name:">WebSocket Name:</dt>
          <dd>WebSocket Transport
            for BFCP (Binary Floor Control Protocol)</t>

            <t hangText="Subprotocol Definition:">RFC&rfc.number;</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>Subprotocol Definition:</dt>
          <dd>RFC 8857</dd>
      <section title="Registration numbered="true" toc="default">
        <name>Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP 'proto' Values"> "proto" Values</name>
        <t>This document defines two new values for the SDP 'proto'
        field under "proto"
        subregistry within the Session "Session Description Protocol (SDP) Parameters Parameters"
        registry. The resulting entries are shown in <xref
        target="IANA_SDP_proto"/> below:<figure
            anchor="IANA_SDP_proto" align="center"
            title="Values target="IANA_SDP_proto" format="default"/>:</t>

<table anchor="IANA_SDP_proto">
   <name>Values for the SDP 'proto' Field">
                 Value                    Reference
               ----------                -----------
              TCP/WS/BFCP                 RFCXXXX;
              TCP/WSS/BFCP                RFCXXXX;

          <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>
         <td>RFC 8857</td>
         <td>RFC 8857</td>


        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4145.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5018.xml"/>

<reference anchor="RFC8855" target="https://www.rfc-editor.org/info/rfc8855">

    <title>The Binary Floor Control Protocol (BFCP)</title>

    <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
      <organization />

    <author initials="K." surname="Drage" fullname="Keith Drage">
      <organization />

    <author initials="T." surname="Kristensen" fullname="Tom Kristensen">
      <organization />

    <author initials="J." surname="Ott" fullname="Jörg Ott">
      <organization />

    <author initials="C." surname="Eckel" fullname="Charles Eckel">
      <organization />

    <date month="May" year="2020" />
  <seriesInfo name="RFC" value="8855" />
  <seriesInfo name="DOI" value="10.17487/RFC8855"/>


        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>

<reference anchor='RFC8856' target="https://www.rfc-editor.org/info/rfc8856">
<title>Session Description Protocol (SDP) Format for Binary Floor Control
Protocol (BFCP) Streams</title>

<author initials='G' surname='Camarillo' fullname='Gonzalo Camarillo'>
    <organization />

<author initials='T' surname='Kristensen' fullname='Tom Kristensen'>
    <organization />

<author initials='C.' surname='Holmberg' fullname='Christer Holmberg'>
    <organization />

<date month='May' year='2020' />
<seriesInfo name="RFC" value="8856"/>
<seriesInfo name="DOI" value="10.17487/RFC8856"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8124.xml"/>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7616.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7617.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7486.xml"/>

        <reference anchor="WS-API" target="https://www.w3.org/TR/2012/CR-websockets-20120920/">
            <title>The WebSocket API</title>
            <author fullname="Ian Hickson" initials="I." role="editor" surname="Hickson">
          <refcontent>W3C Candidate Recommendation, September 2012</refcontent>
      <section anchor="acknowledgements" title="Acknowledgements"> numbered="false" toc="default">

      <t>The authors want to thank Robert Welbourn, <contact fullname="Robert Welbourn"/> from Acme Packet and Sergio
        <contact fullname="Sergio Garcia Murillo Murillo"/>,
        who made significant contributions to the first draft version of
        this document. This work benefited from the thorough review
        and constructive comments of Charles 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 to Bert 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> Thanks for Spencers Dawkin, Ben Campbell, Kathleen Moriarty, Alexey Melnikov, Jari Arkko and Stephen Farrell to <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>


  <!--  *****BACK MATTER ***** -->

    <!-- 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">







      <?rfc include="reference.I-D.ietf-bfcpbis-sdp-ws-uri"?>


    <references title="Informative References">






      <reference anchor="WS-API">
          <title>The WebSocket API</title>


          <author fullname="Ian Hickson" initials="I." role="editor"
            <organization>Google, Inc.</organization>

          <date month="May" year="2012"/>