rfc8857xml2.original.xml   rfc8857.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc, <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
which is available here: http://xml.resource.org. --> nsus="true" docName="draft-ietf-bfcpbis-bfcp-websocket-15" indexInclude="true" i
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ pr="trust200902" number="8857" prepTime="2021-01-18T22:45:44" scripts="Common,La
<!-- One method to get references from the online citation libraries. tin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclud
There has to be one entity for each item to be referenced. e="true" xml:lang="en">
An alternate method (rfc include) is described in the references. --> <link href="https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket
<!-- Normative References --> -15" rel="prev"/>
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <link href="https://dx.doi.org/10.17487/rfc8857" rel="alternate"/>
.2119.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!-- 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" ?>
<rfc category="std" 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 ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="WebSocket as a Transport for BFCP">The WebSocket Protocol as
if the a Transport for the Binary Floor Control Protocol (BFCP)</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="8857" stream="IETF"/>
<author fullname="Victor Pascual" initials="V." surname="Pascual">
<title abbrev="WebSocket as a Transport for BFCP">The WebSocket <organization showOnFrontPage="true">Nokia</organization>
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 -->
<author fullname="Victor Pascual" initials="V.P."
surname="Pascual">
<organization>Genaker</organization>
<address> <address>
<postal> <postal>
<street/> <city>Barcelona</city>
<code/> <country>Spain</country>
<city>Barcelona</city> </postal>
<region/> <email>victor.pascual_avila@nokia.com</email>
<country>Spain</country>
</postal>
<email>victor.pascual@genaker.net</email>
</address> </address>
</author> </author>
<author fullname="Antón Román" initials="A." surname="Román">
<author fullname="Ant&oacute;n Rom&aacute;n" initials="A.R." <organization showOnFrontPage="true">Quobis</organization>
surname="Rom&aacute;n">
<organization>Quobis</organization>
<address> <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> <email>anton.roman@quobis.com</email>
</address> </address>
</author> </author>
<author fullname="Stéphane Cazeaux" initials="S." surname="Cazeaux">
<author fullname="St&eacute;phane Cazeaux" initials="S.C." <organization showOnFrontPage="true">Orange</organization>
surname="Cazeaux">
<organization>France Telecom Orange</organization>
<address> <address>
<postal>
<street>42 rue des Coutures</street>
<city>Caen</city>
<code>14000</code>
<country>France</country>
</postal>
<email>stephane.cazeaux@orange.com</email> <email>stephane.cazeaux@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Gonzalo Salgueiro" initials="G." surname="Salgueiro">
<author fullname="Gonzalo Salgueiro" initials="G.S." <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</o
surname="Salgueiro"> rganization>
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>7200-12 Kit Creek Road</street> <street>7200-12 Kit Creek Road</street>
<city>Research Triangle Park</city> <city>Research Triangle Park</city>
<region>NC</region> <region>NC</region>
<code>27709</code> <code>27709</code>
<country>US</country> <country>US</country>
</postal> </postal>
<email>gsalguei@cisco.com</email> <email>gsalguei@cisco.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Ravindranath" fullname="Ram Mohan Ravindranat
<author initials="R" surname="Ravindranath" fullname="Ram Mohan Ravindranat h">
h"> <organization abbrev="Cisco" showOnFrontPage="true">Cisco Systems, Inc.</o
<organization abbrev="Cisco">Cisco Systems, Inc.</organiz rganization>
ation> <address>
<address> <postal>
<postal> <extaddr>Cessna Business Park</extaddr>
<street>Cessna Business Park,</street> <extaddr>Kadabeesanahalli Village, Varthur Hobli,</extaddr>
<street>Kadabeesanahalli Village, Varthur <street>Sarjapur-Marathahalli Outer Ring Road</street>
Hobli,</street> <city>Bangalore</city>
<street>Sarjapur-Marathahalli Outer Ring <region>Karnataka</region>
Road</street> <code>560103</code>
<city>Bangalore</city> <country>India</country>
<region>Karnataka</region> </postal>
<code>560103</code> <email>rmohanr@cisco.com</email>
<country>India</country> </address>
</postal> </author>
<email>rmohanr@cisco.com</email> <date month="01" year="2021"/>
</address>
</author>
<date year="2017"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current on
e, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not s
pecified for the
purpose of calculating the expiry date). With drafts it is normally su
fficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>IETF</area> <area>IETF</area>
<workgroup>BFCPBIS Working Group</workgroup> <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>BFCP</keyword>
<keyword>WebSocket</keyword> <keyword>WebSocket</keyword>
<abstract pn="section-abstract">
<!-- Keywords will be incorporated into HTML output <t indent="0" pn="section-abstract-1"> The WebSocket protocol enables two-
files in a meta tag but they have no effect on text or nroff way real-time communication
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t> The WebSocket protocol enables two-way realtime communication
between clients and servers. This document specifies the use of Binary Flo or between clients and servers. This document specifies the use of Binary Flo or
Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliabl e Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliabl e
transport mechanism between BFCP entities in new scenarios. </t> transport mechanism between BFCP entities in new scenarios. </t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This 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="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" 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" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="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 der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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-de
finitions">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" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-the-websocket-protocol">The WebSoc
ket Protocol</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-the-websocket-bfcp-subproto">The W
ebSocket BFCP Subprotocol</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" format="title" sectionFormat="of" target="name-bfcp-encoding">BFCP En
coding</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" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-transport-reliability">Transport R
eliability</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-sdp-considerations">SDP Considerat
ions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-sdp-offer-answer-procedures">SDP O
ffer/Answer Procedures</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" format="title" sectionFormat="of" target="name-example-usage-of-webso
cket-">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" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-authentication">Authentication</xr
ef></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="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" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 deri
vedContent="" 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 deri
vedContent="" format="title" sectionFormat="of" target="name-registration-of-the
-tcp-ws-">Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto" Value
s</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" fo
rmat="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="sectio
n-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 deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">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 deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">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="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
<t>The WebSocket(WS) <xref target="RFC6455"/> protocol enables lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">The WebSocket (WS) protocol <xref target="R
FC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/> enables
two-way message exchange between clients and servers on top of a two-way message exchange between clients and servers on top of a
persistent TCP connection, optionally secured with Transport Layer Securit y (TLS) persistent TCP connection, optionally secured with Transport Layer Securit y (TLS)
<xref target="RFC5246"/>. The initial protocol handshake makes use of <xref target="RFC8446" format="default" sectionFormat="of" derivedContent=
Hypertext Transfer Protocol (HTTP) <xref target="RFC7230"/> semantics, all "RFC8446"/>. The initial protocol handshake makes use of
owing the WebSocket Hypertext Transfer Protocol (HTTP) <xref target="RFC7230" format="default"
sectionFormat="of" derivedContent="RFC7230"/> semantics, allowing the WebSocket
protocol to reuse existing HTTP infrastructure.</t> protocol to reuse existing HTTP infrastructure.</t>
<t indent="0" pn="section-1-2">The Binary Floor Control Protocol (BFCP) is
<t>The Binary Floor Control Protocol (BFCP) is a protocol to a protocol to
coordinate access to shared resources in a conference. It is coordinate access to shared resources in a conference. It is
defined in <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> and is defined in <xref target="RFC8855" format="default" sectionFormat="of" deri vedContent="RFC8855"/> and is
used between floor participants and floor control servers, and used between floor participants and floor control servers, and
between floor chairs (i.e., moderators) and floor control between floor chairs (i.e., moderators) and floor control
servers.</t> servers.</t>
<t indent="0" pn="section-1-3">Modern web browsers include a WebSocket cli
<t>Modern web browsers include a WebSocket client stack ent stack
complying with the WebSocket API <xref target="WS-API"/> as complying with the WebSocket API <xref target="WS-API" format="default" se
ctionFormat="of" derivedContent="WS-API"/> as
specified by the W3C. It is expected that other client specified by the W3C. It is expected that other client
applications (those running in personal computers and devices applications (those running in personal computers and devices
such as smartphones) will also make a WebSocket client stack such as smartphones) will also make a WebSocket client stack
available. This document extends the applicability of available. This document extends the applicability of
<xref target="I-D.ietf-bfcpbis-rfc4582bis"/> and <xref target="RFC8855" format="default" sectionFormat="of" derivedContent=
<xref target="I-D.ietf-bfcpbis-rfc4583bis"/> to enable the "RFC8855"/> and
<xref target="RFC8856" format="default" sectionFormat="of" derivedContent=
"RFC8856"/> to enable the
usage of BFCP in these scenarios.</t> usage of BFCP in these scenarios.</t>
<t indent="0" pn="section-1-4">The transport over which BFCP entities exch
<t>The transport over which BFCP entities exchange messages ange messages
depends on how the clients obtain information to contact the depends on how the clients obtain information to contact the
floor control server (e.g. using an Session Description Protocol (SDP) floor control server (e.g., using a Session Description Protocol (SDP)
offer/answer exchange per <xref target="I-D.ietf-bfcpbis-rfc4583bis"/> or offer/answer exchange per <xref target="RFC8856" format="default" sectionF
the ormat="of" derivedContent="RFC8856"/> or the
procedure described in RFC5018 <xref target="RFC5018"/>). procedure described in RFC 5018 <xref target="RFC5018" format="default" se
<xref target="I-D.ietf-bfcpbis-rfc4582bis"/> defines two transports ctionFormat="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 for BFCP: TCP and UDP. This specification defines a new
WebSocket sub-protocol (as defined in Section 1.9 in <xref WebSocket subprotocol (as defined in
target="RFC6455"/>) for transporting BFCP messages between a <xref target="RFC6455" section="1.9" sectionFormat="of" format="default" d
WebSocket client and server. This sub-protocol provides a reliable and bou erivedLink="https://rfc-editor.org/rfc/rfc6455#section-1.9" derivedContent="RFC6
ndary 455"/>) for transporting BFCP messages between a
preserving transport for BFCP when run on top of TCP. Since WebSocket prov WebSocket client and server. This subprotocol provides a reliable and
ides boundary-preserving transport for BFCP when run on top of TCP. Since WebSo
a reliable transport, the extensions defined in <xref cket provides
target="I-D.ietf-bfcpbis-rfc4582bis"/> for sending BFCP over unreliabl a reliable transport, the extensions defined in <xref target="RFC8855" for
e mat="default" sectionFormat="of" derivedContent="RFC8855"/> for sending BFCP ove
r unreliable
transports are not applicable. </t> transports are not applicable. </t>
</section> </section>
<section anchor="terminology" numbered="true" toc="include" removeInRFC="fal
<section anchor="terminology" title="Terminology"> se" pn="section-2">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name slugifiedName="name-terminology">Terminology</name>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
"OPTIONAL" in this document are to be interpreted as described 4>MUST NOT</bcp14>",
in <xref target="RFC2119"/>.</t> "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp1
4>",
<section anchor="definitions" title="Definitions"> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED<
<t><list hangIndent="6" style="hanging"> /bcp14>",
<t hangText="BFCP WebSocket Client:">Any BFCP entity capable "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTION
AL</bcp14>"
in this document are to be interpreted as described in BCP 14
<xref target="RFC2119" format="default" sectionFormat="of" derivedContent=
"RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedCo
ntent="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
<section anchor="definitions" numbered="true" toc="include" removeInRFC="f
alse" 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 of opening outbound connections to WebSocket servers and
communicating using the WebSocket BFCP sub-protocol as communicating using the WebSocket BFCP subprotocol as
defined by this document.</t> defined by this document.</dd>
<dt pn="section-2.1-1.3">BFCP WebSocket Server:</dt>
<t hangText="BFCP WebSocket Server:">Any BFCP entity capable <dd pn="section-2.1-1.4">Any BFCP entity capable
of listening for inbound connections from WebSocket of listening for inbound connections from WebSocket
clients and communicating using the WebSocket BFCP clients and communicating using the WebSocket BFCP
sub-protocol as defined by this document.</t> subprotocol as defined by this document.</dd>
</list></t> </dl>
</section> </section>
</section> </section>
<section anchor="the_websocket_protocol" numbered="true" toc="include" remov
<section anchor="the_websocket_protocol" eInRFC="false" pn="section-3">
title="The WebSocket Protocol"> <name slugifiedName="name-the-websocket-protocol">The WebSocket Protocol</
<t>The WebSocket protocol <xref target="RFC6455"/> is a name>
transport layer on top of TCP (optionally secured with TLS <xref <t indent="0" pn="section-3-1">The WebSocket protocol <xref target="RFC645
target="RFC5246"/>) in which both client and server exchange 5" format="default" sectionFormat="of" derivedContent="RFC6455"/> is a
transport layer on top of TCP (optionally secured with
TLS <xref target="RFC8446" format="default" sectionFormat="of" derivedCont
ent="RFC8446"/>) in which both client and server exchange
message units in both directions. The protocol defines a message units in both directions. The protocol defines a
connection handshake, WebSocket sub-protocol and extensions connection handshake, WebSocket subprotocol and extensions
negotiation, a frame format for sending application and control negotiation, a frame format for sending application and control
data, a masking mechanism, and status codes for indicating data, a masking mechanism, and status codes for indicating
disconnection causes.</t> disconnection causes.</t>
<t indent="0" pn="section-3-2">The WebSocket connection handshake is based
<t>The WebSocket connection handshake is based on HTTP <xref on
target="RFC7230"/> and utilizes the HTTP GET method with an HTTP <xref target="RFC7230" format="default" sectionFormat="of" derivedCon
"Upgrade" request. This is sent by the client and then answered tent="RFC7230"/> and utilizes the HTTP GET method with an
Upgrade header field. This is sent by the client and then answered
by the server (if the negotiation succeeded) with an HTTP 101 by the server (if the negotiation succeeded) with an HTTP 101
status code. Once the handshake is completed the connection status code. Once the handshake is completed, the connection
upgrades from HTTP to the WebSocket protocol. This handshake upgrades from HTTP to the WebSocket protocol. This handshake
procedure is designed to reuse the existing HTTP infrastructure. procedure is designed to reuse the existing HTTP infrastructure.
During the connection handshake, client and server agree on the During the connection handshake, the client and server agree on the
application protocol to use on top of the WebSocket transport. application protocol to use on top of the WebSocket transport.
Such an application protocol (also known as a "WebSocket Such an application protocol (also known as a "WebSocket
sub-protocol") defines the format and semantics of the messages subprotocol") defines the format and semantics of the messages
exchanged by the endpoints. This could be a custom protocol or a exchanged by the endpoints. This could be a custom protocol or a
standardized one (as the WebSocket BFCP sub-protocol defined in standardized one (as the WebSocket BFCP subprotocol defined in
this document). Once the HTTP 101 response is processed both this document). Once the HTTP 101 response is processed, both
client and server reuse the underlying TCP connection for the client and server reuse the underlying TCP connection for
sending WebSocket messages and control frames to each other. sending WebSocket messages and control frames to each other.
Unlike plain HTTP, this connection is persistent and can be used Unlike plain HTTP, this connection is persistent and can be used
for multiple message exchanges.</t> for multiple message exchanges.</t>
<t indent="0" pn="section-3-3">The WebSocket protocol defines message unit
<t>The WebSocket protocol defines message units to be used by s to be used by
applications for the exchange of data, so it provides a message applications for the exchange of data, so it provides a message
boundary-preserving transport layer.</t> boundary-preserving transport layer.</t>
</section> </section>
<section anchor="the_websocket_bfcp_subprotocol" numbered="true" toc="includ
<section anchor="the_websocket_bfcp_subprotocol" e" removeInRFC="false" pn="section-4">
title="The WebSocket BFCP Sub-Protocol"> <name slugifiedName="name-the-websocket-bfcp-subproto">The WebSocket BFCP
<t>The term WebSocket sub-protocol refers to an Subprotocol</name>
<t indent="0" pn="section-4-1">The term WebSocket subprotocol refers to an
application-level protocol layered on top of a WebSocket application-level protocol layered on top of a WebSocket
connection. This document specifies the WebSocket BFCP connection. This document specifies the WebSocket BFCP
sub-protocol for carrying BFCP messages over a WebSocket subprotocol for carrying BFCP messages over a WebSocket
connection.</t> connection.</t>
<section anchor="handshake" numbered="true" toc="include" removeInRFC="fal
<section anchor="handshake" title="Handshake"> se" pn="section-4.1">
<t>The BFCP WebSocket Client and BFCP WebSocket Server <name slugifiedName="name-handshake">Handshake</name>
negotiate usage of the WebSocket BFCP sub-protocol during the <t indent="0" pn="section-4.1-1">The BFCP WebSocket client and BFCP WebS
WebSocket handshake procedure as defined in Section 1.3 of ocket server
<xref target="RFC6455"/>. The Client MUST include the value negotiate usage of the WebSocket BFCP subprotocol during the
"BFCP" in the Sec-WebSocket-Protocol header in its handshake WebSocket handshake procedure as defined in
request. The 101 reply from the Server MUST contain "BFCP" in <xref target="RFC6455" section="1.3" sectionFormat="of" format="default"
its corresponding Sec-WebSocket-Protocol header.</t> derivedLink="https://rfc-editor.org/rfc/rfc6455#section-1.3" derivedContent="RF
C6455"/>.
<t>Below is an example of a WebSocket handshake in which the The client <bcp14>MUST</bcp14> include the value
Client requests the WebSocket BFCP sub-protocol support from "bfcp" in the Sec-WebSocket-Protocol header field in its handshake
the Server:<figure> request. The 101 reply from the server <bcp14>MUST</bcp14> contain "bfcp
<artwork><![CDATA[ " in
its corresponding Sec-WebSocket-Protocol header field.</t>
<t indent="0" pn="section-4.1-2">Below is an example of a WebSocket hand
shake in which the
client requests the WebSocket BFCP subprotocol support from
the server:</t>
<artwork name="" type="" align="left" alt="" pn="section-4.1-3">
GET / HTTP/1.1 GET / HTTP/1.1
Host: bfcp-ws.example.com Host: bfcp-ws.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com Origin: http://www.example.com
Sec-WebSocket-Protocol: BFCP Sec-WebSocket-Protocol: bfcp
Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 13
]]></artwork> </artwork>
</figure></t> <t indent="0" pn="section-4.1-4">The handshake response from the server
accepting the
<t>The handshake response from the Server accepting the WebSocket BFCP subprotocol would look as follows:</t>
WebSocket BFCP sub-protocol would look as follows:<figure> <artwork name="" type="" align="left" alt="" pn="section-4.1-5">
<artwork><![CDATA[
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: BFCP Sec-WebSocket-Protocol: bfcp
]]></artwork> </artwork>
</figure></t> <t indent="0" pn="section-4.1-6">Once the negotiation has been completed
, the WebSocket
<t>Once the negotiation has been completed, the WebSocket
connection is established and can be used for the transport of connection is established and can be used for the transport of
BFCP messages. </t> BFCP messages. </t>
</section> </section>
<section anchor="bfcp_encoding" numbered="true" toc="include" removeInRFC=
<section anchor="bfcp_encoding" title="BFCP Encoding"> "false" pn="section-4.2">
<t>BFCP messages use a TLV (Type-Length-Value) binary <name slugifiedName="name-bfcp-encoding">BFCP Encoding</name>
encoding, therefore BFCP WebSocket Clients and BFCP WebSocket <t indent="0" pn="section-4.2-1">BFCP messages use a TLV (Type-Length-Va
Servers MUST be transported in unfragmented binary WebSocket lue) binary
frames (FIN:1,opcode:%x2) to exchange BFCP messages. The encoding, therefore BFCP WebSocket clients and BFCP WebSocket
WebSocket frame data MUST be a valid BCFP message, so the servers <bcp14>MUST</bcp14> be transported in unfragmented binary WebSoc
length of the payload of the WebSocket frame MUST be lower ket
than the maximum size allowed (2^16 +12 bytes) for a BCFP frames (FIN: 1, opcode: %x2) to exchange BFCP messages. The
message as described in <xref WebSocket frame data <bcp14>MUST</bcp14> be a valid BFCP message, so the
target="I-D.ietf-bfcpbis-rfc4582bis"/>. In addition, the length of the payload of the WebSocket frame <bcp14>MUST</bcp14> be lowe
encoding rules for reliable protocols defined in <xref r
target="I-D.ietf-bfcpbis-rfc4582bis"/> MUST be followed.</t> than the maximum size allowed (2<sup>16</sup> +12 bytes) for a BFCP
<t>While this specification assumes that BFCP encoding is only TLV binar message as described in <xref target="RFC8855" format="default" sectionF
y, ormat="of" derivedContent="RFC8855"/>. In addition, the
future documents may define other mechanisms like JSON serialization. encoding rules for reliable protocols defined in <xref target="RFC8855"
if encoding changes a new subprotocol identifier would need to be selec format="default" sectionFormat="of" derivedContent="RFC8855"/>
ted.</t> <bcp14>MUST</bcp14> be followed.</t>
<t>Each BFCP message MUST be carried within a single WebSocket <t indent="0" pn="section-4.2-2">While this specification assumes that B
message, and a WebSocket message MUST NOT contain more than one FCP encoding is only TLV binary,
future documents may define other mechanisms, like JSON serialization.
If encoding changes, a new subprotocol identifier would need to be sele
cted.</t>
<t indent="0" pn="section-4.2-3">Each BFCP message <bcp14>MUST</bcp14> b
e carried within a single WebSocket
message, and a WebSocket message <bcp14>MUST NOT</bcp14> contain more than
one
BFCP message.</t> BFCP message.</t>
</section> </section>
</section> </section>
<section anchor="bfcp_websocket_transport" numbered="true" toc="include" rem
<section anchor="bfcp_websocket_transport" oveInRFC="false" pn="section-5">
title="Transport Reliability"> <name slugifiedName="name-transport-reliability">Transport Reliability</na
<t>WebSocket <xref target="RFC6455"/> provides a reliable transport and me>
therefore the BFCP WebSocket sub-protocol defined by this <t indent="0" pn="section-5-1">The WebSocket protocol <xref target="RFC645
5" format="default" sectionFormat="of" derivedContent="RFC6455"/> provides a rel
iable transport, and
therefore the BFCP WebSocket subprotocol defined by this
document also provides reliable BFCP transport. Thus, client and server document also provides reliable BFCP transport. Thus, client and server
transactions using WebSocket for transport MUST follow the transactions using the WebSocket protocol for transport <bcp14>MUST</bcp14
procedures for reliable transports as defined in <xref > follow the
target="I-D.ietf-bfcpbis-rfc4582bis"/> and <xref procedures for reliable transports as defined in <xref target="RFC8855" fo
target="I-D.ietf-bfcpbis-rfc4583bis"/>.</t> rmat="default" sectionFormat="of" derivedContent="RFC8855"/>
and <xref target="RFC8856" format="default" sectionFormat="of" derivedCont
<t>BFCP WebSocket clients cannot receive incoming WebSocket ent="RFC8856"/>.</t>
<t indent="0" pn="section-5-2">BFCP WebSocket clients cannot receive incom
ing WebSocket
connections initiated by any other peer. This means that a BFCP connections initiated by any other peer. This means that a BFCP
WebSocket client MUST actively initiate a connection towards a WebSocket client <bcp14>MUST</bcp14> actively initiate a connection toward
BFCP WebSocket server. The BFCP server is a will have a globally routable s a
address BFCP WebSocket server. The BFCP server will have a globally routable addre
and thus does not require ICE as clients always initiate connections to it ss
. </t> and thus does not require ICE, as clients always initiate connections to i
t. </t>
</section> </section>
<section anchor="sdp_con" numbered="true" toc="include" removeInRFC="false"
<section anchor="sdp_con" pn="section-6">
title="SDP Considerations"> <name slugifiedName="name-sdp-considerations">SDP Considerations</name>
<section anchor="updates_to_rfc_4583bis" numbered="true" toc="include" rem
<section anchor="updates_to_rfc_4583bis" oveInRFC="false" pn="section-6.1">
title="Transport Negotiation"> <name slugifiedName="name-transport-negotiation">Transport Negotiation</
<t>Rules to generate an 'm' line for a BFCP stream are described name>
in <xref target="I-D.ietf-bfcpbis-rfc4583bis"/>, Section 3</t> <t indent="0" pn="section-6.1-1">Rules to generate an "m=" line for a BF
CP stream are described
<t>New values are defined for the transport field: TCP/WS/BFCP in <xref target="RFC8856" section="4" sectionFormat="comma" format="defaul
and TCP/WSS/BFCP. <list style="empty"> t" derivedLink="https://rfc-editor.org/rfc/rfc8856#section-4" derivedContent="RF
<t>TCP/WS/BFCP is used when BFCP runs on top of WS, which in C8856"/>.</t>
turn runs on top of TCP.</t> <t indent="0" pn="section-6.1-2">New values are defined for the SDP "pro
to" field: 'TCP/WS/BFCP'
<t>TCP/WSS/BFCP is used when BFCP runs on top of WSS, which and 'TCP/WSS/BFCP'. </t>
in turn runs on top of TLS and TCP.</t> <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.
</list></t> 1-3">
<li pn="section-6.1-3.1">'TCP/WS/BFCP' is used when BFCP runs on top o
<t>The port field is set following the rules in Section 3 and Section 8.1 f WS, which in
of <xref turn runs on top of TCP.</li>
target="I-D.ietf-bfcpbis-rfc4583bis"/>. Depending on the value <li pn="section-6.1-3.2">'TCP/WSS/BFCP' is used when BFCP runs on top
of the SDP 'setup' attribute defined in <xref target="RFC4145"/>, of secure WebSocket (WSS), which
the port field contains the port to which the remote endpoint will in turn runs on top of TLS and TCP.</li>
direct BFCP messages or is irrelevant (i.e., the endpoint will initiate th </ul>
e connection <t indent="0" pn="section-6.1-4">The "port" field is set following the r
towards the remote endpoint) and should be set to a value of 9, ules in Section
which is the discard port. Connection attribute and port MUST <xref target="RFC8856" section="4" sectionFormat="bare" format="default" d
follow the rules of <xref target="RFC4145"/></t> erivedLink="https://rfc-editor.org/rfc/rfc8856#section-4" derivedContent="RFC885
6"/> and Section
<t>While this document recommends the use of secure WebSockets (i.e.TCP/WS <xref target="RFC8856" section="7.1" sectionFormat="bare" format="default"
S) derivedLink="https://rfc-editor.org/rfc/rfc8856#section-7.1" derivedContent="RF
C8856"/>
of <xref target="RFC8856" format="default" sectionFormat="of" derivedConte
nt="RFC8856"/>. Depending on the value
of the SDP 'setup' attribute defined in <xref target="RFC4145" format="def
ault" sectionFormat="of" derivedContent="RFC4145"/>,
the "port" field contains the port to which the remote endpoint will
direct BFCP messages, or it is irrelevant (i.e., the endpoint will initiat
e the connection
towards the remote endpoint) and should be set to a value of '9',
which is the discard port. The 'connection' attribute and port <bcp14>MUST
</bcp14>
follow the rules of <xref target="RFC4145" format="default" sectionFormat=
"of" derivedContent="RFC4145"/>.</t>
<t indent="0" pn="section-6.1-5">While this document recommends the use
of secure WebSocket (i.e., TCP/WSS)
for security reasons, TCP/WS is also permitted so as to achieve maximum for security reasons, TCP/WS is also permitted so as to achieve maximum
compatibility among clients.</t> compatibility among clients.</t>
</section> </section>
<section anchor="attribute" numbered="true" toc="include" removeInRFC="fal
<section anchor="attribute" se" pn="section-6.2">
title="SDP Media Attributes"> <name slugifiedName="name-sdp-media-attributes">SDP Media Attributes</na
<t><xref target="I-D.ietf-bfcpbis-sdp-ws-uri"/> defines a new SDP attribu me>
te <t indent="0" pn="section-6.2-1"><xref target="RFC8124" format="default"
to indicate the connection Uniform Resource Identifier (URI) for the WebSo sectionFormat="of" derivedContent="RFC8124"/> defines a new SDP attribute
cket Client. to indicate the connection Uniform Resource Identifier (URI) for the WebSo
The SDP attribute 'websocket-uri' defined in Section 3 of <xref target="I- cket client.
D.ietf-bfcpbis-sdp-ws-uri"/> The SDP attribute 'websocket-uri' defined in <xref target="RFC8124" sectio
MUST be used when BFCP runs on top of WS or WSS. n="3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rf
c/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, 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-sd the procedures mentioned in <xref target="RFC8124" section="4" sectionForm
p-ws-uri"/> at="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8124#section
MUST be followed.</t> -4" derivedContent="RFC8124"/>
<bcp14>MUST</bcp14> be followed.</t>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
</section> <name slugifiedName="name-sdp-offer-answer-procedures">SDP Offer/Answer Pr
ocedures</name>
<section title="SDP Offer/Answer Procedures"> <section anchor="general" numbered="true" toc="include" removeInRFC="false
<section anchor="general" title="General"> " pn="section-7.1">
<t> An endpoint (i.e., both the offerer and the answerer) MUST create an SD <name slugifiedName="name-general">General</name>
P media description ("m=" line) <t indent="0" pn="section-7.1-1"> An endpoint (i.e., both the offerer an
for each BFCP-over-WebSocket media stream and MUST assign either TCP/WSS/B d the answerer) <bcp14>MUST</bcp14> create an SDP media description ("m=" line)
FCP or TCP/WS/BFCP value to the for each BFCP-over-WebSocket media stream and <bcp14>MUST</bcp14> assign e
ither a 'TCP/WSS/BFCP' or 'TCP/WS/BFCP' value to the
"proto" field of the "m=" line depending on whether the endpoint wishes to use secure WebSocket or WebSocket. "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 answere r, MUST add an "a=websocket-uri" Furthermore, the server side, which could be either the offerer or answere r, <bcp14>MUST</bcp14> add a 'websocket-uri'
attribute in the media section depending on whether it wishes to use WebSo cket or secure WebSocket. This new attribute in the media section depending on whether it wishes to use WebSo cket or secure WebSocket. This new
attribute MUST follow the syntax defined in <xref target="I-D.ietf-bfcpbis attribute <bcp14>MUST</bcp14> follow the syntax defined in <xref target="R
-sdp-ws-uri"/>. Additionally, FC8124" format="default" sectionFormat="of" derivedContent="RFC8124"/>. Addition
the SDP Offer/Answer procedures defined in Section 4 of <xref target="I- ally,
D.ietf-bfcpbis-sdp-ws-uri"/> MUST the SDP offer/answer procedures defined in <xref target="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> be followed for the "m=" line associated with a BFCP-over-WebSocket media stream.</t>
</section> </section>
<section anchor="example" title="Example Usage of 'websocket-uri' SDP Attri <section anchor="example" numbered="true" toc="include" removeInRFC="false
bute"> " pn="section-7.2">
<t>The following is an example of an "m=" line for a BFCP connection. In <name slugifiedName="name-example-usage-of-websocket-">Example Usage of
this example, the offerer sends the SDP with the "proto" field having a value o 'websocket-uri' SDP Attribute</name>
f TCP/WSS/BFCP * indicating that the offerer wishes to use secure WebSocket as a <t indent="0" pn="section-7.2-1">The following is an example of an "m="
transport for the media stream.</t> line for a BFCP connection.
<t> In this example, the offerer sends the SDP with the "proto" field having a
<figure> value of 'TCP/WSS/BFCP', indicating that the offerer wishes to use secure
<artwork><![CDATA[ WebSocket as a transport for the media 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" derivedLi
nk="https://rfc-editor.org/rfc/rfc8856#section-4" derivedContent="RFC8856"/>).</
t>
<sourcecode type="sdp" markers="false" pn="section-7.2-2">
Offer (browser): Offer (browser):
m=application 9 TCP/WSS/BFCP * m=application 9 TCP/WSS/BFCP *
a=setup:active a=setup:active
a=connection:new a=connection:new
a=floorctrl:c-only a=floorctrl:c-only
m=audio 55000 RTP/AVP 0 m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31 m=video 55002 RTP/AVP 31
Answer (server): Answer (server):
m=application 50000 TCP/WSS/BFCP * m=application 50000 TCP/WSS/BFCP *
skipping to change at line 488 skipping to change at line 468
a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312 a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312
a=floorctrl:s-only a=floorctrl:s-only
a=confid:4321 a=confid:4321
a=userid:1234 a=userid:1234
a=floorid:1 m-stream:10 a=floorid:1 m-stream:10
a=floorid:2 m-stream:11 a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0 m=audio 50002 RTP/AVP 0
a=label:10 a=label:10
m=video 50004 RTP/AVP 31 m=video 50004 RTP/AVP 31
a=label:11 a=label:11
]]></artwork> </sourcecode>
</figure></t> <t indent="0" pn="section-7.2-3">
<t>
It is possible that an endpoint (e.g., a browser) sends an offerless I NVITE to the server. It is possible that an endpoint (e.g., a browser) sends an offerless I NVITE to the server.
In such cases the server will act as SDP offerer. The server MUST assi In such cases, the server will act as SDP offerer. The server <bcp14>M
gn the SDP "setup" UST</bcp14> assign the SDP 'setup'
attribute with a value of "passive". The server MUST have an "a=websoc attribute with a value of 'passive'. The server <bcp14>MUST</bcp14> ha
ket-uri" attribute ve a 'websocket-uri' attribute
with a "ws-URI" or "wss-URI" value depending on whether the server wis with a 'ws-URI' or 'wss-URI' value depending on whether the server wis
hes to use WebSocket or secure WebSocket. hes to use WebSocket or secure WebSocket.
This attribute MUST follow the syntax defined in Section 3 of <xref t This attribute <bcp14>MUST</bcp14> follow the syntax defined in
arget="I-D.ietf-bfcpbis-sdp-ws-uri"/> . <xref target="RFC8124" section="3" sectionFormat="of" format="default"
For BFCP application, the "proto" value in the "m=" line MUST be TCP/ derivedLink="https://rfc-editor.org/rfc/rfc8124#section-3" derivedContent="RFC8
WSS/BFCP if WebSocket is over TLS, 124"/>.
else it MUST be TCP/WS/BFCP. For BFCP application, the "proto" value in the "m=" line <bcp14>MUST<
/bcp14> be 'TCP/WSS/BFCP' if WebSocket is over TLS,
else it <bcp14>MUST</bcp14> be 'TCP/WS/BFCP'.
</t> </t>
</section>
</section> </section>
</section> <section anchor="authentication" numbered="true" toc="include" removeInRFC="
false" pn="section-8">
<section anchor="authentication" title="Authentication"> <name slugifiedName="name-authentication">Authentication</name>
<t>Section 9 of <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> <t indent="0" pn="section-8-1"><xref target="RFC8855" section="9" sectionF
states that BFCP clients and floor control servers SHOULD ormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8855#sect
ion-9" derivedContent="RFC8855"/>
states that BFCP clients and floor control servers <bcp14>SHOULD</bcp14>
authenticate each other prior to accepting messages, and authenticate each other prior to accepting messages, and
RECOMMENDS that mutual TLS/DTLS authentication be used. However, RECOMMENDS that mutual TLS/DTLS authentication be used. However,
browser-based WebSocket clients have no control over the use of browser-based WebSocket clients have no control over the use of
TLS in the WebSocket API <xref target="WS-API"/>, so it is TLS in the WebSocket API <xref target="WS-API" format="default" sectionFor
RECOMMENDED that standard Web-based methods for client and mat="of" derivedContent="WS-API"/>, so it is
<bcp14>RECOMMENDED</bcp14> that standard web-based methods for client and
server authentication are used, as follows.</t> server authentication are used, as follows.</t>
<t indent="0" pn="section-8-2">When a BFCP WebSocket client connects to a
<t>When a BFCP WebSocket client connects to a BFCP WebSocket BFCP WebSocket
server, it SHOULD use TCP/WSS as its transport. If the signaling server, it <bcp14>SHOULD</bcp14> use TCP/WSS as its transport. If the sign
aling
or control protocol traffic used to set up the conference is authenticated or control protocol traffic used to set up the conference is authenticated
and confidentiality and integrity protected, Secure WebSocket (WSS) MUST b and confidentiality and integrity protected, secure WebSocket (WSS) <bcp14
e used, >MUST</bcp14> be used,
and the floor control server MUST authenticate the client. The WebSocket c and the floor control server <bcp14>MUST</bcp14> authenticate the client.
lient The WebSocket client
MUST follow the procedures in <xref target="RFC7525"/> while setting up TL <bcp14>MUST</bcp14> follow the procedures in <xref target="RFC7525" format
S ="default" sectionFormat="of" derivedContent="RFC7525"/> while setting up TLS
connection with the WebSocket server. connection with the WebSocket server.
The BFCP client validates the server by means of verifying the server cert ificate. The BFCP client validates the server by means of verifying the server cert ificate.
This means the "websocket-uri" value MUST contain a hostname. This means the 'websocket-uri' value <bcp14>MUST</bcp14> contain a hostnam
The verification process does not use a=fingerprint.</t> e.
The verification process does not use "a=fingerprint".</t>
<t>A floor control server that receives a message over TCP/WS <t indent="0" pn="section-8-3">A floor control server that receives a mess
age over TCP/WS
can mandate the use of TCP/WSS by generating an Error message, can mandate the use of TCP/WSS by generating an Error message,
as described in Section 13.8 of <xref as described in <xref target="RFC8855" section="13.8" sectionFormat="of" f
target="I-D.ietf-bfcpbis-rfc4582bis"/>, with an Error code with ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc8855#section-13.8" de
a value of 9 (use TLS).</t> rivedContent="RFC8855"/>,
with an error code with a value of 9 (Use TLS).</t>
<t>Prior to sending BFCP requests, a BFCP WebSocket client <t indent="0" pn="section-8-4">Prior to sending BFCP requests, a BFCP WebS
ocket client
connects to a BFCP WebSocket server and performs the connection connects to a BFCP WebSocket server and performs the connection
handshake. As described in <xref handshake. As described in <xref target="handshake" format="default" secti
target="the_websocket_protocol"/> the handshake procedure onFormat="of" derivedContent="Section 4.1"/>, the handshake procedure
involves a HTTP GET method request from the client and a involves an HTTP GET method request from the client and a
response from the server including an HTTP 101 status code.</t> response from the server including an HTTP 101 status code.</t>
<t indent="0" pn="section-8-5">In order to authorize the WebSocket connect
<t>In order to authorize the WebSocket connection, the BFCP ion, the BFCP
WebSocket server SHOULD inspect any cookie <xref target="RFC6265"/> WebSocket server <bcp14>SHOULD</bcp14> inspect any cookie header fields
headers present in the HTTP GET request. For many web <xref target="RFC6265" format="default" sectionFormat="of" derivedContent=
applications the value of such a cookie is provided by the web "RFC6265"/> 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 once the user has authenticated themselves to the web
server, which could be done by many existing mechanisms. As an server, which could be done by many existing mechanisms. As an
alternative method, the BFCP WebSocket Server could request HTTP alternative method, the BFCP WebSocket server could request HTTP
authentication by replying to the Client's GET method request authentication by replying to the client's GET method request
with a HTTP 401 status code. The WebSocket protocol <xref with an HTTP 401 status code. The WebSocket protocol <xref target="RFC6455
target="RFC6455"/> covers this usage in Section 4.1: " format="default" sectionFormat="of" derivedContent="RFC6455"/>
<list style="empty"> covers this usage in Section <xref target="RFC6455" section="4.1" sectionF
<t>If the status code received from the server is not 101, ormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#se
the WebSocket client stack handles the response per HTTP ction-4.1" derivedContent="RFC6455"/>:
<xref target="RFC7230"/> procedures, in particular the </t>
client might perform authentication if it receives 401 <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-8-6"
status code.</t> >
<t>If the status code received from the server is not 101, <li pn="section-8-6.1">If the status code received from the server is no
t 101,
the WebSocket client stack handles the response per HTTP the WebSocket client stack handles the response per HTTP
<xref target="RFC7230"/> procedures, in particular the <xref target="RFC7230" format="default" sectionFormat="of" derivedCont
client might perform authentication if it receives 401 ent="RFC7230"/> procedures; in particular, the
client might perform authentication if it receives an 401
status code. The WebSocket clients are vulnerable to the attacks status code. The WebSocket clients are vulnerable to the attacks
of basic authentication (mentioned in Section 4 of <xref target="RFC761 of basic authentication (mentioned in <xref target="RFC7617" section="4
7"/>) and " sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rf
digest authentication (mentioned in Section 5 of <xref target="RFC7616"/ c7617#section-4" derivedContent="RFC7617"/>) and
>]). To overcome digest authentication (mentioned in <xref target="RFC7616" section="5" s
some of these weakness, the WebSocket clients for example can use ectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc76
HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in <xref tar 16#section-5" derivedContent="RFC7616"/>). To overcome
get="RFC7486"/>.</t> some of these weaknesses, WebSocket clients can use the
</list></t> HTTP Origin-Bound Authentication (HOBA) mechanism mentioned in
<xref target="RFC7486" format="default" sectionFormat="of" derivedConten
t="RFC7486"/>, for example.</li>
</ul>
</section> </section>
<section anchor="security_considerations" numbered="true" toc="include" remo
<section anchor="security_considerations" veInRFC="false" pn="section-9">
title="Security Considerations"> <name slugifiedName="name-security-considerations">Security Considerations
<t>Considerations from <xref </name>
target="I-D.ietf-bfcpbis-rfc4582bis"/>, <xref <t indent="0" pn="section-9-1">Considerations from <xref target="RFC8855"
target="I-D.ietf-bfcpbis-rfc4583bis"/> and RFC5018 <xref format="default" sectionFormat="of" derivedContent="RFC8855"/>,
target="RFC5018"/> apply.</t> <xref target="RFC8856" format="default" sectionFormat="of" derivedContent=
"RFC8856"/>, and <xref target="RFC5018" format="default" sectionFormat="of" deri
<t>BFCP relies on lower-layer security mechanisms to provide vedContent="RFC5018"/> apply.</t>
<t indent="0" pn="section-9-2">BFCP relies on lower-layer security mechani
sms to provide
replay and integrity protection and confidentiality. It is replay and integrity protection and confidentiality. It is
RECOMMENDED that the BFCP traffic transported over a WebSocket <bcp14>RECOMMENDED</bcp14> that the BFCP traffic transported over WebSocke
communication be protected by using a secure WebSocket t
connection (using TLS <xref target="RFC5246"/> over TCP). The security be protected by using a Secure WebSocket
considerations in <xref target="RFC6455"/> apply for BFCP over WebSocket a connection (using TLS <xref target="RFC8446" format="default" sectionForma
s well. t="of" derivedContent="RFC8446"/> over TCP). The security
considerations in <xref target="RFC6455" format="default" sectionFormat="o
f" derivedContent="RFC6455"/> apply for BFCP over WebSocket as well.
The security model here is a typical webserver-client model The security model here is a typical webserver-client model
where the client validates the server certificate and then connects to the server. where the client validates the server certificate and then connects to the server.
<xref target="authentication"/> describes the authentication procedures be tween client <xref target="authentication" format="default" sectionFormat="of" derivedC ontent="Section 8"/> describes the authentication procedures between client
and server.</t> and server.</t>
<t indent="0" pn="section-9-3">When using BFCP over WebSocket, the securit
<t>When using BFCP over websockets, the security mechanisms defined in y mechanisms defined in
<xref target="I-D.ietf-bfcpbis-rfc4582bis"/> are not used. Instead, the <xref target="RFC8855" format="default" sectionFormat="of" derivedContent="R
application is required to build and rely on the security mechanisms in <xre FC8855"/> are not used. Instead, the
f target="RFC6455"/>.</t> application is required to build and rely on the security mechanisms in <xre
f target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/
<t>The rest of this section analyses the threats described in Section 14 of >.</t>
<xref target="I-D.ietf-bfcpbis-rfc4582bis"/> when WebSocket is used as tra <t indent="0" pn="section-9-4">The rest of this section analyses the threa
nsport ts described in
<xref target="RFC8855" section="14" sectionFormat="of" format="default" de
rivedLink="https://rfc-editor.org/rfc/rfc8855#section-14" derivedContent="RFC885
5"/> when WebSocket is used as a transport
protocol for BFCP.</t> protocol for BFCP.</t>
<t indent="0" pn="section-9-5">An attacker attempting to impersonate a flo
<t>An attacker attempting to impersonate a floor control server is avoided or control server is
by having avoided by having servers accept BFCP messages over WSS
servers accept BFCP messages over WSS only. As with any other web connecti only. As with any other web connection, the clients will verify the server
on, the clients 's
will verify the servers certificate. The floor control WebSocket client M certificate. The BFCP WebSocket client <bcp14>MUST</bcp14> follow the
UST follow the procedures in <xref target="RFC7525" format="default" sectionFormat="of" d
procedures in <xref target="RFC7525"/> (including hostname verification as erivedContent="RFC7525"/> (including hostname verification as per
per <xref target="RFC7525" section="6.1" sectionFormat="of" format="default" d
Section 6.1 in <xref target="RFC7525"/>) while setting up TLS connection w erivedLink="https://rfc-editor.org/rfc/rfc7525#section-6.1" derivedContent="RFC7
ith floor 525"/>) while setting up a TLS connection with floor
control webSocket server.</t> control WebSocket server.</t>
<t indent="0" pn="section-9-6">An attacker attempting to impersonate a flo
<t>An attacker attempting to impersonate a floor control client is avoided or control client is avoided by
by
having servers accept BFCP messages over WSS only. As described in having servers accept BFCP messages over WSS only. As described in
Section 10.5 of <xref target="RFC6455"/> the floor control server can us <xref target="RFC6455" section="10.5" sectionFormat="of" format="default
e " derivedLink="https://rfc-editor.org/rfc/rfc6455#section-10.5" derivedContent="
any client authentication mechanism and follow the steps in <xref target RFC6455"/> the floor control server can use
="authentication"/> any client authentication mechanism and follow the steps in <xref target
="authentication" format="default" sectionFormat="of" derivedContent="Section 8"
/>
of this document.</t> of this document.</t>
<t indent="0" pn="section-9-7">Attackers may attempt to modify messages ex
<t>Attackers may attempt to modify messages exchanged by a client and a changed by a client and a
floor control server. This can be prevented by having WSS between client a nd server.</t> floor control server. This can be prevented by having WSS between client a nd server.</t>
<t indent="0" pn="section-9-8">An attacker trying to replay the messages i
<t>An attacker trying to replay the messages is prevented by s prevented by
having floor control servers check that messages arriving over a having floor control servers check that messages arriving over a
given WSS connection use an authorized user ID. </t> given WSS connection use an authorized user ID. </t>
<t indent="0" pn="section-9-9">Attackers may eavesdrop on the network to g
<t>Attackers may may eavesdrop on the network to get access et access
to confidential information between the floor control server and a to confidential information between the floor control server and a
client (e.g., why a floor request was denied). In order to ensure that 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 users are getting the level of protection that they would get using
the BFCP protocol directly, applications need to have a way to BFCP directly, applications need to have a way to
control the websocket libraries to use encryption algorithms specified in control the WebSocket libraries to use encryption algorithms specified in
Section 7 of <xref target="I-D.ietf-bfcpbis-rfc4582bis"/> . Since the <xref target="RFC8855" section="7" sectionFormat="of" format="default" derive
WebSocket API <xref target="WS-API"/> does not have a way to allow an dLink="https://rfc-editor.org/rfc/rfc8855#section-7" derivedContent="RFC8855"/>.
Since the
WebSocket API <xref target="WS-API" format="default" sectionFormat="of" deriv
edContent="WS-API"/> does not have a way to allow an
application to select the encryption algorithm to be used, the protection lev el application to select the encryption algorithm to be used, the protection lev el
provided when WSS is used is limited to the underlying TLS algorithm used by provided when WSS is used is limited to the underlying TLS algorithm used by
WebSocket library.</t> the WebSocket library.</t>
</section> </section>
<section anchor="iana_considerations" numbered="true" toc="include" removeIn
<section anchor="iana_considerations" title="IANA Considerations"> RFC="false" pn="section-10">
<section title="Registration of the WebSocket BFCP Sub-Protocol"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This specification requests IANA to register the WebSocket <section numbered="true" toc="include" removeInRFC="false" pn="section-10.
BFCP sub-protocol under the "WebSocket Subprotocol Name" 1">
Registry with the following data:</t> <name slugifiedName="name-registration-of-the-websock">Registration of t
he WebSocket BFCP Subprotocol</name>
<t><list style="hanging"> <t indent="0" pn="section-10.1-1">IANA has registered the WebSocket
<t hangText="Subprotocol Identifier:">BFCP</t> BFCP subprotocol under the "WebSocket Subprotocol Name Registry"
as follows:</t>
<t hangText="Subprotocol Common Name:">WebSocket Transport <dl newline="false" spacing="normal" indent="3" pn="section-10.1-2">
for BFCP (Binary Floor Control Protocol)</t> <dt pn="section-10.1-2.1">Subprotocol Identifier:</dt>
<dd pn="section-10.1-2.2">bfcp</dd>
<t hangText="Subprotocol Definition:">RFC&rfc.number;</t> <dt pn="section-10.1-2.3">Subprotocol Common Name:</dt>
</list></t> <dd pn="section-10.1-2.4">WebSocket Transport
<t>[[NOTE TO RFC EDITOR: Please change &rfc.number; to the number as for BFCP (Binary Floor Control Protocol)</dd>
signed to this specification, and remove this paragraph on publication.]]</t> <dt pn="section-10.1-2.5">Subprotocol Definition:</dt>
<dd pn="section-10.1-2.6">RFC 8857</dd>
</section> </dl>
<section title="Registration of the 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP '
proto' Values">
<t>This document defines two new values for the SDP 'proto'
field under the Session Description Protocol (SDP) Parameters
registry. The resulting entries are shown in <xref
target="IANA_SDP_proto"/> below:<figure
anchor="IANA_SDP_proto" align="center"
title="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 assi
gned to this specification, and remove this paragraph on publication.]]</t>
</section> </section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-10.
2">
<section anchor="acknowledgements" title="Acknowledgements"> <name slugifiedName="name-registration-of-the-tcp-ws-">Registration of t
<t>The authors want to thank Robert Welbourn, from Acme Packet and Sergi he 'TCP/WS/BFCP' and 'TCP/WSS/BFCP' SDP "proto" Values</name>
o Garcia Murillo <t indent="0" pn="section-10.2-1">This document defines two new values f
who made significant contributions to the first version of or the SDP "proto"
this document. This work benefited from the thorough review subregistry within the "Session Description Protocol (SDP) Parameters"
and constructive comments of Charles Eckel, Christer Holmberg, Paul Kyzi registry. The resulting entries are shown in <xref target="IANA_SDP_prot
vat, Dan Wing and Alissa Cooper. o" format="default" sectionFormat="of" derivedContent="Table 1"/>:</t>
Thanks to Bert Wijnen, Robert Sparks and Mirja Kuehlewind for their revi <table anchor="IANA_SDP_proto" align="center" pn="table-1">
ews and comments on this document. <name slugifiedName="name-values-for-the-sdp-proto-fi">Values for the
</t> SDP "proto" Field</name>
<t> Thanks for Spencers Dawkin, Ben Campbell, Kathleen Moriarty, Alexey <thead>
Melnikov, Jari Arkko and Stephen Farrell for <tr>
their feedback and comments during IESG reviews. </t> <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>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative --> <references pn="section-11">
<name slugifiedName="name-references">References</name>
<!-- There are 2 ways to insert reference entries from the citation librarie <references pn="section-11.1">
s: <name slugifiedName="name-normative-references">Normative References</na
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here me>
(as shown) <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm 119" quoteTitle="true" derivedAnchor="RFC2119">
l"?> here <front>
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis. <title>Key words for use in RFCs to Indicate Requirement Levels</tit
xml") le>
Both are cited textually in the same manner: by using xref elements. <author initials="S." surname="Bradner" fullname="S. Bradner">
If you use the PI option, xml2rfc will, by default, try to find included fi <organization showOnFrontPage="true"/>
les in the same </author>
directory as the including file. You can also define the XML_LIBRARY enviro <date year="1997" month="March"/>
nment variable <abstract>
with a value containing a set of directories to search. These can be eithe <t indent="0">In many standards track documents several words are
r in the local used to signify the requirements in the specification. These words are often ca
filing system or remote ones accessed by http (http://domain/dir/... ).--> pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
<references title="Normative References"> e Internet Community, and requests discussion and suggestions for improvements.<
&RFC2119; /t>
</abstract>
&RFC4145; </front>
<seriesInfo name="BCP" value="14"/>
&RFC6455; <seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
&RFC5018; </reference>
<reference anchor="RFC4145" target="https://www.rfc-editor.org/info/rfc4
&BFCPbis; 145" quoteTitle="true" derivedAnchor="RFC4145">
<front>
&RFC7525; <title>TCP-Based Media Transport in the Session Description Protocol
(SDP)</title>
&SDPBFCPbis; <author initials="D." surname="Yon" fullname="D. Yon">
<organization showOnFrontPage="true"/>
<?rfc include="reference.I-D.ietf-bfcpbis-sdp-ws-uri"?> </author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
</references> <organization showOnFrontPage="true"/>
</author>
<references title="Informative References"> <date year="2005" month="September"/>
&RFC7230; <abstract>
<t indent="0">This document describes how to express media transpo
&RFC5246; rt over TCP using the Session Description Protocol (SDP). It defines the SDP 'T
CP' protocol identifier, the SDP 'setup' attribute, which describes the connecti
&RFC6265; on setup procedure, and the SDP 'connection' attribute, which handles connection
reestablishment. [STANDARDS-TRACK]</t>
&RFC7616; </abstract>
</front>
&RFC7617; <seriesInfo name="RFC" value="4145"/>
<seriesInfo name="DOI" value="10.17487/RFC4145"/>
&RFC7486; </reference>
<reference anchor="RFC5018" target="https://www.rfc-editor.org/info/rfc5
<reference anchor="WS-API"> 018" quoteTitle="true" derivedAnchor="RFC5018">
<front> <front>
<title>The WebSocket API</title> <title>Connection Establishment in the Binary Floor Control Protocol
(BFCP)</title>
<author> <author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization>W3C</organization> <organization showOnFrontPage="true"/>
</author> </author>
<date year="2007" month="September"/>
<author fullname="Ian Hickson" initials="I." role="editor" <abstract>
surname="Hickson"> <t indent="0">This document specifies how a Binary Floor Control P
<organization>Google, Inc.</organization> rotocol (BFCP) client establishes a connection to a BFCP floor control server ou
</author> tside the context of an offer/answer exchange. Client and server authentication
are based on Transport Layer Security (TLS). [STANDARDS-TRACK]</t>
<date month="May" year="2012"/> </abstract>
</front> </front>
</reference> <seriesInfo name="RFC" value="5018"/>
<seriesInfo name="DOI" value="10.17487/RFC5018"/>
</reference>
<reference anchor="RFC6455" target="https://www.rfc-editor.org/info/rfc6
455" 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 us
ed for this is the origin-based security model commonly used by web browsers. T
he 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 bro
wser-based applications that need two-way communication with servers that does n
ot rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;
iframe&gt;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/rfc7
525" quoteTitle="true" derivedAnchor="RFC7525">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) 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 Transpor
t Layer Security (DTLS) are widely used to protect data exchanged over applicati
on protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few ye
ars, several serious attacks on TLS have emerged, including attacks on its most
commonly used cipher suites and their modes of operation. This document provide
s recommendations for improving the security of deployed services that use TLS a
nd 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/rfc8
124" quoteTitle="true" derivedAnchor="RFC8124">
<front>
<title>The Session Description Protocol (SDP) WebSocket Connection U
RI Attribute</title>
<author initials="R." surname="Ravindranath" fullname="R. Ravindrana
th">
<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-ti
me communication between clients and servers in web-based applications. This do
cument specifies extensions to Session Description Protocol (SDP) for applicatio
n 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/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</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/rfc8
855" quoteTitle="true" derivedAnchor="RFC8855">
<front>
<title>The Binary Floor Control Protocol (BFCP)</title>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarill
o">
<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/rfc8
856" quoteTitle="true" derivedAnchor="RFC8856">
<front>
<title>Session Description Protocol (SDP) Format for Binary Floor Co
ntrol 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/rfc6
265" 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 ses
sion over the mostly stateless HTTP protocol. Although cookies have many histor
ical infelicities that degrade their security and privacy, the Cookie and Set-Co
okie 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/rfc7
230" quoteTitle="true" derivedAnchor="RFC7230">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Ro
uting</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 stateles
s application-level protocol for distributed, collaborative, hypertext informati
on systems. This document provides an overview of HTTP architecture and its ass
ociated 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/rfc7
486" 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 alterna
tive to HTTP authentication schemes that require passwords and therefore avoids
all problems related to passwords, such as leakage of server-side password datab
ases.</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/rfc7
616" 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 si
mple challenge- response authentication mechanism that may be used by a server t
o challenge a client request and by a client to provide authentication informati
on. This document defines the HTTP Digest Authentication scheme that can be use
d 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/rfc7
617" 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/rfc8
446" quoteTitle="true" derivedAnchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<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 commun
icate over the Internet in a way that is designed to prevent eavesdropping, tamp
ering, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
r 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-websock
ets-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> </references>
<section anchor="acknowledgements" numbered="false" toc="include" removeInRF
C="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 of <contact fullname="Charles Eckel"/>, <conta
ct fullname="Christer Holmberg"/>,
<contact fullname="Paul Kyzivat"/>, <contact fullname="Dan Wing"/>, and
<contact fullname="Alissa Cooper"/>.
Thanks to <contact fullname="Bert Wijnen"/>, <contact fullname="Robert S
parks"/>, and <contact fullname="Mirja Kühlewind"/>
for their reviews and comments on this document.
</t>
<t indent="0" pn="section-appendix.a-2"> Thanks to <contact fullname="Spen
cer Dawkins"/>, <contact fullname="Ben Campbell"/>,
<contact fullname="Kathleen Moriarty"/>, <contact fullname="Alexey Melni
kov"/>, <contact fullname="Jari Arkko"/>,
and <contact fullname="Stephen Farrell"/> for
their feedback and comments during IESG reviews. </t>
</section>
<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>
<author 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 Ravindran
ath">
<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>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 91 change blocks. 
675 lines changed or deleted 1204 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/