rfc8855xml2.original.xml   rfc8855.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!-- [rfced] There are [auth] comments included throughout the file. We have
left them in for now, in case you want to review. However, please
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> note that these will be removed from the XML file prior to publication.
-->
<rfc category="std" ipr="trust200902" docName="draft-ietf-bfcpbis-rfc4582bis-16"
obsoletes="4582">
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<front>
<title abbrev="BFCP">The Binary Floor Control Protocol (BFCP)</title>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>FI-02420 Jorvas</city>
<country>Finland</country>
</postal>
<email>gonzalo.camarillo@ericsson.com</email>
</address>
</author>
<author initials="K." surname="Drage" fullname="Keith Drage"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
<organization>Alcatel-Lucent</organization> category="std"
<address> consensus="true"
<postal> ipr="trust200902"
<street>Quadrant, StoneHill Green, Westlea</street> docName="draft-ietf-bfcpbis-rfc4582bis-16"
<street>Swindon, Wilts</street> number="8855"
<country>UK</country> obsoletes="4582"
</postal> updates=""
<email>drage@alcatel-lucent.com</email> submissionType="IETF"
</address> xml:lang="en"
</author> tocInclude="true"
tocDepth="4"
symRefs="false"
sortRefs="true"
version="3">
<author fullname="Tom Kristensen" initials="T." surname="Kristensen"> <!-- xml2rfc v2v3 conversion 2.35.0 -->
<organization>Cisco</organization> <front>
<address> <title abbrev="BFCP">The Binary Floor Control Protocol (BFCP)</title>
<postal> <seriesInfo name="RFC" value="8855" />
<street>Philip Pedersens vei 1</street> <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<city>NO-1366 Lysaker</city> <organization>Ericsson</organization>
<country>Norway</country> <address>
</postal> <postal>
<email>tomkrist@cisco.com, tomkri@ifi.uio.no</email> <street>Hirsalantie 11</street>
</address> <code>02420</code><city>Jorvas</city>
</author> <country>Finland</country>
</postal>
<email>gonzalo.camarillo@ericsson.com</email>
</address>
</author>
<author initials="J." surname="Ott" fullname="Joerg Ott"> <author initials="K." surname="Drage" fullname="Keith Drage">
<organization>Aalto University</organization> <address>
<address> <postal>
<postal> </postal>
<street>Otakaari 5 A</street> <email>drageke@ntlworld.com</email>
<city>FI-02150 Espoo</city> </address>
<country>Finland</country> </author>
</postal>
<email>jo@comnet.tkk.fi</email>
</address>
</author>
<author fullname="Charles Eckel" initials="C." surname="Eckel"> <author fullname="Tom Kristensen" initials="T." surname="Kristensen">
<organization>Cisco</organization> <organization abbrev="Jotron">Jotron AS</organization>
<address> <address>
<postal> <postal>
<street>707 Tasman Drive</street> <street>Ringdalskogen 8</street>
<city>California, CA 95035</city> <code>3270</code> <city>Larvik</city>
<country>United States</country> <country>Norway</country>
</postal> </postal>
<email>eckelcu@cisco.com</email> <email>tom.kristensen@jotron.com, tomkri@ifi.uio.no</email>
</address> </address>
</author> </author>
<!-- Maximum 5 authors in current xml2rfc <author initials="J." surname="Ott" fullname="Jörg Ott">
<organization>Technical University Munich</organization>
<address>
<postal>
<street>Boltzmannstrasse 3</street>
<code>85748</code><city>Garching</city>
<country>Germany</country>
</postal>
<email>ott@in.tum.de</email>
</address>
</author>
<author fullname="Charles Eckel" initials="C." surname="Eckel">
<organization>Cisco</organization>
<address>
<postal>
<street>707 Tasman Drive</street>
<city>Milpitas</city>
<region>California</region>
<code>95035</code>
<country>United States of America</country>
</postal>
<email>eckelcu@cisco.com</email>
</address>
</author>
<!-- [auth] Maximum 5 authors in current xml2rfc
<author fullname="Paul E. Jones" initials="P.E." surname="Jones"> <author fullname="Paul E. Jones" initials="P.E." surname="Jones">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street>7025 Kit Creek Rd.</street> <street>7025 Kit Creek Rd.</street>
<city>Research Triangle Park, NC 27709</city> <city>Research Triangle Park, NC 27709</city>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>paulej@packetizer.com</email> <email>paulej@packetizer.com</email>
</address> </address>
</author> </author>
--> -->
<date year="2020" month="April" />
<date/> <area>Real-time Applications and Infrastructure</area>
<workgroup>BFCPbis Working Group</workgroup>
<area>Real-time Applications and Infrastructure</area> <keyword>floor control</keyword>
<workgroup>BFCPbis Working Group</workgroup> <keyword>conference</keyword>
<abstract>
<keyword>floor control</keyword> <t>Floor control is a means to manage joint or exclusive access to
<keyword>conference</keyword> shared resources in a (multiparty) conferencing environment. Thereby,
floor control complements other functions -- such as conference and
<abstract> media session setup, conference policy manipulation, and media control
<t>Floor control is a means to manage joint or exclusive access to shared re -- that are realized by other protocols.</t>
sources in a (multiparty) conferencing environment. Thereby, floor control compl <t>This document specifies the Binary Floor Control Protocol
ements other functions -- such as conference and media session setup, conference (BFCP). BFCP is used between floor participants and floor control
policy manipulation, and media control -- that are realized by other protocols. servers, and between floor chairs (i.e., moderators) and floor control
</t> servers.</t>
<t>This document specifies the Binary Floor Control Protocol (BFCP). BFCP is <t>This document obsoletes RFC 4582.</t>
used between floor participants and floor control servers, and between floor ch <!-- [auth] Ensure correct section #, as xref is not allowed in abstract -
airs (i.e., moderators) and floor control servers.</t> ->
<t>This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in </abstract>
Section 16.</t> </front>
<!-- Ensure correct section #, as xref is no <middle>
t allowed in abstract --> <section anchor="sec_intro" numbered="true" toc="default">
</abstract> <name>Introduction</name>
</front> <t>Within a conference, some applications need to manage the access to a s
et of shared resources, such as the right to send media to a particular media se
<middle> ssion. Floor control enables such applications to provide users with coordinated
<section title="Introduction" anchor="sec:intro"> (shared or exclusive) access to these resources.</t>
<t>Within a conference, some applications need to manage the access to a set <t>The Requirements for Floor Control Protocol <xref target="RFC4376" form
of shared resources, such as the right to send media to a particular media sess at="default"/> list a set of requirements that need to be met by floor control p
ion. Floor control enables such applications to provide users with coordinated ( rotocols. The Binary Floor Control Protocol (BFCP), which is specified in this d
shared or exclusive) access to these resources.</t> ocument, meets these requirements.</t>
<t>The Requirements for Floor Control Protocol <xref target="RFC4376"/> list <t>In addition, BFCP has been designed so that it can be used in low-bandw
a set of requirements that need to be met by floor control protocols. The Binar idth environments. The binary encoding used by BFCP achieves a small message siz
y Floor Control Protocol (BFCP), which is specified in this document, meets thes e (when message signatures are not used) that keeps the time it takes to transmi
e requirements.</t> t delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages incl
<t>In addition, BFCP has been designed so that it can be used in low-bandwid ude FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expec
th environments. The binary encoding used by BFCP achieves a small message size ted that future extensions to these messages will not increase the size of these
(when message signatures are not used) that keeps the time it takes to transmit messages in a significant way.</t>
delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages includ <t>The remainder of this document is organized as follows: <xref
e FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expecte target="sec_terminology" format="default"/> defines the terminology used
d that future extensions to these messages will not increase the size of these m throughout this document, <xref target="sec_scope" format="default"/>
essages in a significant way.</t> discusses the scope of BFCP (i.e., which tasks fall within the scope of
<t>The remainder of this document is organized as follows: <xref target="sec BFCP and which ones are performed using different mechanisms), <xref
:terminology"/> defines the terminology used throughout this document, <xref tar target="sec_overview" format="default"/> provides a non-normative
get="sec:scope"/> discusses the scope of BFCP (i.e., which tasks fall within the overview of BFCP operation. The subsequent sections provide the
scope of BFCP and which ones are performed using different mechanisms), <xref t normative specification of BFCP. <xref target="sec_changes" />
arget="sec:overview"/> provides a non-normative overview of BFCP operation, and summarizes changes from <xref target="RFC4582"> RFC 4582</xref>.</t>
subsequent sections provide the normative specification of BFCP.</t> </section>
</section> <section anchor="sec_terminology" numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology" anchor="sec:terminology"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
LD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in th IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
is document are to be interpreted as described in BCP 14, <xref target="RFC2119" NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
>RFC 2119</xref> and indicate requirement levels for compliant implementations.< RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
/t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>Media Participant: An entity that has access to the media resources of a be interpreted as
conference (e.g., it can receive a media stream). In floor-controlled conference described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
s, a given media participant is typically colocated with a floor participant, bu when, and only when, they appear in all capitals, as shown here.
t it does not need to be. Third-party floor requests consist of having a floor p </t>
articipant request a floor for a media participant when they are not colocated. <dl>
The protocol between a floor participant and a media participant (that are not c <dt>Media Participant:</dt> <dd>An entity that has access to the media
olocated) is outside the scope of this document.</t> resources of a conference (e.g., it can receive a media stream). In floor-contro
<t>Client: A floor participant or a floor chair that communicates with a flo lled conferences, a given media participant is typically co-located with a floor
or control server using BFCP.</t> participant, but it does not need to be. Third-party floor requests consist of
<t>Floor: A temporary permission to access or manipulate a specific shared r having a floor participant request a floor for a media participant when they are
esource or set of resources.</t> not co-located. The protocol between a floor participant and a media participan
<t>Floor Chair: A logical entity that manages one floor (grants, denies, or t (that are not co-located) is outside the scope of this document.</dd>
revokes a floor). An entity that assumes the logical role of a floor chair for a <dt>Client:</dt> <dd>A floor participant or a floor chair that communicate
given transaction may assume a different role (e.g., floor participant) for a d s with a floor control server using BFCP.</dd>
ifferent transaction. The roles of floor chair and floor participant are defined <dt>Floor:</dt> <dd>A temporary permission to access or manipulate a speci
on a transaction-by-transaction basis. BFCP transactions are defined in <xref t fic shared resource or set of resources.</dd>
arget="sec:transactions"/>.</t> <dt>Floor Chair:</dt> <dd>A logical entity that manages one floor (grants,
<t>Floor Control: A mechanism that enables applications or users to gain saf denies, or revokes a floor). An entity that assumes the logical role of a floor
e and mutually exclusive or non-exclusive input access to the shared object or r chair for a given transaction may assume a different role (e.g., floor particip
esource.</t> ant) for a different transaction. The roles of floor chair and floor participant
<t>Floor Control Server: A logical entity that maintains the state of the fl are defined on a transaction-by-transaction basis. BFCP transactions are define
oor(s), including which floors exists, who the floor chairs are, who holds a flo d in <xref target="sec_transactions" format="default"/>.</dd>
or, etc. Requests to manipulate a floor are directed at the floor control serve <dt>Floor Control:</dt> <dd>A mechanism that enables applications or users
r. The floor control server of a conference may perform other logical roles (e.g to gain safe and mutually exclusive or non-exclusive input access to the shared
., floor participant) in another conference.</t> object or resource.</dd>
<t>Floor Participant: A logical entity that requests floors, and possibly in <dt>Floor Control Server:</dt> <dd>A logical entity that maintains the sta
formation about them, from a floor control server. An entity that assumes the lo te of the floor(s), including which floors exists, who the floor chairs are, who
gical role of a floor participant for a given transaction may assume a different holds a floor, etc. Requests to manipulate a floor are directed at the floor c
role (e.g., a floor chair) for a different transaction. The roles of floor part ontrol server. The floor control server of a conference may perform other logica
icipant and floor chair are defined on a transaction-by-transaction basis. BFCP l roles (e.g., floor participant) in another conference.</dd>
transactions are defined in <xref target="sec:transactions"/>. In floor-controll <dt>Floor Participant:</dt> <dd>A logical entity that requests floors, and
ed conferences, a given floor participant is typically colocated with a media pa possibly information about them, from a floor control server. An entity that as
rticipant, but it does not need to be. Third-party floor requests consist of hav sumes the logical role of a floor participant for a given transaction may assume
ing a floor participant request a floor for a media participant when they are no a different role (e.g., a floor chair) for a different transaction. The roles o
t colocated.</t> f floor participant and floor chair are defined on a transaction-by-transaction
<t>Participant: An entity that acts as a floor participant, as a media parti basis. BFCP transactions are defined in <xref target="sec_transactions" format="
cipant, or as both.</t> default"/>. In floor-controlled conferences, a given floor participant is typica
<t>BFCP Connection: A transport association between BFCP entities, used to e lly co-located with a media participant, but it does not need to be. Third-party
xchange BFCP messages.</t> floor requests consist of having a floor participant request a floor for a medi
<t>Transaction Failure Window: When communicating over an unreliable transpo a participant when they are not co-located.</dd>
rt, this is some period of time less than or equal to T1*2^4 (see <xref target=" <dt>Participant:</dt> <dd>An entity that acts as a floor participant, as a
timers"/>). For reliable transports, this period of time is unbounded.</t> media participant, or as both.</dd>
</section> <dt>BFCP Connection:</dt> <dd>A transport association between BFCP entitie
s, used to exchange BFCP messages.</dd>
<section title="Scope" anchor="sec:scope"> <dt>Transaction Failure Window:</dt> <dd>When communicating over an
<t>As stated earlier, BFCP is a protocol to coordinate access to shared reso unreliable transport, this is some period of time less than or equal to
urces in a conference following the requirements defined in <xref target="RFC437 T1*2<sup>4</sup> (see <xref target="timers" format="default"/>). For
6"/>. Floor control complements other functions defined in the XCON conferencin reliable transports, this period of time is unbounded.</dd>
g framework <xref target="RFC5239"/>. The floor control protocol BFCP defined in </dl>
this document only specifies a means to arbitrate access to floors. The rules </section>
and constraints for floor arbitration and the results of floor assignments are o <section anchor="sec_scope" numbered="true" toc="default">
utside the scope of this document and are defined by other protocols <xref targe <name>Scope</name>
t="RFC5239"/>.</t> <t>As stated earlier, BFCP is a protocol to coordinate access to shared re
<t><xref target="fig:arch"/> shows the tasks that BFCP can perform.</t> sources in a conference following the requirements defined in <xref target="RFC4
<t><figure anchor="fig:arch" title="Functionality provided by BFCP"> 376" format="default"/>. Floor control complements other functions defined in t
<artwork><![CDATA[ he Centralized Conferencing (XCON) Framework <xref target="RFC5239" format="defa
ult"/>. The floor control protocol BFCP defined in this document only specifies
a means to arbitrate access to floors. The rules and constraints for floor arbi
tration and the results of floor assignments are outside the scope of this docum
ent and are defined by other protocols <xref target="RFC5239" format="default"/>
.</t>
<t><xref target="fig_arch" format="default"/> shows the tasks that BFCP ca
n perform.</t>
<figure anchor="fig_arch">
<name>Functionality provided by BFCP</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+---------+ +---------+
| Floor | | Floor |
| Chair | | Chair |
| | | |
+---------+ +---------+
^ | ^ |
| | | |
Notification | | Decision Notification | | Decision
| | | |
| | | |
Floor | v Floor | v
+-------------+ Request +---------+ +-------------+ +-------------+ Request +---------+ +-------------+
| Floor |----------->| Floor | Notification | Floor | | Floor |----------->| Floor | Notification | Floor |
| Participant | | Control |------------->| Participant | | Participant | | Control |------------->| Participant |
| |<-----------| Server | | | | |<-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+ +-------------+ Granted or +---------+ +-------------+
Denied ]]></artwork> Denied ]]></artwork>
</figure></t> </figure>
<t>BFCP provides a means:</t> <t>BFCP provides a means:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>for floor participants to send floor requests to floor control server <li>for floor participants to send floor requests to floor control serve
s.</t> rs.</li>
<t>for floor control servers to grant or deny requests to access a given <li>for floor control servers to grant or deny requests to access a give
resource from floor participants.</t> n resource from floor participants.</li>
<t>for floor chairs to send floor control servers decisions regarding fl <li>for floor chairs to send floor control servers decisions regarding f
oor requests.</t> loor requests.</li>
<t>for floor control servers to keep floor participants and floor chairs <li>for floor control servers to keep floor participants and floor chair
informed about the status of a given floor or a given floor request.</t> s informed about the status of a given floor or a given floor request.</li>
</list></t> </ul>
<t>Even though tasks that do not belong to the previous list are outside the <t>Even though tasks that do not belong to the previous list are outside t
scope of BFCP, some of these out-of-scope tasks relate to floor control and are he scope of BFCP, some of these out-of-scope tasks relate to floor control and a
essential for creating floors and establishing BFCP connections between differe re essential for creating floors and establishing BFCP connections between diffe
nt entities. In the following subsections, we discuss some of these tasks and me rent entities. In the following subsections, we discuss some of these tasks and
chanisms to perform them.</t> mechanisms to perform them.</t>
<section anchor="sec_scope_creation" numbered="true" toc="default">
<section title="Floor Creation" anchor="sec:scope:creation"> <name>Floor Creation</name>
<t>The association of a given floor with a resource or a set of resources <t>The association of a given floor with a resource or a set of resource
(e.g., media streams) is out of the scope of BFCP as described in <xref target=" s (e.g., media streams) is out of the scope of BFCP as described in <xref target
RFC5239"/>. Floor creation and termination are also outside the scope of BFCP; t ="RFC5239" format="default"/>. Floor creation and termination are also outside t
hese aspects are handled using the conference control protocol for manipulating he scope of BFCP; these aspects are handled using the conference control protoco
the conference object. Consequently, the floor control server needs to stay up t l for manipulating the conference object. Consequently, the floor control server
o date on changes to the conference object (e.g., when a new floor is created).< needs to stay up to date on changes to the conference object (e.g., when a new
/t> floor is created).</t>
<t>Conference control clients using CCMP <xref target="RFC6503"/> can spec <t>Conference control clients using Centralized Conferencing Manipulatio
ify such floor-related settings in the &lt;floor-information&gt; element <xref t n Protocol (CCMP) <xref target="RFC6503" format="default"/> can specify such flo
arget="RFC6501"/> of the to-be created conference object provided in the body of or-related settings in the &lt;floor-information&gt; element <xref target="RFC65
a CCMP confRequest/create message issued to the conference control server.</t> 01" format="default"/> of the to-be created conference object provided in the bo
</section> dy of a CCMP confRequest/create message issued to the conference control server.
</t>
<section title="Obtaining Information to Contact a Floor Control Server" anc </section>
hor="sec:scope:info"> <section anchor="sec_scope_info" numbered="true" toc="default">
<t>A client needs a set of data in order to establish a BFCP connection to <name>Obtaining Information to Contact a Floor Control Server</name>
a floor control server. This data includes the transport address of the server, <t>A client needs a set of data in order to establish a BFCP connection
the conference identifier, and a user identifier.</t> to a floor control server. These data include the transport address of the serve
<t>Clients can obtain this information in different ways. One is to use an r, the conference identifier, and a user identifier.</t>
SDP offer/answer <xref target="RFC3264"/> exchange, which is described in <xref <t>Clients can obtain this information in different ways. One is to use
target="I-D.ietf-bfcpbis-rfc4583bis"/>. How to establish a connection to a BFCP a Session Description Protocol (SDP) offer/answer <xref target="RFC3264" format=
floor control server outside the context of an offer/answer exchange when using "default"/> exchange, which is described in <xref target="RFC8856" format="defau
a reliable transport is described in <xref target="RFC5018"/>. Other mechanisms lt"/>. How to establish a connection to a BFCP floor control server is outside t
are described in the XCON framework <xref target="RFC5239"/> (and other related he context of an offer/answer exchange when using a reliable transport is descri
documents). For unreliable transports, the use of an SDP offer/answer exchange bed in <xref target="RFC5018" format="default"/>. Other mechanisms are described
is the only specified mechanism.</t> in the XCON Framework <xref target="RFC5239" format="default"/> (and other rela
</section> ted documents). For unreliable transports, the use of an SDP offer/answer exchan
ge is the only specified mechanism.</t>
</section>
<section anchor="sec_scope_associations" numbered="true" toc="default">
<name>Obtaining Floor-Resource Associations</name>
<t>Floors are associated with resources. For example, a floor that contr
ols who talks at a given time has a particular audio session as its associated r
esource. Associations between floors and resources are part of the conference ob
ject.</t>
<t>Floor participants and floor chairs need to know which resources are
associated with which floors. They can obtain this information by using differen
t mechanisms, such as an SDP offer/answer <xref target="RFC3264" format="default
"/> exchange. How to use an SDP offer/answer exchange to obtain these associatio
ns is described in <xref target="RFC8856" format="default"/>.</t>
<section title="Obtaining Floor-Resource Associations" anchor="sec:scope:ass <aside>
ociations">
<t>Floors are associated with resources. For example, a floor that control
s who talks at a given time has a particular audio session as its associated res
ource. Associations between floors and resources are part of the conference obje
ct.</t>
<t>Floor participants and floor chairs need to know which resources are as
sociated with which floors. They can obtain this information by using different
mechanisms, such as an SDP offer/answer <xref target="RFC3264"/> exchange. How t
o use an SDP offer/answer exchange to obtain these associations is described in
<xref target="I-D.ietf-bfcpbis-rfc4583bis"/>.</t>
<t><list style="hanging">
<t>Note that floor participants perform SDP offer/answer exchanges wit h the conference focus of the conference. So, the conference focus needs to obta in information about associations between floors and resources in order to be ab le to provide this information to a floor participant in an SDP offer/answer exc hange.</t> <t>Note that floor participants perform SDP offer/answer exchanges wit h the conference focus of the conference. So, the conference focus needs to obta in information about associations between floors and resources in order to be ab le to provide this information to a floor participant in an SDP offer/answer exc hange.</t>
</list></t> </aside>
<t>Other mechanisms for obtaining this information, including discussion o <t>Other mechanisms for obtaining this information, including discussion
f how the information is made available to a (SIP) Focus, are described in the X of how the information is made available to a (SIP) focus, are described in the
CON framework <xref target="RFC5239"/> (and other related documents). According XCON Framework <xref target="RFC5239" format="default"/> (and other related doc
to the conferencing system policies, conference control clients using CCMP <xref uments). According to the conferencing system policies, conference control clien
target="RFC6503"/> can modify the floor settings of a conference by issuing CCM ts using CCMP <xref target="RFC6503" format="default"/> can modify the floor set
P confRequest/update messages providing the specific updates to the &lt;floor-in tings of a conference by issuing CCMP confRequest/update messages providing the
formation&gt; element of the target conference object. More information about CC specific updates to the &lt;floor-information&gt; element of the target conferen
MP and BFCP interaction can be found in <xref target="RFC6504"/>.</t> ce object. More information about CCMP and BFCP interaction can be found in <xre
</section> f target="RFC6504" format="default"/>.</t>
</section>
<section title="Privileges of Floor Control" anchor="sec:scope:policy"> <section anchor="sec_scope_policy" numbered="true" toc="default">
<t>A participant whose floor request is granted has the right to use the r <name>Privileges of Floor Control</name>
esource or resources associated with the floor that was requested. For example, <t>A participant whose floor request is granted has the right to use the
the participant may have the right to send media over a particular audio stream. resource or resources associated with the floor that was requested. For example
</t> , the participant may have the right to send media over a particular audio strea
<t>Nevertheless, holding a floor does not imply that others will not be ab m.</t>
le to use its associated resources at the same time, even if they do not have th <t>Nevertheless, holding a floor does not imply that others will not be
e right to do so. Determination of which media participants can actually use the able to use its associated resources at the same time, even if they do not have
resources in the conference is discussed in the XCON Framework <xref target="RF the right to do so. Determination of which media participants can actually use t
C5239"/>.</t> he resources in the conference is discussed in the XCON Framework <xref target="
RFC5239" format="default"/>.</t>
</section>
</section> </section>
</section> <section anchor="sec_overview" numbered="true" toc="default">
<name>Overview of Operation</name>
<section title="Overview of Operation" anchor="sec:overview"> <t>This section provides a non-normative description of BFCP operations. <
<t>This section provides a non-normative description of BFCP operations. <xr xref target="sec_overview_user" format="default"/> describes the interface betwe
ef target="sec:overview:user"/> describes the interface between floor participan en floor participants and floor control servers, and <xref target="sec_overview_
ts and floor control servers, and <xref target="sec:overview:chair"/> describes chair" format="default"/> describes the interface between floor chairs and floor
the interface between floor chairs and floor control servers.</t> control servers.</t>
<t>BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consi <t>BFCP messages, which use a TLV (Type-Length-Value) binary encoding, con
st of a common header followed by a set of attributes. The common header contain sist of a COMMON-HEADER followed by a set of attributes. The COMMON-HEADER conta
s, among other information, a 32-bit conference identifier. Floor participants, ins, among other information, a 32-bit conference identifier. Floor participants
media participants, and floor chairs are identified by 16-bit user identifiers.< , media participants, and floor chairs are identified by 16-bit user identifiers
/t> .</t>
<t>BFCP supports nested attributes (i.e., attributes that contain attributes <t>BFCP supports nested attributes (i.e., attributes that contain attribut
). These are referred to as grouped attributes.</t> es). These are referred to as grouped attributes.</t>
<t>There are two types of transactions in BFCP: client-initiated transaction <t>There are two types of transactions in BFCP: client-initiated transacti
s and server-initiated transactions. <xref target="sec:transactions"/> describes ons and server-initiated transactions. <xref target="sec_transactions" format="d
both types of transactions in detail.</t> efault"/> describes both types of transactions in detail.</t>
<section anchor="sec_overview_user" numbered="true" toc="default">
<section title="Floor Participant to Floor Control Server Interface" anchor= <name>Floor Participant to Floor Control Server Interface</name>
"sec:overview:user"> <t>Floor participants request a floor by sending a FloorRequest message
<t>Floor participants request a floor by sending a FloorRequest message to to the floor control server. BFCP supports third-party floor requests. That is,
the floor control server. BFCP supports third-party floor requests. That is, th the floor participant sending the floor request need not be co-located with the
e floor participant sending the floor request need not be colocated with the med media participant that will get the floor once the floor request is granted. Flo
ia participant that will get the floor once the floor request is granted. FloorR orRequest messages carry the identity of the requester in the User ID field of t
equest messages carry the identity of the requester in the User ID field of the he COMMON-HEADER, and the identity of the beneficiary of the floor (in third-par
common header, and the identity of the beneficiary of the floor (in third-party ty floor requests) in a BENEFICIARY-ID attribute.</t>
floor requests) in a BENEFICIARY-ID attribute.</t> <aside>
<t><list style="hanging">
<t>Third-party floor requests can be sent, for example, by floor parti cipants that have a BFCP connection to the floor control server but that are not media participants (i.e., they do not handle any media).</t> <t>Third-party floor requests can be sent, for example, by floor parti cipants that have a BFCP connection to the floor control server but that are not media participants (i.e., they do not handle any media).</t>
</list></t> </aside>
<t>FloorRequest messages identify the floor or floors being requested by c <t>FloorRequest messages identify the floor or floors being requested by
arrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorReque
message carries more than one floor identifier, the floor control server treats st message carries more than one floor identifier, the floor control server trea
all the floor requests as an atomic package. That is, the floor control server ts all the floor requests as an atomic package. That is, the floor control serve
either grants or denies all the floors in the FloorRequest message.</t> r either grants or denies all the floors in the FloorRequest message.</t>
<t>Floor control servers respond to FloorRequest messages with FloorReques <t>Floor control servers respond to FloorRequest messages with FloorRequ
tStatus messages, which provide information about the status of the floor reques estStatus messages, which provide information about the status of the floor requ
t. The first FloorRequestStatus message is the response to the FloorRequest mess est. The first FloorRequestStatus message is the response to the FloorRequest me
age from the client, and therefore has the same Transaction ID as the FloorReque ssage from the client, and therefore has the same Transaction ID as the FloorReq
st.</t> uest.</t>
<t>Additionally, the first FloorRequestStatus message carries the Floor Re <t>Additionally, the first FloorRequestStatus message carries the Floor
quest ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStat
messages related to the same floor request will carry the same Floor Request ID us messages related to the same floor request will carry the same Floor Request
. This way, the floor participant can associate them with the appropriate floor ID. This way, the floor participant can associate them with the appropriate floo
request.</t> r request.</t>
<t>Messages from the floor participant related to a particular floor reque <t>Messages from the floor participant related to a particular floor req
st also use the same Floor Request ID as the first FloorRequestStatus Message fr uest also use the same Floor Request ID as the first FloorRequestStatus message
om the floor control server.</t> from the floor control server.</t>
<t>Figures 2 and 3 below show examples of call flows where BFCP is used ov <t><xref target="fig_flow1" format="default"/> and <xref target="fig_flo
er a reliable transport. <xref target="app:unrelcallflow"/> shows the same call w2" format="default"/> show examples of call flows where BFCP is used over a rel
flow examples using an unreliable transport.</t> iable transport. <xref target="app_unrelcallflow" format="default"/> shows the s
<t><xref target="fig:flow1"/> shows how a floor participant requests a flo ame call flow examples using an unreliable transport.</t>
or, obtains it, and, at a later time, releases it. This figure illustrates the u <t><xref target="fig_flow1" format="default"/> shows how a floor partici
se, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute pant requests a floor, obtains it, and, at a later time, releases it. This figur
.</t> e illustrates the use, among other things, of the Transaction ID and the FLOOR-R
<t><figure anchor="fig:flow1" title="Requesting and releasing a floor"> EQUEST-ID attribute.</t>
<artwork> <figure anchor="fig_flow1">
<![CDATA[ <name>Requesting and releasing a floor</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorRequest | |(1) FloorRequest |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorRequestStatus | |(2) FloorRequestStatus |
|Transaction ID: 123 | |Transaction ID: 123 |
skipping to change at line 266 skipping to change at line 295
| | | |
|(6) FloorRequestStatus | |(6) FloorRequestStatus |
|Transaction ID: 154 | |Transaction ID: 154 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Released | | Request Status: Released |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| ]]> |<----------------------------------------------|]]></artwork>
</artwork> </figure>
</figure></t> <t><xref target="fig_flow2" format="default"/> shows how a floor partici
<t><xref target="fig:flow2"/> shows how a floor participant requests to be pant requests to be informed on the status of a floor. The first FloorStatus mes
informed on the status of a floor. The first FloorStatus message from the floor sage from the floor control server is the response to the FloorQuery message and
control server is the response to the FloorQuery message and, as such, has the , as such, has the same Transaction ID as the FloorQuery message.</t>
same Transaction ID as the FloorQuery message.</t> <t>Subsequent FloorStatus messages consist of server-initiated transacti
<t>Subsequent FloorStatus messages consist of server-initiated transaction ons, and therefore their Transaction ID is 0 given this example uses a reliable
s, and therefore their Transaction ID is 0 given this example uses a reliable tr transport. FloorStatus message (2) indicates that there are currently two floor
ansport. FloorStatus message (2) indicates that there are currently two floor re requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates
quests for the floor whose Floor ID is 543. FloorStatus message (3) indicates th that the floor requests with Floor Request ID 764 has been granted, and the floo
at the floor requests with Floor Request ID 764 has been granted, and the floor r request with Floor Request ID 635 is the first in the queue. FloorStatus messa
request with Floor Request ID 635 is the first in the queue. FloorStatus message ge (4) indicates that the floor request with Floor Request ID 635 has been grant
(4) indicates that the floor request with Floor Request ID 635 has been granted ed.</t>
.</t> <figure anchor="fig_flow2">
<t><figure anchor="fig:flow2" title="Obtaining status information about a <name>Obtaining status information about a floor</name>
floor"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorQuery | |(1) FloorQuery |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorStatus | |(2) FloorStatus |
|Transaction ID: 257 | |Transaction ID: 257 |
skipping to change at line 341 skipping to change at line 369
|User ID: 234 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Granted | | Request Status: Granted |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| ]]> |<----------------------------------------------|]]></artwork>
</artwork> </figure>
</figure></t> <t>FloorStatus messages contain information about the floor requests
<t>FloorStatus messages contain information about the floor requests they they carry. For example, FloorStatus message (4) indicates that the
carry. For example, FloorStatus message (4) indicates that the floor request wit floor request with Floor Request ID 635 has as the beneficiary (i.e.,
h Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the participant that holds the floor when a particular floor request is
the floor when a particular floor request is granted) the participant whose User granted) the participant whose User ID is 154. The floor request applies
ID is 154. The floor request applies only to the floor whose Floor ID is 543. T only to the floor whose Floor ID is 543. That is, this is not a
hat is, this is not a multi-floor floor request.</t> multi-floor floor request.</t>
<t><list style="hanging"> <aside>
<t>A multi-floor floor request applies to more than one floor (e.g., a participant wants to be able to speak and write on the whiteboard at the same t ime). The floor control server treats a multi-floor floor request as an atomic p ackage. That is, the floor control server either grants the request for all floo rs or denies the request for all floors.</t> <t>A multi-floor floor request applies to more than one floor (e.g., a participant wants to be able to speak and write on the whiteboard at the same t ime). The floor control server treats a multi-floor floor request as an atomic p ackage. That is, the floor control server either grants the request for all floo rs or denies the request for all floors.</t>
</list></t> </aside>
</section> </section>
<section anchor="sec_overview_chair" numbered="true" toc="default">
<section title="Floor Chair to Floor Control Server Interface" anchor="sec:o <name>Floor Chair to Floor Control Server Interface</name>
verview:chair"> <t><xref target="fig_flow3" format="default"/> shows a floor chair instr
<t><xref target="fig:flow3"/> shows a floor chair instructing a floor cont ucting a floor control server to grant a floor.</t>
rol server to grant a floor.</t> <aside>
<t><list style="empty">
<t>Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., gra nting a floor), it does not necessarily need to perform them exactly as requeste d by the floor chair. The operation that the floor control server performs depen ds on the ChairAction message and on the internal state of the floor control ser ver.</t> <t>Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., gra nting a floor), it does not necessarily need to perform them exactly as requeste d by the floor chair. The operation that the floor control server performs depen ds on the ChairAction message and on the internal state of the floor control ser ver.</t>
</list></t> </aside>
<t>For example, a floor chair may send a ChairAction message granting a fl <t>For example, a floor chair may send a ChairAction message granting a
oor that was requested as part of an atomic floor request operation that involve floor that was requested as part of an atomic floor request operation that invol
d several floors. Even if the chair responsible for one of the floors instructs ved several floors. Even if the chair responsible for one of the floors instruct
the floor control server to grant the floor, the floor control server will not g s the floor control server to grant the floor, the floor control server will not
rant it until the chairs responsible for the other floors agree to grant them as grant it until the chairs responsible for the other floors agree to grant them
well. In another example, a floor chair may instruct the floor control server t as well. In another example, a floor chair may instruct the floor control server
o grant a floor to a participant. The floor control server needs to revoke the f to grant a floor to a participant. The floor control server needs to revoke the
loor from its current holder before granting it to the new participant.</t> floor from its current holder before granting it to the new participant.</t>
<t>So, the floor control server is ultimately responsible for keeping a co <t>So, the floor control server is ultimately responsible for keeping a
herent floor state using instructions from floor chairs as input to this state.< coherent floor state using instructions from floor chairs as input to this state
/t> .</t>
<t><figure anchor="fig:flow3" title="Chair instructing the floor control s <figure anchor="fig_flow3">
erver"> <name>Chair instructing the floor control server</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
<![CDATA[
Floor Chair Floor Control Floor Chair Floor Control
Server Server
|(1) ChairAction | |(1) ChairAction |
|Transaction ID: 769 | |Transaction ID: 769 |
|User ID: 357 | |User ID: 357 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| Request Status: Granted | | Request Status: Granted |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) ChairActionAck | |(2) ChairActionAck |
|Transaction ID: 769 | |Transaction ID: 769 |
|User ID: 357 | |User ID: 357 |
|<----------------------------------------------| ]]> |<----------------------------------------------|]]></artwork>
</artwork> </figure>
</figure></t> </section>
</section> </section>
</section> <section anchor="sec_format" numbered="true" toc="default">
<name>Packet Format</name>
<section title="Packet Format" anchor="sec:format"> <t>BFCP packets consist of a 12-octet COMMON-HEADER followed by attributes
<t>BFCP packets consist of a 12-octet common header followed by attributes. . All the protocol values <bcp14>MUST</bcp14> be sent in network byte order.</t>
All the protocol values MUST be sent in network byte order.</t> <section anchor="sec_format_common" numbered="true" toc="default">
<name>COMMON-HEADER Format</name>
<section title="COMMON-HEADER Format" anchor="sec:format:common"> <t>The following is the format of the COMMON-HEADER.</t>
<t>The following is the format of the common header.</t> <figure anchor="fig_common">
<t><figure title="COMMON-HEADER format" anchor="fig:common"> <name>COMMON-HEADER format</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |R|F| Res | Primitive | Payload Length | | Ver |R|F| Res | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID | | Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID | | Transaction ID | User ID |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Fragment Offset (if F is set) | Fragment Length (if F is set) | | | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+---- These fragment fields are never present +---- These fragment fields are never present
when using reliable transports ]]> when using reliable transports]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Ver: This 3-bit field defines the version of BFCP that this message adh <dt>Ver:</dt> <dd>This 3-bit field defines the version of BFCP to which
eres to. This specification defines two versions: 1 and 2. The version field MUS this message adheres. This specification defines two versions: 1 and 2. The vers
T be set to 1 when using BFCP over a reliable transport. The version field MUST ion field <bcp14>MUST</bcp14> be set to 1 when using BFCP over a reliable transp
be set to 2 when using BFCP over an unreliable transport. If a floor control se ort. The version field <bcp14>MUST</bcp14> be set to 2 when using BFCP over an u
rver receives a message with an unsupported version field value or a message wit nreliable transport. If a floor control server receives a message with an unsup
h a version number that is not permitted with the transport over which it was re ported version field value or a message with a version number that is not permit
ceived, the server MUST indicate it does not support the protocol version by sen ted with the transport over which it was received, the server <bcp14>MUST</bcp14
ding an Error message with parameter value 12 (Unsupported Version). Note that > indicate it does not support the protocol version by sending an Error message
BFCP entities supporting only the <xref target="RFC4582"/> subset will not suppo with parameter value 12 (Unsupported Version). Note that BFCP entities supporti
rt this parameter value.</t> ng only the <xref target="RFC4582" format="default"/> subset will not support th
<t>R: The Transaction Responder (R) flag-bit has relevance only for use of is parameter value.</dd>
BFCP over an unreliable transport. When cleared, it indicates that this message
is a request initiating a new transaction, and the Transaction ID that follows
has been generated for this transaction. When set, it indicates that this messag
e is a response to a previous request, and the Transaction ID that follows is th
e one associated with that request. When BFCP is used over a reliable transport,
the flag has no significance and MUST be cleared by the sender and MUST be igno
red by the receiver.</t>
<t>F: The Fragmentation (F) flag-bit has relevance only for use of BFCP ov
er an unreliable transport. When cleared, the message is not fragmented. When se
t, it indicates that the message is a fragment of a large fragmented BFCP messag
e. (The optional fields Fragment Offset and Fragment Length described below are
present only if the F flag is set). When BFCP is used over a reliable transport,
the flag has no significance and MUST be cleared by the sender and the flag MUS
T be ignored by the receiver. In the latter case, the receiver should also proce
ss the COMMON-HEADER as not having the Fragment Offset and Fragment Length field
s present.</t>
<t>Res: The 3 bits in the reserved field MUST be set to zero by the sender
of the message and MUST be ignored by the receiver.</t>
<t>Primitive: This 8-bit field identifies the main purpose of the message.
The following primitive values are defined:</t>
<texttable title="BFCP primitives" anchor="tab:primitives">
<ttcol align="center">Value</ttcol>
<ttcol>Primitive</ttcol>
<ttcol>Direction</ttcol>
<c>1</c> <c>FloorRequest</c> <c><![CDATA[P -> S]]></c>
<c>2</c> <c>FloorRelease</c> <c><![CDATA[P -> S]]></c>
<c>3</c> <c>FloorRequestQuery</c> <c><![CDATA[P -> S ; Ch -> S
]]></c>
<c>4</c> <c>FloorRequestStatus</c> <c><![CDATA[P <- S ; Ch <- S
]]></c>
<c>5</c> <c>UserQuery</c> <c><![CDATA[P -> S ; Ch -> S
]]></c>
<c>6</c> <c>UserStatus</c> <c><![CDATA[P <- S ; Ch <- S
]]></c>
<c>7</c> <c>FloorQuery</c> <c><![CDATA[P -> S ; Ch -> S
]]></c>
<c>8</c> <c>FloorStatus</c> <c><![CDATA[P <- S ; Ch <- S
]]></c>
<c>9</c> <c>ChairAction</c> <c><![CDATA[ Ch -> S
]]></c>
<c>10</c> <c>ChairActionAck</c> <c><![CDATA[ Ch <- S
]]></c>
<c>11</c> <c>Hello</c> <c><![CDATA[P -> S ; Ch -> S
]]></c>
<c>12</c> <c>HelloAck</c> <c><![CDATA[P <- S ; Ch <- S
]]></c>
<c>13</c> <c>Error</c> <c><![CDATA[P <- S ; Ch <- S
]]></c>
<c>14</c> <c>FloorRequestStatusAck</c> <c><![CDATA[P -> S ; Ch -> S
]]></c>
<c>15</c> <c>FloorStatusAck</c> <c><![CDATA[P -> S ; Ch -> S]
]></c>
<c>16</c> <c>Goodbye</c> <c><![CDATA[P -> S ; Ch -> S
; ]]></c>
<c> </c> <c></c> <c><![CDATA[P <- S ; Ch <- S
]]></c>
<c>17</c> <c>GoodbyeAck</c> <c><![CDATA[P -> S ; Ch -> S
; ]]></c>
<c> </c> <c></c> <c><![CDATA[P <- S ; Ch <- S
]]></c>
<postamble>
S: Floor Control Server / P: Floor Participant / Ch: Floor Chair
</postamble>
</texttable>
<t>Payload Length: This 16-bit field contains the length of the message in
4-octet units, excluding the common header. If a Floor Control Server receives
a message with an incorrect Payload Length field value, the receiving server MUS
T send an Error message with parameter value 13 (Incorrect Message Length) to in
dicate this and then discard the message. Other entities that receive a message
with an incorrect length MUST discard the message.</t>
<t><list style="hanging">
<t>Note: BFCP is designed to achieve small message size, as explained
in <xref target="sec:intro"/>, and BFCP entities are required to keep the BFCP m
essage size smaller than the size limited by the 16-bit Payload Length field. To
convey information not strictly related to floor control, other protocols shoul
d be used such as the XCON framework (cf. <xref target="sec:scope"/>).</t>
</list></t>
<t>Conference ID: This 32-bit unsigned integer field identifies the confer
ence to which the message belongs. It is RECOMMENDED that the conference identi
fier be randomly chosen. (Note that the use of predictable conference identifie
rs in conjunction with a non-secure transport protocol makes BFCP susceptible to
off-path data injection attacks, where an attacker can forge a request or respo
nse message.)</t>
<t>Transaction ID: This field contains a 16-bit value that allows users to
match a given message with its response (see <xref target="sec:transactions"/>)
.</t>
<t>User ID: This field contains a 16-bit unsigned integer that uniquely id
entifies a participant within a conference.</t>
<t><list style="hanging">
<t>The identity used by a participant in BFCP, which is carried in the
User ID field, is generally mapped to the identity used by the same participant
in the session establishment protocol (e.g., in SIP). The way this mapping is p
erformed is outside the scope of this specification.</t>
</list></t>
<t>Fragment Offset: This optional field is present only if the F flag is s
et and contains a 16-bit value that specifies the number of 4-octet units contai
ned in previous fragments, excluding the common header.</t>
<t>Fragment Length: This optional field is present only if the F flag is s
et and contains a 16-bit value that specifies the number of 4-octet units contai
ned in this fragment, excluding the common header. BFCP entities that receive m
essage fragments that, individually or collectively, exceed the Payload Length v
alue MUST discard the message. Additionally, if the receiver is a Floor Control
Server, it must also send an Error message with parameter value 13 (Incorrect M
essage Length)</t>
</section>
<section title="Attribute Format" anchor="sec:format:attributes"> <dt>R:</dt> <dd>The Transaction Responder (R) flag bit has relevance onl
<t>BFCP attributes are encoded in TLV (Type-Length-Value) format. Attribut y for use of BFCP over an unreliable transport. When cleared, it indicates that
es are 32-bit aligned.</t> this message is a request initiating a new transaction, and the Transaction ID t
<t><figure title="Attribute format" anchor="sec:format:tlv"> hat follows has been generated for this transaction. When set, it indicates that
<artwork> this message is a response to a previous request, and the Transaction ID that f
ollows is the one associated with that request. When BFCP is used over a reliabl
e transport, the flag has no significance and <bcp14>MUST</bcp14> be cleared by
the sender and <bcp14>MUST</bcp14> be ignored by the receiver.</dd>
<dt>F:</dt> <dd>The Fragmentation (F) flag bit has relevance only for us
e of BFCP over an unreliable transport. When cleared, the message is not fragmen
ted. When set, it indicates that the message is a fragment of a large, fragmente
d BFCP message. (The optional fields Fragment Offset and Fragment Length describ
ed below are present only if the F flag is set). When BFCP is used over a relia
ble transport, the flag has no significance and <bcp14>MUST</bcp14> be cleared b
y the sender, and the flag <bcp14>MUST</bcp14> be ignored by the receiver. In th
e latter case, the receiver should also ignore the Fragment Offset and Fragment
Length fields when processing the COMMON-HEADER.
</dd>
<dt>Res:</dt> <dd>The 3 bits in the reserved field <bcp14>MUST</bcp14> b
e set to zero by the sender of the message and <bcp14>MUST</bcp14> be ignored by
the receiver.</dd>
<dt>Primitive:</dt> <dd>This 8-bit field identifies the main purpose of
the
message. The following primitive values are defined:</dd>
</dl>
<table anchor="tab_primitives" align="center">
<name>BFCP primitives</name>
<thead>
<tr>
<th align="center">Value</th>
<th align="left">Primitive</th>
<th align="left">Direction</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">1</td>
<td align="left">FloorRequest</td>
<td align="left">P -&gt; S</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left">FloorRelease</td>
<td align="left">P -&gt; S</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">FloorRequestQuery</td>
<td align="left">P -&gt; S ; Ch -&gt; S</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">FloorRequestStatus</td>
<td align="left">P &lt;- S ; Ch &lt;- S</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left">UserQuery</td>
<td align="left">P -&gt; S ; Ch -&gt; S</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left">UserStatus</td>
<td align="left">P &lt;- S ; Ch &lt;- S</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left">FloorQuery</td>
<td align="left">P -&gt; S ; Ch -&gt; S</td>
</tr>
<tr>
<td align="center">8</td>
<td align="left">FloorStatus</td>
<td align="left">P &lt;- S ; Ch &lt;- S</td>
</tr>
<tr>
<td align="center">9</td>
<td align="left">ChairAction</td>
<td align="left"> Ch -&gt; S</td>
</tr>
<tr>
<td align="center">10</td>
<td align="left">ChairActionAck</td>
<td align="left"> Ch &lt;- S</td>
</tr>
<tr>
<td align="center">11</td>
<td align="left">Hello</td>
<td align="left">P -&gt; S ; Ch -&gt; S</td>
</tr>
<tr>
<td align="center">12</td>
<td align="left">HelloAck</td>
<td align="left">P &lt;- S ; Ch &lt;- S</td>
</tr>
<tr>
<td align="center">13</td>
<td align="left">Error</td>
<td align="left">P &lt;- S ; Ch &lt;- S</td>
</tr>
<tr>
<td align="center">14</td>
<td align="left">FloorRequestStatusAck</td>
<td align="left">P -&gt; S ; Ch -&gt; S</td>
</tr>
<tr>
<td align="center">15</td>
<td align="left">FloorStatusAck</td>
<td align="left">P -&gt; S ; Ch -&gt; S</td>
</tr>
<tr>
<td align="center">16</td>
<td align="left">Goodbye</td>
<td align="left">P -&gt; S ; Ch -&gt; S ; P &lt;- S ; Ch &
lt;- S</td>
</tr>
<tr>
<td align="center">17</td>
<td align="left">GoodbyeAck</td>
<td align="left">P -&gt; S ; Ch -&gt; S ; P &lt;- S ; Ch &
lt;- S</td>
</tr>
</tbody>
<tfoot>
<tr>
<td align="center" colspan="3">S: Floor Control Server / P: Floor
Participant / Ch: Floor Chair<br/></td>
</tr>
</tfoot>
</table>
<t>
</t>
<dl>
<dt>Payload Length:</dt> <dd>This 16-bit field contains the length of
the message in 4-octet units, excluding the COMMON-HEADER. If a floor
control server receives a message with an incorrect Payload Length
field value, the receiving server <bcp14>MUST</bcp14> send an Error
message with parameter value 13 (Incorrect Message Length) to indicate
this and then discard the message. Other entities that receive a
message with an incorrect length <bcp14>MUST</bcp14> discard the
message.</dd>
</dl>
<aside>
<t>Note: BFCP is designed to achieve small message size, as explained
in <xref target="sec_intro" format="default"/>, and BFCP entities are required t
o keep the BFCP message size smaller than the size limited by the 16-bit Payload
Length field. To convey information not strictly related to floor control, othe
r protocols should be used, such as the XCON Framework (cf.&nbsp;<xref target="s
ec_scope" format="default"/>).</t>
</aside>
<dl>
<dt>Conference ID:</dt> <dd>This 32-bit unsigned integer field identifie
s the conference to which the message belongs. It is <bcp14>RECOMMENDED</bcp14>
that the conference identifier be randomly chosen. (Note that the use of predi
ctable conference identifiers in conjunction with a nonsecure transport protocol
makes BFCP susceptible to off-path data injection attacks, where an attacker ca
n forge a request or response message.)</dd>
<dt>Transaction ID:</dt> <dd>This field contains a 16-bit value that all
ows users to match a given message with its response (see <xref target="sec_tran
sactions" format="default"/>).</dd>
<dt>User ID:</dt> <dd>This field contains a 16-bit unsigned integer
that uniquely identifies a participant within a conference.</dd>
</dl>
<aside>
<t>The identity used by a participant in BFCP, which is carried in the
User ID field, is generally mapped to the identity used by the same participant
in the session establishment protocol (e.g., in SIP). The way this mapping is p
erformed is outside the scope of this specification.</t>
</aside>
<dl>
<dt>Fragment Offset:</dt> <dd>This optional field is present only if the
F flag is set and contains a 16-bit value that specifies the number of 4-octet
units contained in previous fragments, excluding the COMMON-HEADER.</dd>
<dt>Fragment Length:</dt> <dd>This optional field is present only if
the F flag is set and contains a 16-bit value that specifies the
number of 4-octet units contained in this fragment, excluding the
COMMON-HEADER. BFCP entities that receive message fragments that,
individually or collectively, exceed the Payload Length value
<bcp14>MUST</bcp14> discard the message. Additionally, if the
receiver is a floor control server, it must also send an Error message
with parameter value 13 (Incorrect Message Length)</dd>
</dl>
</section>
<section anchor="sec_format_attributes" numbered="true" toc="default">
<name>Attribute Format</name>
<t>BFCP attributes are encoded in TLV (Type-Length-Value) format. Attrib
utes are 32-bit aligned.</t>
<figure anchor="sec_format_tlv">
<name>Attribute format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |M| Length | | | Type |M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Attribute Contents / / Attribute Contents /
/ / / /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </figure>
</t>
<t>Type: This 7-bit field contains the type of the attribute. Each attribu <dl>
te, identified by its type, has a particular format. The attribute formats defin <dt>Type:</dt> <dd><t>This 7-bit field contains the type of the attribut
ed are:</t> e. Each attribute, identified by its type, has a particular format. The attribut
<t><list style="hanging"> e formats defined are:</t>
<t>Unsigned16: The contents of the attribute consist of a 16-bit unsig <dl>
ned integer.</t> <dt>Unsigned16:</dt> <dd>The contents of the attribute consist of a 16
<t>OctetString16: The contents of the attribute consist of 16 bits of -bit unsigned integer.</dd>
arbitrary data.</t> <dt>OctetString16:</dt> <dd>The contents of the attribute consist of 1
<t>OctetString: The contents of the attribute consist of arbitrary dat 6 bits of arbitrary data.</dd>
a of variable length.</t> <dt>OctetString:</dt> <dd>The contents of the attribute consist of arb
<t>Grouped: The contents of the attribute consist of a sequence of att itrary data of variable length.</dd>
ributes.</t> <dt>Grouped:</dt> <dd>The contents of the attribute consist of a seque
nce of attributes.</dd>
</dl></dd>
</dl>
<aside>
<t>Note that extension attributes defined in the future may define new attribute formats.</t> <t>Note that extension attributes defined in the future may define new attribute formats.</t>
</list></t> </aside>
<t>The following attribute types are defined:</t>
<texttable title="BFCP attributes" anchor="tab:attributes">
<ttcol align="center">Type</ttcol>
<ttcol>Attribute</ttcol>
<ttcol>Format</ttcol>
<c>1</c> <c>BENEFICIARY-ID</c> <c>Unsigned16</c>
<c>2</c> <c>FLOOR-ID</c> <c>Unsigned16</c>
<c>3</c> <c>FLOOR-REQUEST-ID</c> <c>Unsigned16</c>
<c>4</c> <c>PRIORITY</c> <c>OctetString16</c>
<c>5</c> <c>REQUEST-STATUS</c> <c>OctetString16</c>
<c>6</c> <c>ERROR-CODE</c> <c>OctetString</c>
<c>7</c> <c>ERROR-INFO</c> <c>OctetString</c>
<c>8</c> <c>PARTICIPANT-PROVIDED-INFO</c> <c>OctetString</c>
<c>9</c> <c>STATUS-INFO</c> <c>OctetString</c>
<c>10</c> <c>SUPPORTED-ATTRIBUTES</c> <c>OctetString</c>
<c>11</c> <c>SUPPORTED-PRIMITIVES</c> <c>OctetString</c>
<c>12</c> <c>USER-DISPLAY-NAME</c> <c>OctetString</c>
<c>13</c> <c>USER-URI</c> <c>OctetString</c>
<c>14</c> <c>BENEFICIARY-INFORMATION</c> <c>Grouped</c>
<c>15</c> <c>FLOOR-REQUEST-INFORMATION</c> <c>Grouped</c>
<c>16</c> <c>REQUESTED-BY-INFORMATION</c> <c>Grouped</c>
<c>17</c> <c>FLOOR-REQUEST-STATUS</c> <c>Grouped</c>
<c>18</c> <c>OVERALL-REQUEST-STATUS</c> <c>Grouped</c>
</texttable>
<t>M: The 'M' bit, known as the Mandatory bit, indicates whether support o
f the attribute is required. If a Floor Control Server receives an unrecognized
attribute with the 'M' bit set the server MUST send an Error message with param
eter value 4 (Unknown Mandatory Attribute) to indicate this. The 'M' bit is sign
ificant for extension attributes defined in other documents only. All attributes
specified in this document MUST be understood by the receiver so that the setti
ng of the 'M' bit is irrelevant for these. Unrecognized attributes, such as tho
se that might be specified in future extensions, that do not have the "M" bit se
t are ignored, but the message is processed.</t>
<t>Length: This 8-bit field contains the length of the attribute in octets
, excluding any padding defined for specific attributes. The length of attribut
es that are not grouped includes the Type, 'M' bit, and Length fields. The Lengt
h in grouped attributes is the length of the grouped attribute itself (including
Type, 'M' bit, and Length fields) plus the total length (including padding) of
all the included attributes.</t>
<t>Attribute Contents: The contents of the different attributes are define
d in the following sections.</t>
<section title="BENEFICIARY-ID" anchor="sec:format:attributes:beneficiaryi <t>The following attribute types are defined:</t>
d"> <table anchor="tab_attributes" align="center">
<t>The following is the format of the BENEFICIARY-ID attribute.</t> <name>BFCP attributes</name>
<t><figure title="BENEFICIARY-ID format" anchor="sec:format:beneficiary- <thead>
id"> <tr>
<artwork> <th align="center">Type</th>
<th align="left">Attribute</th>
<th align="left">Format</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">1</td>
<td align="left">BENEFICIARY-ID</td>
<td align="left">Unsigned16</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left">FLOOR-ID</td>
<td align="left">Unsigned16</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">FLOOR-REQUEST-ID</td>
<td align="left">Unsigned16</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">PRIORITY</td>
<td align="left">OctetString16</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left">REQUEST-STATUS</td>
<td align="left">OctetString16</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left">ERROR-CODE</td>
<td align="left">OctetString</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left">ERROR-INFO</td>
<td align="left">OctetString</td>
</tr>
<tr>
<td align="center">8</td>
<td align="left">PARTICIPANT-PROVIDED-INFO</td>
<td align="left">OctetString</td>
</tr>
<tr>
<td align="center">9</td>
<td align="left">STATUS-INFO</td>
<td align="left">OctetString</td>
</tr>
<tr>
<td align="center">10</td>
<td align="left">SUPPORTED-ATTRIBUTES</td>
<td align="left">OctetString</td>
</tr>
<tr>
<td align="center">11</td>
<td align="left">SUPPORTED-PRIMITIVES</td>
<td align="left">OctetString</td>
</tr>
<tr>
<td align="center">12</td>
<td align="left">USER-DISPLAY-NAME</td>
<td align="left">OctetString</td>
</tr>
<tr>
<td align="center">13</td>
<td align="left">USER-URI</td>
<td align="left">OctetString</td>
</tr>
<tr>
<td align="center">14</td>
<td align="left">BENEFICIARY-INFORMATION</td>
<td align="left">Grouped</td>
</tr>
<tr>
<td align="center">15</td>
<td align="left">FLOOR-REQUEST-INFORMATION</td>
<td align="left">Grouped</td>
</tr>
<tr>
<td align="center">16</td>
<td align="left">REQUESTED-BY-INFORMATION</td>
<td align="left">Grouped</td>
</tr>
<tr>
<td align="center">17</td>
<td align="left">FLOOR-REQUEST-STATUS</td>
<td align="left">Grouped</td>
</tr>
<tr>
<td align="center">18</td>
<td align="left">OVERALL-REQUEST-STATUS</td>
<td align="left">Grouped</td>
</tr>
</tbody>
</table>
<dl>
<dt>M:</dt> <dd>The 'M' bit, known as the Mandatory bit, indicates wheth
er support of the attribute is required. If a floor control server receives an
unrecognized attribute with the 'M' bit set, the server <bcp14>MUST</bcp14> send
an Error message with parameter value 4 (Unknown Mandatory Attribute) to indica
te this. The 'M' bit is significant for extension attributes defined in other do
cuments only. All attributes specified in this document <bcp14>MUST</bcp14> be u
nderstood by the receiver so that the setting of the 'M' bit is irrelevant for t
hese. Unrecognized attributes, such as those that might be specified in future
extensions, that do not have the 'M' bit set are ignored, but the message is pro
cessed.</dd>
<dt>Length:</dt> <dd>This 8-bit field contains the length of the attribu
te in octets, excluding any padding defined for specific attributes. The length
of attributes that are not grouped includes the Type, 'M' bit, and Length field
s. The Length in grouped attributes is the length of the grouped attribute itsel
f (including Type, 'M' bit, and Length fields) plus the total length (including
padding) of all the included attributes.</dd>
<dt>Attribute Contents:</dt> <dd>The contents of the different
attributes are defined in the following sections.</dd>
</dl>
<section anchor="sec_format_attributes_beneficiaryid" numbered="true" to
c="default">
<name>BENEFICIARY-ID</name>
<t>The following is the format of the BENEFICIARY-ID attribute.</t>
<figure anchor="sec_format_beneficiary-id">
<name>BENEFICIARY-ID format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID | |0 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Beneficiary ID: This field contains a 16-bit value that uniquely iden <dt>Beneficiary ID:</dt> <dd>This field contains a 16-bit value that
tifies a user within a conference.</t> uniquely identifies a user within a conference.</dd>
<t><list style="empty"> </dl>
<t>Note that although the formats of the Beneficiary ID and of the U <aside>
ser ID field in the common header are similar, their semantics are different. Th <t>Note that although the formats of the Beneficiary ID and of the U
e Beneficiary ID is used in third-party floor requests and to request informatio ser ID field in the COMMON-HEADER are similar, their semantics are different. Th
n about a particular participant.</t> e Beneficiary ID is used in third-party floor requests and to request informatio
</list></t> n about a particular participant.</t>
</section> </aside>
</section>
<section title="FLOOR-ID" anchor="sec:format:attributes:floorid"> <section anchor="sec_format_attributes_floorid" numbered="true" toc="def
<t>The following is the format of the FLOOR-ID attribute.</t> ault">
<t><figure title="FLOOR-ID format" anchor="sec:format:floor-id"> <name>FLOOR-ID</name>
<artwork> <t>The following is the format of the FLOOR-ID attribute.</t>
<figure anchor="sec_format_floor-id">
<name>FLOOR-ID format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID | |0 0 0 0 0 1 0|M|0 0 0 0 0 1 0 0| Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Floor ID: This field contains a 16-bit value that uniquely identifies <dt>Floor ID:</dt> <dd>This field contains a 16-bit value that
a floor within a conference.</t> uniquely identifies a floor within a conference.</dd>
</section> </dl>
</section>
<section title="FLOOR-REQUEST-ID" anchor="sec:format:attributes:floorreque <section anchor="sec_format_attributes_floorrequestid" numbered="true" t
stid"> oc="default">
<t>The following is the format of the FLOOR-REQUEST-ID attribute.</t> <name>FLOOR-REQUEST-ID</name>
<t><figure title="FLOOR-REQUEST-ID format" anchor="sec:format:floor-requ <t>The following is the format of the FLOOR-REQUEST-ID attribute.</t>
est-id"> <figure anchor="sec_format_floor-request-id">
<artwork> <name>FLOOR-REQUEST-ID format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID | |0 0 0 0 0 1 1|M|0 0 0 0 0 1 0 0| Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Floor Request ID: This field contains a 16-bit value that identifies <dt>Floor Request ID:</dt> <dd>This field contains a 16-bit value
a floor request at the floor control server.</t> that identifies a floor request at the floor control server.</dd>
</section> </dl>
</section>
<section title="PRIORITY" anchor="sec:format:attributes:priority"> <section anchor="sec_format_attributes_priority" numbered="true" toc="de
<t>The following is the format of the PRIORITY attribute.</t> fault">
<t><figure title="PRIORITY format" anchor="sec:format:priority"> <name>PRIORITY</name>
<artwork> <t>The following is the format of the PRIORITY attribute.</t>
<figure anchor="sec_format_priority">
<name>PRIORITY format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved | |0 0 0 0 1 0 0|M|0 0 0 0 0 1 0 0|Prio | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </figure>
</t> <dl>
<t>Prio: This field contains a 3-bit priority value, as shown in <xref t <dt>Prio:</dt> <dd>This field contains a 3-bit Priority value, as
arget="tab:priority"/>. Senders SHOULD NOT use values higher than 4 in this fiel shown in <xref target="tab_priority" format="default"/>. Senders
d. Receivers MUST treat values higher than 4 as if the value received were 4 (Hi <bcp14>SHOULD NOT</bcp14> use values higher than 4 in this
ghest). The default priority value when the PRIORITY attribute is missing is 2 ( field. Receivers <bcp14>MUST</bcp14> treat values higher than 4 as
Normal).</t> if the value received were 4 (Highest). The default Priority value
<texttable title="Priority values" anchor="tab:priority"> when the PRIORITY attribute is missing is 2 (Normal).</dd>
<ttcol align="center">Value</ttcol> </dl>
<ttcol>Priority</ttcol> <table anchor="tab_priority" align="center">
<c>0</c> <c>Lowest</c> <name>Priority values</name>
<c>1</c> <c>Low</c> <thead>
<c>2</c> <c>Normal</c> <tr>
<c>3</c> <c>High</c> <th align="center">Value</th>
<c>4</c> <c>Highest</c> <th align="left">Priority</th>
</texttable> </tr>
<t>Reserved: The 13 bits in the reserved field MUST be set to zero by th </thead>
e sender of the message and MUST be ignored by the receiver.</t> <tbody>
</section> <tr>
<td align="center">0</td>
<section title="REQUEST-STATUS" anchor="sec:format:attributes:req-status"> <td align="left">Lowest</td>
<t>The following is the format of the REQUEST-STATUS attribute.</t> </tr>
<t><figure title="REQUEST-STATUS format" anchor="sec:format:request-stat <tr>
us"> <td align="center">1</td>
<artwork> <td align="left">Low</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left">Normal</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">High</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">Highest</td>
</tr>
</tbody>
</table>
<dl>
<dt>Reserved:</dt> <dd>The 13 bits in the reserved field <bcp14>MUST</
bcp14> be set to zero by the sender of the message and <bcp14>MUST</bcp14> be ig
nored by the receiver.</dd>
</dl>
</section>
<section anchor="sec_format_attributes_req-status" numbered="true" toc="
default">
<name>REQUEST-STATUS</name>
<t>The following is the format of the REQUEST-STATUS attribute.</t>
<figure anchor="sec_format_request-status">
<name>REQUEST-STATUS format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position | |0 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Request Status: This 8-bit field contains the status of the request, <dt>Request Status:</dt> <dd>This 8-bit field contains the status of t
as described in the following table.</t> he request, as described in the following table.</dd></dl>
<texttable title="Request Status values" anchor="tab:requeststatusvalues
">
<ttcol align="center">Value</ttcol>
<ttcol>Status</ttcol>
<c>1</c> <c>Pending</c>
<c>2</c> <c>Accepted</c>
<c>3</c> <c>Granted</c>
<c>4</c> <c>Denied</c>
<c>5</c> <c>Cancelled</c>
<c>6</c> <c>Released</c>
<c>7</c> <c>Revoked</c>
</texttable>
<t>Queue Position: This 8-bit field contains, when applicable, the posit
ion of the floor request in the floor request queue at the server. If the Reques
t Status value is different from Accepted, if the floor control server does not
implement a floor request queue, or if the floor control server does not want to
provide the client with this information, all the bits of this field SHOULD be
set to zero.</t>
<t>A floor request is in Pending state if the floor control server needs
to contact a floor chair in order to accept the floor request, but has not done
it yet. Once the floor control chair accepts the floor request, the floor reque
st is moved to the Accepted state.</t>
</section>
<section title="ERROR-CODE" anchor="sec:format:attributes:error-code"> <table anchor="tab_requeststatusvalues" align="center">
<t>The following is the format of the ERROR-CODE attribute.</t> <name>Request Status values</name>
<t><figure title="ERROR-CODE format" anchor="sec:format:error"> <thead>
<artwork> <tr>
<th align="center">Value</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">1</td>
<td align="left">Pending</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left">Accepted</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">Granted</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">Denied</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left">Cancelled</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left">Released</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left">Revoked</td>
</tr>
</tbody>
</table>
<dl>
<dt>Queue Position:</dt> <dd>This 8-bit field contains, when
applicable, the position of the floor request in the floor request
queue at the server. If the Request Status value is different from
Accepted, if the floor control server does not implement a floor
request queue, or if the floor control server does not want to
provide the client with this information, all the bits of this field
<bcp14>SHOULD</bcp14> be set to zero.</dd>
</dl>
<t>A floor request is in Pending state if the floor control server nee
ds to contact a floor chair in order to accept the floor request, but has not do
ne it yet. Once the floor control chair accepts the floor request, the floor req
uest is moved to the Accepted state.</t>
</section>
<section anchor="sec_format_attributes_error-code" numbered="true" toc="
default">
<name>ERROR-CODE</name>
<t>The following is the format of the ERROR-CODE attribute.</t>
<figure anchor="sec_format_error">
<name>ERROR-CODE format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 0|M| Length | Error Code | | |0 0 0 0 1 1 0|M| Length | Error Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| Error Specific Details | | Error Specific Details |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Error Code: This 8-bit field contains an error code from the followin <dt>Error Code:</dt> <dd>This 8-bit field contains an error code
g table. If an error code is not recognized by the receiver, then the receiver M from the following table. If an error code is not recognized by the
UST assume that an error exists, and therefore that the original message that tr receiver, then the receiver <bcp14>MUST</bcp14> assume that an error
iggered the Error message to be sent is processed, but the nature of the error i exists, and therefore that the original message that triggered the
s unclear.</t> Error message to be sent is processed, but the nature of the error
<texttable title="Error Code meaning" anchor="tab:errorcode"> is unclear.</dd>
<ttcol align="center">Value</ttcol> </dl>
<ttcol>Meaning</ttcol>
<c>1</c> <c>Conference does not Exist</c> <table anchor="tab_errorcode" align="center">
<c>2</c> <c>User does not Exist</c> <name>Error Code meaning</name>
<c>3</c> <c>Unknown Primitive</c> <thead>
<c>4</c> <c>Unknown Mandatory Attribute</c> <tr>
<c>5</c> <c>Unauthorized Operation</c> <th align="center">Value</th>
<c>6</c> <c>Invalid Floor ID</c> <th align="left">Meaning</th>
<c>7</c> <c>Floor Request ID Does Not Exist</c> </tr>
<c>8</c> <c>You have Already Reached the Maximum Number of Ongoing Fl </thead>
oor Requests for this Floor</c> <tbody>
<c>9</c> <c>Use TLS</c> <tr>
<c>10</c> <c>Unable to Parse Message</c> <td align="center">1</td>
<c>11</c> <c>Use DTLS</c> <td align="left">Conference Does Not Exist</td>
<c>12</c> <c>Unsupported Version</c> </tr>
<c>13</c> <c>Incorrect Message Length</c> <tr>
<c>14</c> <c>Generic Error</c> <td align="center">2</td>
</texttable> <td align="left">User Does Not Exist</td>
<t><list style="empty"> </tr>
<tr>
<td align="center">3</td>
<td align="left">Unknown Primitive</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">Unknown Mandatory Attribute</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left">Unauthorized Operation</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left">Invalid Floor ID</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left">Floor Request ID Does Not Exist</td>
</tr>
<tr>
<td align="center">8</td>
<td align="left">You have Already Reached the Maximum Number of
Ongoing Floor Requests for This Floor</td>
</tr>
<tr>
<td align="center">9</td>
<td align="left">Use TLS</td>
</tr>
<tr>
<td align="center">10</td>
<td align="left">Unable to Parse Message</td>
</tr>
<tr>
<td align="center">11</td>
<td align="left">Use DTLS</td>
</tr>
<tr>
<td align="center">12</td>
<td align="left">Unsupported Version</td>
</tr>
<tr>
<td align="center">13</td>
<td align="left">Incorrect Message Length</td>
</tr>
<tr>
<td align="center">14</td>
<td align="left">Generic Error</td>
</tr>
</tbody>
</table>
<aside>
<t>Note: The Generic Error error code is intended to be used when an error occurs and the other specific error codes do not apply.</t> <t>Note: The Generic Error error code is intended to be used when an error occurs and the other specific error codes do not apply.</t>
</list></t> </aside>
<t>Error Specific Details: Present only for certain Error Codes. In this <dl>
document, only for Error Code 4 (Unknown Mandatory Attribute). See <xref target <dt>Error Specific Details:</dt> <dd>Present only for certain error co
="sec:format:attributes:error-code:specific-4"/> for its definition.</t> des. In this document, this field is present only for Error Code 4 (Unknown Mand
<t>Padding: One, two, or three octets of padding added so that the conte atory Attribute). See <xref target="sec_format_attributes_error-code_specific-4"
nts of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 3 format="default"/> for its definition.</dd>
2-bit aligned, no padding is needed.</t> <dt>Padding:</dt> <dd><t>One, two, or three octets of padding added so
<t>The Padding bits MUST be set to zero by the sender and MUST be ignore that the contents of the ERROR-CODE attribute is 32-bit aligned. If the attribu
d by the receiver.</t> te is already 32-bit aligned, no padding is needed.</t>
<t>The Padding bits <bcp14>MUST</bcp14> be set to zero by the sender a
nd <bcp14>MUST</bcp14> be ignored by the receiver.</t></dd>
</dl>
<section title="Error-Specific Details for Error Code 4" anchor="sec:for <section anchor="sec_format_attributes_error-code_specific-4" numbered
mat:attributes:error-code:specific-4"> ="true" toc="default">
<t>The following is the format of the Error-Specific Details field for <name>Error Specific Details for Error Code 4</name>
Error Code 4.</t> <t>The following is the format of the Error Specific Details field f
<t><figure title="Unknown attributes format" anchor="sec:format:unknow or Error Code 4.</t>
n-tlvs"> <figure anchor="sec_format_unknown-tlvs">
<artwork> <name>Unknown attributes format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R| | Unknown Type|R| Unknown Type|R| Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Unknown Type|R| Unknown Type|R| | | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unknown Type|R| Unknown Type|R| | Unknown Type|R| Unknown Type|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t>
<t>Unknown Type: These 7-bit fields contain the Types of the attribute
s (which were present in the message that triggered the Error message) that were
unknown to the receiver.</t>
<t>R: This bit is reserved. It MUST be set to zero by the sender of th
e message and MUST be ignored by the receiver.</t>
</section>
</section>
<section title="ERROR-INFO" anchor="sec:format:attributes:error-info"> <dl><dt>Unknown Type:</dt> <dd>These 7-bit fields contain the Types of the attri
<t>The following is the format of the ERROR-INFO attribute.</t> butes (which were present in the message that triggered the Error message) that
<t><figure title="ERROR-INFO format" anchor="sec:format:error-info"> were unknown to the receiver.</dd>
<artwork>
<dt>Reserved (R):</dt> <dd>This bit is reserved. It <bcp14>MUST</bcp
14> be
set to zero by the sender of the message and <bcp14>MUST</bcp14>
be ignored by the receiver.</dd>
</dl>
</section>
</section>
<section anchor="sec_format_attributes_error-info" numbered="true" toc="
default">
<name>ERROR-INFO</name>
<t>The following is the format of the ERROR-INFO attribute.</t>
<figure anchor="sec_format_error-info">
<name>ERROR-INFO format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 1 1|M| Length | | |0 0 0 0 1 1 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl><dt>Text:</dt> <dd><t>This field contains UTF-8 encoded text <xref ta
<t>Text: This field contains UTF-8 <xref target="RFC3629"/> encoded text rget="RFC3629" format="default"/>.</t>
.</t> <t>In some situations, the contents of the Text field may be generated
<t>In some situations, the contents of the Text field may be generated b by an automaton. If this automaton has information about the preferred language
y an automaton. If this automaton has information about the preferred language o of the receiver of a particular ERROR-INFO attribute, it <bcp14>MAY</bcp14> use
f the receiver of a particular ERROR-INFO attribute, it MAY use this language to this language to generate the Text field.</t></dd>
generate the Text field.</t> <dt>Padding:</dt> <dd>One, two, or three octets of padding added so
<t>Padding: One, two, or three octets of padding added so that the conte that the contents of the ERROR-INFO attribute is 32-bit aligned. The
nts of the ERROR-INFO attribute is 32-bit aligned. The Padding bits MUST be set Padding bits <bcp14>MUST</bcp14> be set to zero by the sender and
to zero by the sender and MUST be ignored by the receiver. If the attribute is a <bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is
lready 32-bit aligned, no padding is needed.</t> already 32-bit aligned, no padding is needed.</dd>
</section> </dl>
</section>
<section title="PARTICIPANT-PROVIDED-INFO" anchor="sec:format:attributes:h <section anchor="sec_format_attributes_human-read-info" numbered="true"
uman-read-info"> toc="default">
<t>The following is the format of the PARTICIPANT-PROVIDED-INFO attribut <name>PARTICIPANT-PROVIDED-INFO</name>
e.</t> <t>The following is the format of the PARTICIPANT-PROVIDED-INFO attrib
<t><figure title="PARTICIPANT-PROVIDED-INFO format" anchor="sec:format:h ute.</t>
uman"> <figure anchor="sec_format_human">
<artwork> <name>PARTICIPANT-PROVIDED-INFO format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0|M| Length | | |0 0 0 1 0 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t>
<t>Text: This field contains UTF-8 <xref target="RFC3629"/> encoded text
.</t>
<t>Padding: One, two, or three octets of padding added so that the conte
nts of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bi
ts MUST be set to zero by the sender and MUST be ignored by the receiver. If the
attribute is already 32-bit aligned, no padding is needed.</t>
</section>
<section title="STATUS-INFO" anchor="sec:format:attributes:status-info"> <dl><dt>Text:</dt> <dd>This field contains UTF-8 encoded text <xref targe
<t>The following is the format of the STATUS-INFO attribute.</t> t="RFC3629" format="default"/>.</dd>
<t><figure title="STATUS-INFO format" anchor="sec:format:status"> <dt>Padding:</dt> <dd>One, two, or three octets of padding added so
<artwork> that the contents of the PARTICIPANT-PROVIDED-INFO attribute is
32-bit aligned. The Padding bits <bcp14>MUST</bcp14> be set to zero
by the sender and <bcp14>MUST</bcp14> be ignored by the receiver. If
the attribute is already 32-bit aligned, no padding is needed.</dd>
</dl>
</section>
<section anchor="sec_format_attributes_status-info" numbered="true" toc=
"default">
<name>STATUS-INFO</name>
<t>The following is the format of the STATUS-INFO attribute.</t>
<figure anchor="sec_format_status">
<name>STATUS-INFO format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 1|M| Length | | |0 0 0 1 0 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl><dt>Text:</dt> <dd><t>This field contains UTF-8 encoded text <xref ta
<t>Text: This field contains UTF-8 <xref target="RFC3629"/> encoded text rget="RFC3629" format="default"/>.</t>
.</t> <t>In some situations, the contents of the Text field may be generated
<t>In some situations, the contents of the Text field may be generated b by an automaton. If this automaton has information about the preferred language
y an automaton. If this automaton has information about the preferred language o of the receiver of a particular STATUS-INFO attribute, it <bcp14>MAY</bcp14> us
f the receiver of a particular STATUS-INFO attribute, it MAY use this language t e this language to generate the Text field.</t></dd>
o generate the Text field.</t> <dt>Padding:</dt> <dd>One, two, or three octets of padding added so
<t>Padding: One, two, or three octets of padding added so that the conte that the contents of the STATUS-INFO attribute is 32-bit
nts of the STATUS-INFO attribute is 32-bit aligned. The Padding bits MUST be set aligned. The Padding bits <bcp14>MUST</bcp14> be set to zero by the
to zero by the sender and MUST be ignored by the receiver. If the attribute is sender and <bcp14>MUST</bcp14> be ignored by the receiver. If the
already 32-bit aligned, no padding is needed.</t> attribute is already 32-bit aligned, no padding is needed.</dd>
</section> </dl>
</section>
<section title="SUPPORTED-ATTRIBUTES" anchor="sec:format:attributes:suppor <section anchor="sec_format_attributes_supported-tlvs" numbered="true" t
ted-tlvs"> oc="default">
<t>The following is the format of the SUPPORTED-ATTRIBUTES attribute.</t <name>SUPPORTED-ATTRIBUTES</name>
> <t>The following is the format of the SUPPORTED-ATTRIBUTES attribute.<
<t><figure title="SUPPORTED-ATTRIBUTES format" anchor="fig:format:suppor /t>
ted-tlvs"> <figure anchor="fig_format_supported-tlvs">
<artwork> <name>SUPPORTED-ATTRIBUTES format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R| |0 0 0 1 0 1 0|M| Length | Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| | Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R| Supp. Attr. |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl><dt>Supp.&nbsp;Attr.:</dt> <dd>These fields contain the
<t>Supp. Attr.: These fields contain the Types of the attributes that ar BFCP attribute types that are supported by the floor control server.
e supported by the floor control server in the following format:</t> See <xref target="tab_attributes" format="default"/> for the list
<t>R: Reserved: This bit MUST be set to zero upon transmission and MUST of BFCP attributes.</dd>
be ignored upon reception.</t> <dt>Reserved (R):</dt> <dd>This bit <bcp14>MUST</bcp14> be set to zero
<t>Padding: One, two, or three octets of padding added so that the conte upon transmission and <bcp14>MUST</bcp14> be ignored upon reception.</dd>
nts of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is <dt>Padding:</dt> <dd><t>One, two, or three octets of padding added so
already 32-bit aligned, no padding is needed.</t> that the contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If t
<t>The Padding bits MUST be set to zero by the sender and MUST be ignore he attribute is already 32-bit aligned, no padding is needed.</t>
d by the receiver.</t> <t>The Padding bits <bcp14>MUST</bcp14> be set to zero by the sender
</section> and <bcp14>MUST</bcp14> be ignored by the receiver.</t></dd>
</dl>
<section title="SUPPORTED-PRIMITIVES" anchor="sec:format:attributes:suppor </section>
ted-reqs"> <section anchor="sec_format_attributes_supported-reqs" numbered="true" t
<t>The following is the format of the SUPPORTED-PRIMITIVES attribute.</t oc="default">
> <name>SUPPORTED-PRIMITIVES</name>
<t><figure title="SUPPORTED-PRIMITIVES format" anchor="fig:format:suppor <t>The following is the format of the SUPPORTED-PRIMITIVES attribute.<
ted-reqs"> /t>
<artwork> <figure anchor="fig_format_supported-reqs">
<name>SUPPORTED-PRIMITIVES format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 1 1|M| Length | Primitive | Primitive | |0 0 0 1 0 1 1|M| Length | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primitive | Primitive | Primitive | Primitive | | Primitive | Primitive | Primitive | Primitive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ / / /
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl><dt>Primitive:</dt> <dd>These fields contain the types of the BFCP m
<t>Primitive: These fields contain the types of the BFCP messages that a essages that are supported by the floor control server. See <xref target="tab_pr
re supported by the floor control server. See <xref target="tab:primitives"/> fo imitives" format="default"/> for the list of BFCP primitives.</dd>
r the list of BFCP primitives.</t> <dt>Padding:</dt> <dd><t>One, two, or three octets of padding added so
<t>Padding: One, two, or three octets of padding added so that the conte that the contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If t
nts of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is he attribute is already 32-bit aligned, no padding is needed.</t>
already 32-bit aligned, no padding is needed.</t> <t>The Padding bits <bcp14>MUST</bcp14> be set to zero by the sender
<t>The Padding bits MUST be set to zero by the sender and MUST be ignore and <bcp14>MUST</bcp14> be ignored by the receiver.</t></dd>
d by the receiver.</t> </dl>
</section> </section>
<section anchor="sec_format_attributes_user-display-name" numbered="true
<section title="USER-DISPLAY-NAME" anchor="sec:format:attributes:user-disp " toc="default">
lay-name"> <name>USER-DISPLAY-NAME</name>
<t>The following is the format of the USER-DISPLAY-NAME attribute.</t> <t>The following is the format of the USER-DISPLAY-NAME attribute.</t>
<t><figure title="USER-DISPLAY-NAME format" anchor="sec:format:user-disp <figure anchor="sec_format_user-display">
lay"> <name>USER-DISPLAY-NAME format</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 0|M| Length | | |0 0 0 1 1 0 0|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl><dt>Text:</dt> <dd>This field contains the UTF-8 encoded name of the
<t>Text: This field contains the UTF-8 encoded name of the user.</t> user.</dd>
<t>Padding: One, two, or three octets of padding added so that the conte <dt>Padding:</dt> <dd>One, two, or three octets of padding added so
nts of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits MUST that the contents of the USER-DISPLAY-NAME attribute is 32-bit
be set to zero by the sender and MUST be ignored by the receiver. If the attribu aligned. The Padding bits <bcp14>MUST</bcp14> be set to zero by the
te is already 32-bit aligned, no padding is needed.</t> sender and <bcp14>MUST</bcp14> be ignored by the receiver. If the
</section> attribute is already 32-bit aligned, no padding is needed.</dd>
</dl>
<section title="USER-URI" anchor="sec:format:attributes:user-uri"> </section>
<t>The following is the format of the USER-URI attribute.</t> <section anchor="sec_format_attributes_user-uri" numbered="true" toc="de
<t><figure title="USER-URI format" anchor="sec:format:user-uri"> fault">
<artwork> <name>USER-URI</name>
<t>The following is the format of the USER-URI attribute.</t>
<figure anchor="sec_format_user-uri">
<name>USER-URI format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 0 1|M| Length | | |0 0 0 1 1 0 1|M| Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Text / / Text /
/ +-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+
| | Padding | | | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Text: This field contains the UTF-8 encoded user's contact URI, that <dt>Text:</dt> <dd>This field contains the UTF-8 encoded user's contac
is, the URI used by the user to set up the resources (e.g., media streams) that t URI, that is, the URI used by the user to set up the resources (e.g., media st
are controlled by BFCP. For example, in the context of a conference set up by SI reams) that are controlled by BFCP. For example, in the context of a conference
P, the USER-URI attribute would carry the SIP URI of the user.</t> set up by SIP, the USER-URI attribute would carry the SIP URI of the user.</dd><
<t><list style="hanging"> /dl>
<aside>
<t>Messages containing a user's URI in a USER-URI attribute also con tain the user's User ID. This way, a client receiving such a message can correla te the user's URI (e.g., the SIP URI the user used to join a conference) with th e user's User ID.</t> <t>Messages containing a user's URI in a USER-URI attribute also con tain the user's User ID. This way, a client receiving such a message can correla te the user's URI (e.g., the SIP URI the user used to join a conference) with th e user's User ID.</t>
</list></t> </aside>
<t>Padding: One, two, or three octets of padding added so that the conte <dl>
nts of the USER-URI attribute is 32-bit aligned. The Padding bits MUST be set to <dt>Padding:</dt> <dd>One, two, or three octets of padding added so
zero by the sender and MUST be ignored by the receiver. If the attribute is alr that the contents of the USER-URI attribute is 32-bit aligned. The
eady 32-bit aligned, no padding is needed.</t> Padding bits <bcp14>MUST</bcp14> be set to zero by the sender and
</section> <bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is
already 32-bit aligned, no padding is needed.</dd>
<section title="BENEFICIARY-INFORMATION" anchor="sec:format:attributes:ben </dl>
-info"> </section>
<t>The BENEFICIARY-INFORMATION attribute is a grouped attribute that con <section anchor="sec_format_attributes_ben-info" numbered="true" toc="de
sists of a header, which is referred to as BENEFICIARY-INFORMATION-HEADER, follo fault">
wed by a sequence of attributes. The following is the format of the BENEFICIARY- <name>BENEFICIARY-INFORMATION</name>
INFORMATION-HEADER:</t> <t>The BENEFICIARY-INFORMATION attribute is a grouped attribute that c
<t><figure title="BENEFICIARY-INFORMATION-HEADER format" anchor="fig:for onsists of a header, which is referred to as BENEFICIARY-INFORMATION-HEADER, fol
mat:ben-information-header"> lowed by a sequence of attributes. The following is the format of the BENEFICIAR
<artwork> Y-INFORMATION-HEADER:</t>
<figure anchor="fig_format_ben-information-header">
<name>BENEFICIARY-INFORMATION-HEADER format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 0|M| Length | Beneficiary ID | |0 0 0 1 1 1 0|M| Length | Beneficiary ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Beneficiary ID: This field contains a 16-bit value that uniquely iden <dt>Beneficiary ID:</dt> <dd>This field contains a 16-bit value that u
tifies a user within a conference.</t> niquely identifies a user within a conference.</dd></dl>
<t>The following is the ABNF (Augmented Backus-Naur Form) <xref target=" <t>The following is the ABNF (Augmented Backus-Naur Form) <xref
RFC5234"/> of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUT target="RFC5234" format="default"/> of the BENEFICIARY-INFORMATION
E refers to extension attributes that may be defined in the future.)</t> grouped attribute. (EXTENSION-ATTRIBUTE refers to extension
<t><figure title="BENEFICIARY-INFORMATION format" anchor="fig:ben-inform attributes that may be defined in the future.)</t>
ation">
<artwork>
BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER
[USER-DISPLAY-NAME]
[USER-URI]
*EXTENSION-ATTRIBUTE
</artwork>
</figure></t>
</section>
<section title="FLOOR-REQUEST-INFORMATION" anchor="sec:format:attributes:f <figure anchor="fig_ben-information">
loor-req-info"> <name>BENEFICIARY-INFORMATION format</name>
<t>The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that c <sourcecode name="" type="abnf"><![CDATA[
onsists of a header, which is referred to as FLOOR-REQUEST-INFORMATION-HEADER, f BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER
ollowed by a sequence of attributes. The following is the format of the FLOOR-RE [USER-DISPLAY-NAME]
QUEST-INFORMATION-HEADER:</t> [USER-URI]
<t><figure title="FLOOR-REQUEST-INFORMATION-HEADER format" anchor="fig:f *EXTENSION-ATTRIBUTE]]></sourcecode>
ormat:request-information-header"> </figure>
<artwork> </section>
<section anchor="sec_format_attributes_floor-req-info" numbered="true" t
oc="default">
<name>FLOOR-REQUEST-INFORMATION</name>
<t>The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that
consists of a header, which is referred to as FLOOR-REQUEST-INFORMATION-HEADER,
followed by a sequence of attributes. The following is the format of the FLOOR-
REQUEST-INFORMATION-HEADER:</t>
<figure anchor="fig_format_request-information-header">
<name>FLOOR-REQUEST-INFORMATION-HEADER format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1|M| Length | Floor Request ID | |0 0 0 1 1 1 1|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Floor Request ID: This field contains a 16-bit value that identifies <dt>Floor Request ID:</dt> <dd>This field contains a 16-bit value
a floor request at the floor control server.</t> that identifies a floor request at the floor control server.</dd>
<t>The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped at </dl>
tribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined <t>The following is the ABNF of the FLOOR-REQUEST-INFORMATION
in the future.)</t> grouped attribute. (EXTENSION-ATTRIBUTE refers to extension
<t><figure title="FLOOR-REQUEST-INFORMATION format" anchor="fig:floor-re attributes that may be defined in the future.)</t>
quest-information"> <figure anchor="fig_floor-request-information">
<artwork> <name>FLOOR-REQUEST-INFORMATION format</name>
<sourcecode name="" type="abnf"><![CDATA[
FLOOR-REQUEST-INFORMATION = FLOOR-REQUEST-INFORMATION-HEADER FLOOR-REQUEST-INFORMATION = FLOOR-REQUEST-INFORMATION-HEADER
[OVERALL-REQUEST-STATUS] [OVERALL-REQUEST-STATUS]
1*FLOOR-REQUEST-STATUS 1*FLOOR-REQUEST-STATUS
[BENEFICIARY-INFORMATION] [BENEFICIARY-INFORMATION]
[REQUESTED-BY-INFORMATION] [REQUESTED-BY-INFORMATION]
[PRIORITY] [PRIORITY]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
*EXTENSION-ATTRIBUTE *EXTENSION-ATTRIBUTE]]></sourcecode>
</artwork> </figure>
</figure></t> </section>
</section> <section anchor="sec_format_attributes_req-by-info" numbered="true" toc=
"default">
<section title="REQUESTED-BY-INFORMATION" anchor="sec:format:attributes:re <name>REQUESTED-BY-INFORMATION</name>
q-by-info"> <t>The REQUESTED-BY-INFORMATION attribute is a grouped attribute that
<t>The REQUESTED-BY-INFORMATION attribute is a grouped attribute that co consists of a header, which is referred to as REQUESTED-BY-INFORMATION-HEADER, f
nsists of a header, which is referred to as REQUESTED-BY-INFORMATION-HEADER, fol ollowed by a sequence of attributes. The following is the format of the REQUESTE
lowed by a sequence of attributes. The following is the format of the REQUESTED- D-BY-INFORMATION-HEADER:</t>
BY-INFORMATION-HEADER:</t> <figure anchor="fig_format_req-by-information-header">
<t><figure title="REQUESTED-BY-INFORMATION-HEADER format" anchor="fig:fo <name>REQUESTED-BY-INFORMATION-HEADER format</name>
rmat:req-by-information-header"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0|M| Length | Requested-by ID | |0 0 1 0 0 0 0|M| Length | Requested-by ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Requested-by ID: This field contains a 16-bit value that uniquely ide <dt>Requested-by ID:</dt> <dd>This field contains a 16-bit value
ntifies a user within a conference.</t> that uniquely identifies a user within a conference.</dd>
<t>The following is the ABNF of the REQUESTED-BY-INFORMATION grouped att </dl>
ribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined <t>The following is the ABNF of the REQUESTED-BY-INFORMATION grouped
in the future.)</t> attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
<t><figure title="REQUESTED-BY-INFORMATION format" anchor="fig:reqby-inf may be defined in the future.)</t>
ormation">
<artwork>
REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER
[USER-DISPLAY-NAME]
[USER-URI]
*EXTENSION-ATTRIBUTE
</artwork>
</figure></t>
</section>
<section title="FLOOR-REQUEST-STATUS" anchor="sec:format:attributes:floor- <figure anchor="fig_reqby-information">
req-status"> <name>REQUESTED-BY-INFORMATION format</name>
<t>The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consis <sourcecode name="" type="abnf"><![CDATA[
ts of a header, which is referred to as FLOOR-REQUEST-STATUS-HEADER, followed by REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER
a sequence of attributes. The following is the format of the FLOOR-REQUEST-STAT [USER-DISPLAY-NAME]
US-HEADER:</t> [USER-URI]
<t><figure title="FLOOR-REQUEST-STATUS-HEADER format" anchor="fig:format *EXTENSION-ATTRIBUTE]]></sourcecode>
:floor-req-status-header"> </figure>
<artwork> </section>
<section anchor="sec_format_attributes_floor-req-status" numbered="true"
toc="default">
<name>FLOOR-REQUEST-STATUS</name>
<t>The FLOOR-REQUEST-STATUS attribute is a grouped attribute that cons
ists of a header, which is referred to as FLOOR-REQUEST-STATUS-HEADER, followed
by a sequence of attributes. The following is the format of the FLOOR-REQUEST-ST
ATUS-HEADER:</t>
<figure anchor="fig_format_floor-req-status-header">
<name>FLOOR-REQUEST-STATUS-HEADER format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 1|M| Length | Floor ID | |0 0 1 0 0 0 1|M| Length | Floor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Floor ID: this field contains a 16-bit value that uniquely identifies <dt>Floor ID:</dt> <dd>this field contains a 16-bit value that
a floor within a conference.</t> uniquely identifies a floor within a conference.</dd>
<t>The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribu </dl>
te. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in t <t>The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attri
he future.)</t> bute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in
<t><figure title="FLOOR-REQUEST-STATUS format" anchor="fig:floor-req-sta the future.)</t>
tus"> <figure anchor="fig_floor-req-status">
<artwork> <name>FLOOR-REQUEST-STATUS format</name>
FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER <sourcecode name="" type="abnf"><![CDATA[
[REQUEST-STATUS] FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER
[STATUS-INFO] [REQUEST-STATUS]
*EXTENSION-ATTRIBUTE [STATUS-INFO]
</artwork> *EXTENSION-ATTRIBUTE]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="sec_format_attributes_overall-req-status" numbered="tru
<section title="OVERALL-REQUEST-STATUS" anchor="sec:format:attributes:over e" toc="default">
all-req-status"> <name>OVERALL-REQUEST-STATUS</name>
<t>The OVERALL-REQUEST-STATUS attribute is a grouped attribute that cons <t>The OVERALL-REQUEST-STATUS attribute is a grouped attribute that co
ists of a header, which is referred to as OVERALL-REQUEST-STATUS-HEADER, followe nsists of a header, which is referred to as OVERALL-REQUEST-STATUS-HEADER, follo
d by a sequence of attributes. The following is the format of the OVERALL-REQUES wed by a sequence of attributes. The following is the format of the OVERALL-REQU
T-STATUS-HEADER:</t> EST-STATUS-HEADER:</t>
<t><figure title="OVERALL-REQUEST-STATUS-HEADER format" anchor="fig:form <figure anchor="fig_format_overall-req-status-header">
at:overall-req-status-header"> <name>OVERALL-REQUEST-STATUS-HEADER format</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 1 0|M| Length | Floor Request ID | |0 0 1 0 0 1 0|M| Length | Floor Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> </figure>
</figure></t> <dl>
<t>Floor Request ID: this field contains a 16-bit value that identifies <dt>Floor Request ID:</dt> <dd>This field contains a 16-bit value that
a floor request at the floor control server.</t> identifies a floor request at the floor control server.</dd></dl>
<t>The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attri <t>The following is the ABNF of the OVERALL-REQUEST-STATUS grouped att
bute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in ribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined
the future.)</t> in the future.)</t>
<t><figure title="OVERALL-REQUEST-STATUS format" anchor="fig:overall-req <figure anchor="fig_overall-req-status">
-status"> <name>OVERALL-REQUEST-STATUS format</name>
<artwork> <sourcecode name="" type="abnf"><![CDATA[
OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER
[REQUEST-STATUS] [REQUEST-STATUS]
[STATUS-INFO] [STATUS-INFO]
*EXTENSION-ATTRIBUTE *EXTENSION-ATTRIBUTE]]></sourcecode>
</artwork> </figure>
</figure></t> </section>
</section> </section>
</section> <section anchor="sec_msg_format" numbered="true" toc="default">
<name>Message Format</name>
<section title="Message Format" anchor="sec:msg_format"> <t>This section contains the normative ABNF (Augmented Backus-Naur Form)
<t>This section contains the normative ABNF (Augmented Backus-Naur Form) < <xref target="RFC5234" format="default"/> of the BFCP messages. Extension attri
xref target="RFC5234"/> of the BFCP messages. Extension attributes that may be d butes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE i
efined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.</t> n the ABNF.</t>
<section anchor="sec_msg_format_FloorRequest" numbered="true" toc="defau
<section title="FloorRequest" anchor="sec:msg_format:FloorRequest"> lt">
<t>Floor participants request a floor by sending a FloorRequest message <name>FloorRequest</name>
to the floor control server. The following is the format of the FloorRequest mes <t>Floor participants request a floor by sending a FloorRequest messag
sage:</t> e to the floor control server. The following is the format of the FloorRequest m
<t><figure title="FloorRequest format" anchor="fig:floorequest"> essage:</t>
<artwork> <figure anchor="fig_floorequest">
<name>FloorRequest format</name>
<sourcecode name="" type="abnf"><![CDATA[
FloorRequest = COMMON-HEADER FloorRequest = COMMON-HEADER
1*FLOOR-ID 1*FLOOR-ID
[BENEFICIARY-ID] [BENEFICIARY-ID]
[PARTICIPANT-PROVIDED-INFO] [PARTICIPANT-PROVIDED-INFO]
[PRIORITY] [PRIORITY]
*EXTENSION-ATTRIBUTE *EXTENSION-ATTRIBUTE]]></sourcecode>
</artwork> </figure>
</figure></t> </section>
</section> <section anchor="sec_msg_format_FloorRelease" numbered="true" toc="defau
lt">
<section title="FloorRelease" anchor="sec:msg_format:FloorRelease"> <name>FloorRelease</name>
<t>Floor participants release a floor by sending a FloorRelease message <t>Floor participants release a floor by sending a FloorRelease messag
to the floor control server. Floor participants also use the FloorRelease messag e to the floor control server. Floor participants also use the FloorRelease mess
e to cancel pending floor requests. The following is the format of the FloorRele age to cancel pending floor requests. The following is the format of the FloorRe
ase message:</t> lease message:</t>
<t><figure title="FloorRelease format" anchor="fig:floorelease"> <figure anchor="fig_floorelease">
<artwork> <name>FloorRelease format</name>
FloorRelease = COMMON-HEADER <sourcecode name="" type="abnf"><![CDATA[
FLOOR-REQUEST-ID FloorRelease = COMMON-HEADER
*EXTENSION-ATTRIBUTE FLOOR-REQUEST-ID
</artwork> *EXTENSION-ATTRIBUTE]]></sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="sec_msg_format_FloorRequestQuery" numbered="true" toc="
<section title="FloorRequestQuery" anchor="sec:msg_format:FloorRequestQuer default">
y"> <name>FloorRequestQuery</name>
<t>Floor participants and floor chairs request information about a floor <t>Floor participants and floor chairs request information about a flo
request by sending a FloorRequestQuery message to the floor control server. The or request by sending a FloorRequestQuery message to the floor control server. T
following is the format of the FloorRequestQuery message:</t> he following is the format of the FloorRequestQuery message:</t>
<t><figure title="FloorRequestQuery format" anchor="fig:floorrequestinfo <figure anchor="fig_floorrequestinfo">
"> <name>FloorRequestQuery format</name>
<artwork> <sourcecode name="" type="abnf"><![CDATA[
FloorRequestQuery = COMMON-HEADER FloorRequestQuery = COMMON-HEADER
FLOOR-REQUEST-ID FLOOR-REQUEST-ID
*EXTENSION-ATTRIBUTE *EXTENSION-ATTRIBUTE]]></sourcecode>
</artwork> </figure>
</figure></t> </section>
</section> <section anchor="sec_msg_format_FloorRequestStatus" numbered="true" toc=
"default">
<section title="FloorRequestStatus" anchor="sec:msg_format:FloorRequestSta <name>FloorRequestStatus</name>
tus"> <t>The floor control server informs floor participants and floor chair
<t>The floor control server informs floor participants and floor chairs s about the status of their floor requests by sending them FloorRequestStatus me
about the status of their floor requests by sending them FloorRequestStatus mess ssages. The following is the format of the FloorRequestStatus message:</t>
ages. The following is the format of the FloorRequestStatus message:</t> <figure anchor="fig_floorrequeststatus">
<t><figure title="FloorRequestStatus format" anchor="fig:floorrequeststa <name>FloorRequestStatus format</name>
tus"> <sourcecode name="" type="abnf"><![CDATA[
<artwork> FloorRequestStatus = COMMON-HEADER
FloorRequestStatus = COMMON-HEADER FLOOR-REQUEST-INFORMATION
FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE]]></sourcecode>
*EXTENSION-ATTRIBUTE </figure>
</artwork> </section>
</figure></t> <section anchor="sec_msg_format_UserQuery" numbered="true" toc="default"
</section> >
<name>UserQuery</name>
<section title="UserQuery" anchor="sec:msg_format:UserQuery"> <t>Floor participants and floor chairs request information about a par
<t>Floor participants and floor chairs request information about a parti ticipant and the floor requests related to this participant by sending a UserQue
cipant and the floor requests related to this participant by sending a UserQuery ry message to the floor control server. The following is the format of the UserQ
message to the floor control server. The following is the format of the UserQue uery message:</t>
ry message:</t> <figure anchor="fig_userinfowanted">
<t><figure title="UserQuery format" anchor="fig:userinfowanted"> <name>UserQuery format</name>
<artwork> <sourcecode name="" type="abnf"><![CDATA[
UserQuery = COMMON-HEADER UserQuery = COMMON-HEADER
[BENEFICIARY-ID] [BENEFICIARY-ID]
*EXTENSION-ATTRIBUTE *EXTENSION-ATTRIBUTE]]></sourcecode>
</artwork> </figure>
</figure></t> </section>
</section> <section anchor="sec_msg_format_UserStatus" numbered="true" toc="default
">
<section title="UserStatus" anchor="sec:msg_format:UserStatus"> <name>UserStatus</name>
<t>The floor control server provides information about participants and <t>The floor control server provides information about participants an
their related floor requests to floor participants and floor chairs by sending t d their related floor requests to floor participants and floor chairs by sending
hem UserStatus messages. The following is the format of the UserStatus message:< them UserStatus messages. The following is the format of the UserStatus message
/t> :</t>
<t><figure title="UserStatus format" anchor="fig:userstatus"> <figure anchor="fig_userstatus">
<artwork> <name>UserStatus format</name>
UserStatus = COMMON-HEADER <sourcecode name="" type="abnf"><![CDATA[
[BENEFICIARY-INFORMATION] UserStatus = COMMON-HEADER
[BENEFICIARY-INFORMATION]
*FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE]]></sourcecode>
</figure>
</section>
<section anchor="sec_msg_format_FloorQuery" numbered="true" toc="default
">
<name>FloorQuery</name>
<t>Floor participants and floor chairs request information about a flo
or or floors by sending a FloorQuery message to the floor control server. The fo
llowing is the format of the FloorQuery message:</t>
<figure anchor="fig_floorinfo">
<name>FloorQuery format</name>
<sourcecode name="" type="abnf"><![CDATA[
FloorQuery = COMMON-HEADER
*FLOOR-ID
*EXTENSION-ATTRIBUTE]]></sourcecode>
</figure>
</section>
<section anchor="sec_msg_format_FloorStatus" numbered="true" toc="defaul
t">
<name>FloorStatus</name>
<t>The floor control server informs floor participants and floor chair
s about the status (e.g., the current holder) of a floor by sending them FloorSt
atus messages. The following is the format of the FloorStatus message:</t>
<figure anchor="fig_floorstatus">
<name>FloorStatus format</name>
<sourcecode name="" type="abnf"><![CDATA[
FloorStatus = COMMON-HEADER
*FLOOR-ID
*FLOOR-REQUEST-INFORMATION *FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE *EXTENSION-ATTRIBUTE]]></sourcecode>
</artwork> </figure>
</figure></t> </section>
<section anchor="sec_msg_format_ChairAction" numbered="true" toc="defaul
t">
<name>ChairAction</name>
<t>Floor chairs send instructions to floor control servers by sending
them ChairAction messages. The following is the format of the ChairAction messag
e:</t>
<figure anchor="fig_chairaction">
<name>ChairAction format</name>
<sourcecode name="" type="abnf"><![CDATA[
ChairAction = COMMON-HEADER
FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE]]></sourcecode>
</figure>
</section>
<section anchor="sec_msg_format_ChairActionAck" numbered="true" toc="def
ault">
<name>ChairActionAck</name>
<t>Floor control servers confirm that they have accepted a ChairAction
message by sending a ChairActionAck message. The following is the format of the
ChairActionAck message:</t>
<figure anchor="fig_chairactionack">
<name>ChairActionAck format</name>
<sourcecode name="" type="abnf"><![CDATA[
ChairActionAck = COMMON-HEADER
*EXTENSION-ATTRIBUTE]]></sourcecode>
</figure>
</section>
<section anchor="sec_msg_format_Hello" numbered="true" toc="default">
<name>Hello</name>
<t>Floor participants and floor chairs <bcp14>MAY</bcp14> check the li
veness of floor control servers by sending a Hello message. Additionally, clien
ts communicating with a floor control server over an unreliable transport use th
e Hello message to initiate communication with the server. The following is the
format of the Hello message:</t>
<figure anchor="fig_hello">
<name>Hello format</name>
<sourcecode name="" type="abnf"><![CDATA[
Hello = COMMON-HEADER
*EXTENSION-ATTRIBUTE]]></sourcecode>
</figure>
</section>
<section anchor="sec_msg_format_HelloAck" numbered="true" toc="default">
<name>HelloAck</name>
<t>Floor control servers confirm that they are alive on reception of a
Hello message by sending a HelloAck message. The following is the format of the
HelloAck message:</t>
<figure anchor="fig_helloack">
<name>HelloAck format</name>
<sourcecode name="" type="abnf"><![CDATA[
HelloAck = COMMON-HEADER
SUPPORTED-PRIMITIVES
SUPPORTED-ATTRIBUTES
*EXTENSION-ATTRIBUTE]]></sourcecode>
</figure>
</section>
<section anchor="sec_msg_format_Error" numbered="true" toc="default">
<name>Error</name>
<t>Floor control servers inform floor participants and floor chairs ab
out errors processing requests by sending them Error messages. The following is
the format of the Error message:</t>
<figure anchor="fig_error">
<name>Error format</name>
<sourcecode name="" type="abnf"><![CDATA[
Error = COMMON-HEADER
ERROR-CODE
[ERROR-INFO]
*EXTENSION-ATTRIBUTE]]></sourcecode>
</figure>
</section>
<section numbered="true" toc="default">
<name>FloorRequestStatusAck</name>
<t>When communicating over an unreliable transport, floor participants
and chairs acknowledge the receipt of a subsequent FloorRequestStatus message f
rom the floor control server (cf.&nbsp;<xref target="sec_server_request_subseque
nt" format="default"/>) by sending a FloorRequestStatusAck message. The followin
g is the format of the FloorRequestStatusAck message:</t>
<figure anchor="FloorRequestStatusAck">
<name>FloorRequestStatusAck format</name>
<sourcecode name="" type="abnf"><![CDATA[
FloorRequestStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE ]]></sourcecode>
</figure>
</section>
<section numbered="true" toc="default">
<name>FloorStatusAck</name>
<t>When communicating over an unreliable transport, floor participants
and chairs acknowledge the receipt of a subsequent FloorStatus message from the
floor control server (cf.&nbsp;<xref target="sec_server_floorinfo_subsequent" f
ormat="default"/>) by sending a FloorStatusAck message. The following is the for
mat of the FloorStatusAck message:</t>
<figure anchor="FloorStatusAck">
<name>FloorStatusAck format</name>
<sourcecode name="" type="abnf"><![CDATA[
FloorStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE ]]></sourcecode>
</figure>
</section>
<section numbered="true" toc="default">
<name>Goodbye</name>
<t>BFCP entities communicating over an unreliable transport that wish
to dissociate themselves from their remote participant do so through the transmi
ssion of a Goodbye. The following is the format of the Goodbye message:</t>
<figure anchor="Goodbye">
<name>Goodbye format</name>
<sourcecode name="" type="abnf"><![CDATA[
Goodbye = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE ]]></sourcecode>
</figure>
</section>
<section numbered="true" toc="default">
<name>GoodbyeAck</name>
<t>BFCP entities communicating over an unreliable transport acknowledg
e the receipt of a Goodbye message from a peer. The following is the format of t
he GoodbyeAck message:</t>
<figure anchor="GoodbyeAck">
<name>GoodbyeAck format</name>
<sourcecode name="" type="abnf"><![CDATA[
GoodbyeAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE ]]></sourcecode>
</figure>
</section>
</section> </section>
</section>
<section title="FloorQuery" anchor="sec:msg_format:FloorQuery"> <section anchor="sec_transport" numbered="true" toc="default">
<t>Floor participants and floor chairs request information about a floor <name>Transport</name>
or floors by sending a FloorQuery message to the floor control server. The foll <t>The transport over which BFCP entities exchange messages depends on the
owing is the format of the FloorQuery message:</t> information the clients obtain for contacting the floor control server, as desc
<t><figure title="FloorQuery format" anchor="fig:floorinfo"> ribed in <xref target="sec_scope_info" format="default"/>. Two transports are su
<artwork> pported: TCP, which is appropriate where connectivity is not impeded by network
FloorQuery = COMMON-HEADER elements such as NAT devices or media relays; and UDP for those deployments wher
*FLOOR-ID e TCP may not be applicable or appropriate.</t>
*EXTENSION-ATTRIBUTE <aside>
</artwork> <t>Note: In practice, products are configured to try one transport first
</figure></t> and then use the other transport as a fallback. Whether TCP or UDP is chosen as
underlying transport depends on the type of product and the deployment environm
ent. See <xref target="app_motivation" format="default"/> for additional conside
rations.</t>
</aside>
<section anchor="tcp_transport" numbered="true" toc="default">
<name>Reliable Transport</name>
<t>BFCP entities may elect to exchange BFCP messages using TCP connectio
ns. TCP provides an in-order reliable delivery of a stream of bytes. Consequentl
y, message framing needs to be implemented in the application layer. BFCP implem
ents application-layer framing using TLV-encoded attributes.</t>
<t>A client <bcp14>MUST NOT</bcp14> use more than one TCP connection to
communicate with a given floor control server within a conference. Nevertheless,
if the same physical box handles different clients (e.g., a floor chair and a f
loor participant), which are identified by different User IDs, a separate connec
tion per client is allowed.</t>
<t>If a BFCP entity (a client or a floor control server) receives data t
hat cannot be parsed, the entity <bcp14>MUST</bcp14> close the TCP connection, a
nd the connection <bcp14>SHOULD</bcp14> be reestablished. Similarly, if a TCP co
nnection cannot deliver a BFCP message and times out or receives an ICMP port un
reachable message mid-connection, the TCP connection <bcp14>SHOULD</bcp14> be re
established.</t>
<t>The way connection reestablishment is handled depends on how the clie
nt obtains information to contact the floor control server. Once the TCP connect
ion is reestablished, the client <bcp14>MAY</bcp14> resend those messages for wh
ich it did not get a response from the floor control server.</t>
<t>If a floor control server detects that the TCP connection towards one
of the floor participants is lost, it is up to the local policy of the floor co
ntrol server what to do with the pending floor requests of the floor participant
. In any case, it is <bcp14>RECOMMENDED</bcp14> that the floor control server ke
ep the floor requests (i.e., that it does not cancel them) while the TCP connect
ion is reestablished.</t>
<t>If a client wishes to end its BFCP connection with a floor control se
rver, the client closes (i.e., a graceful close) the TCP connection towards the
floor control server. If a floor control server wishes to end its BFCP connecti
on with a client (e.g., the focus of the conference informs the floor control se
rver that the client has been kicked out of the conference), the floor control s
erver closes (i.e., a graceful close) the TCP connection towards the client.</t>
<t>In cases where a BFCP entity reestablishes a connection due to protoc
ol errors as described above, the entity <bcp14>SHOULD NOT</bcp14> repeatedly re
establish the connection. Rather, if the same protocol errors persist, the enti
ty <bcp14>MUST</bcp14> cease attempts and <bcp14>SHOULD</bcp14> report the error
to the human user and/or log the event. This does not preclude the entity from
reestablishing a connection when facing a different set of errors. That said,
entities <bcp14>MUST</bcp14> avoid overloading the server with reestablishment r
equests. A connection <bcp14>MUST NOT</bcp14> be reestablished too frequently.
The frequency is a matter of implementation, but <bcp14>SHOULD NOT</bcp14> be a
ttempted more than once in a 30 second period of time.</t>
</section> </section>
<section anchor="udp_transport" numbered="true" toc="default">
<name>Unreliable Transport</name>
<t>BFCP entities may elect to exchange BFCP messages using UDP datagrams
. UDP is an unreliable transport where neither delivery nor ordering is assured.
Each BFCP UDP datagram <bcp14>MUST</bcp14> contain exactly one BFCP message or
message fragment. To keep large BFCP messages from being fragmented at the IP la
yer, the fragmentation of BFCP messages that exceed the path MTU size is perform
ed at the BFCP level. Considerations related to fragmentation are covered in <xr
ef target="fragmentation_handling" format="default"/>. The message format for BF
CP messages is the same regardless of whether the messages are sent in UDP datag
rams or over a TCP stream.</t>
<t>Clients <bcp14>MUST</bcp14> announce their presence to the floor cont
rol server by sending a Hello message. The floor control server responds to the
Hello message with a HelloAck message. The client considers the floor control se
rver as present and available only upon receiving the HelloAck message. The beha
vior when timers fire, including the determination that a connection is broken,
is described in <xref target="timers" format="default"/>.</t>
<t>As described in <xref target="sec_transactions" format="default"/>, e
ach request sent by a floor participant or chair forms a client transaction that
expects an acknowledgement message from the floor control server within a trans
action failure window. Concordantly, messages sent by the floor control server
that initiate new transactions (e.g., FloorStatus announcements as part of a Fl
oorQuery subscription) require acknowledgement messages from the floor participa
nt and chair entities to which they were sent.</t>
<section title="FloorStatus" anchor="sec:msg_format:FloorStatus"> <t>If a floor control server receives data that cannot be parsed, the re
<t>The floor control server informs floor participants and floor chairs ceiving server <bcp14>MUST</bcp14> send an Error message with parameter value 10
about the status (e.g., the current holder) of a floor by sending them FloorStat (Unable to Parse Message) indicating receipt of a malformed message, given that
us messages. The following is the format of the FloorStatus message:</t> it is possible to parse the received message to such an extent that an Error me
<t><figure title="FloorStatus format" anchor="fig:floorstatus"> ssage may be built.</t>
<artwork> <t>Entities <bcp14>MUST</bcp14> have at most one outstanding request tra
FloorStatus = COMMON-HEADER nsaction per peer at any one time. Implicit subscriptions occur for a client-in
*FLOOR-ID itiated request transaction whose acknowledgement is implied by the first server
*FLOOR-REQUEST-INFORMATION -initiated response for that transaction, followed by zero of more subsequent se
*EXTENSION-ATTRIBUTE rver-initiated messages corresponding to the same transaction. An example is a F
</artwork> loorRequest message for which there are potentially multiple responses from the
</figure></t> floor control server as it processes intermediate states until a terminal state
(e.g., Granted or Denied) is attained. The subsequent changes in state for the r
equest are new transactions whose Transaction ID is determined by the floor cont
rol server and whose receipt by the client participant is acknowledged with a Fl
oorRequestStatusAck message.</t>
<t>By restricting entities to having at most one pending transaction ope
n in a BFCP connection, both the out-of-order receipt of messages as well as the
possibility for congestion are mitigated. Additional details regarding congesti
on control are provided in <xref target="congestion" format="default"/>.
If a participant receives a server-initiated request (e.g., a
FloorStatus from the floor control server) while waiting for a
response to a client-initiated transaction (e.g., the participant
sent a FloorRequest and is waiting for a FloorRequestStatus
response), then the participant <bcp14>MUST</bcp14> treat the server-initiate
d
request as superseding any response to its client-initiated
transaction.
As the floor control server cannot send a second update to the implicit floor st
atus subscription until the first is acknowledged, ordinality is maintained.</t>
<t>If a client wishes to end its BFCP connection with a floor control se
rver, it is <bcp14>REQUIRED</bcp14> that the client send a Goodbye message to di
ssociate itself from any allocated resources. If a floor control server wishes t
o end its BFCP connection with a client (e.g., the focus of the conference infor
ms the floor control server that the client has been kicked out from the confere
nce), it is <bcp14>REQUIRED</bcp14> that the floor control server send a Goodbye
message towards the client.</t>
<!-- [auth] Commented out. RFC 5018 behaviour for unreliable transport i
s explicitly not supported, cf. anchor="sec:scope:info". In the unlikely case we
need UDP/DTLS support outside offer/answer, a RFC5018bis is needed.
<t>RFC 5018 <xref target="RFC5018"/> specifies how to establish a TCP
connection to a floor control server outside the context of an offer/answer exc
hange. When using UDP the same set of data is needed for a BFCP connection as li
sted in <xref target="RFC5018"/>, Section 3, i.e. transport address of the serve
r, the conference identifier, and the user identifier. The procedures and consid
erations for resolving a host name into an IP address also applies to BFCP over
an unreliable transport. In <xref target="RFC5018"/>, Section 4 applies, but whe
n using BFCP over an unreliable transport the floor control server that receives
a BFCP message over UDP (no DTLS) <bcp14>SHOULD</bcp14> request the use of DTLS
by generating an Error message with an Error code with a value of 11 (Use DTLS)
. A floor control server that is configured to require DTLS <bcp14>MUST</bcp14>
request the use of DTLS this way. The recommendations for authentication in <xre
f target="RFC5018"/>, Section 5 and the security considerations in <xref target=
"RFC5018"/>, Section 6 also apply when an unreliable transport is used, both for
certificate-based server authentication and for client authentication based on
a pre-shared secret.</t> -->
<section anchor="congestion" numbered="true" toc="default">
<name>Congestion Control</name>
<t>BFCP may be characterized as generating "low data-volume" traffic,
per the classification in <xref target="RFC8085" format="default"/>. Nevertheles
s, it is necessary to ensure that suitable and necessary congestion control mech
anisms are used for BFCP over UDP. As described in <xref target="udp_transport"
format="default"/>, within the same BFCP connection, every entity -- client or s
erver -- is only allowed to send one request at a time, and await the acknowledg
ing response. This way, at most one datagram is sent per RTT given the message i
s not lost during transmission. If the message is lost, the request retransmissi
on timer T1 specified in <xref target="timers_retrans" format="default"/> will f
ire, and the message is retransmitted up to three times, in addition to the orig
inal transmission of the message. The default initial interval <bcp14>MUST</bcp1
4> be set to 500 ms, but is adjusted dynamically as described in <xref target="t
imers_retrans" format="default"/>. The interval <bcp14>MUST</bcp14> be doubled
after each retransmission attempt. This is similar to the specification of the t
imer A and its initial value T1 in SIP as described in <xref target="RFC3261" se
ction="17.1.1.2" sectionFormat="of" format="default"/>, except that the value of
T1 in this protocol is not fixed from one transaction to another.</t>
</section>
<section anchor="icmp" numbered="true" toc="default">
<name>ICMP Error Handling</name>
<t>ICMP is not usable when BFCP is running over an unreliable transpor
t
due to risks associated with off-path attacks. Any ICMP messages associated wit
h BFCP running over an unreliable transport <bcp14>MUST</bcp14> be ignored.</t>
</section>
<section anchor="fragmentation_handling" numbered="true" toc="default">
<name>Fragmentation Handling</name>
<t>When using UDP, a single BFCP message could be fragmented at the IP
layer if its overall size exceeds the path MTU of the network. To avoid this ha
ppening at the IP layer, a fragmentation scheme for BFCP is defined below.</t>
<t>BFCP is designed for achieving small message size, due to the binar
y encoding as described in <xref target="sec_intro" format="default"/>. The frag
mentation scheme is therefore deliberately kept simple and straightforward, sinc
e the probability of fragmentation of BFCP messages is small. By design, the fra
gmentation scheme does not acknowledge individual BFCP message fragments. The wh
ole BFCP message is acknowledged if received completely.</t>
<t>BFCP entities <bcp14>SHOULD</bcp14> consider the path MTU size
available between the sender and the receiver and <bcp14>MAY</bcp14>
run MTU discovery, such as described in <xref target="RFC1191"
format="default"/>, <xref target="RFC8201" format="default"/>, and <xre
f target="RFC4821" format="default"/>, for this purpose.</t>
<t>When transmitting a BFCP message with a size greater than the path
MTU, the sender <bcp14>MUST</bcp14> fragment the message into a series of N cont
iguous data ranges. The size of each of these N messages <bcp14>MUST</bcp14> be
smaller than the path MTU to help prevent fragmentation overlap attacks. The va
lue for N is defined as ceil((message size -- COMMON-HEADER size) / (path MTU si
ze -- COMMON-HEADER size)), where ceil is the integer ceiling function, and the
COMMON-HEADER size includes the Fragment Offset and Fragment Length fields. The
sender then creates N BFCP fragment messages (one for each data range) with the
same Transaction ID. The size of each of these N messages, with the COMMON-HEAD
ER included, <bcp14>MUST</bcp14> be smaller than the path MTU. The F flag in the
COMMON-HEADER in all the fragments is set to indicate fragmentation of the BFCP
message.</t>
<t>For each of these fragments, the Fragment Offset and Fragment Lengt
h fields are included in the COMMON-HEADER. The Fragment Offset field denotes th
e number of 4-octet units contained in the previous fragments, excluding the COM
MON-HEADER. The Fragment Length contains the length of the fragment itself, also
excluding the COMMON-HEADER. Note that the Payload Length field contains the le
ngth of the entire, unfragmented message.</t>
<t>When a BFCP implementation receives a BFCP message fragment, it <bc
p14>MUST</bcp14> buffer the fragment until either it has received the entire BFC
P message, or until the Response Retransmission Timer expires. The state machine
should handle the BFCP message only after all the fragments of the message have
been received.</t>
<t>If a fragment of a BFCP message is lost, the sender will not receiv
e an acknowledgement for the message. Therefore the sender will retransmit the m
essage with same transaction ID as specified in <xref target="timers" format="de
fault"/>. If the acknowledgement message sent by the receiver is lost, then the
entire message will be resent by the sender. The receiver <bcp14>MUST</bcp14> th
en retransmit the acknowledgement. The receiver <bcp14>MAY</bcp14> discard an in
complete buffer utilizing the Response Retransmission Timer, starting the timer
after the receipt of the first fragment.</t>
<aside>
<t>A Denial of Service (DoS) attack utilizing the fragmentation sche
me described above is mitigated by the fact that the Response Retransmission Tim
er is started after receipt of the first BFCP message fragment. In addition, the
Payload Length field can be compared with the Fragment Offset and Fragment Leng
th fields to verify the message fragments as they arrive. To make DoS attacks wi
th spoofed IP addresses difficult, BFCP entities <bcp14>SHOULD</bcp14> use the c
ookie exchange mechanism in DTLS <xref target="RFC6347" format="default"/>.</t>
</aside>
<t>When deciding the size of the message fragment based on path MTU, t
he BFCP fragmentation handling should take into account how the DTLS record fram
ing expands the datagram size as described in <xref target="RFC6347" section="4.
1.1.1" sectionFormat="of" format="default"/>.</t>
</section>
<section anchor="nat_traversal" numbered="true" toc="default">
<name>NAT Traversal</name>
<t>One of the key benefits of using UDP for BFCP communication is the
ability to leverage the existing NAT traversal infrastructure and strategies dep
loyed to facilitate transport of the media associated with the video conferencin
g sessions. Depending on the given deployment, this infrastructure typically inc
ludes some subset of Interactive Connectivity Establishment (ICE) <xref target="
RFC8445" format="default"/>.</t>
<t>In order to facilitate the initial establishment of NAT bindings, a
nd to maintain those bindings once established, BFCP entities using an unreliabl
e transport are <bcp14>RECOMMENDED</bcp14> to use STUN <xref target="RFC5389" fo
rmat="default"/> Binding Indication for keepalives, as described for ICE <xref t
arget="RFC8445" format="default"/>. <xref target="RFC5763" section="6.7" section
Format="of" format="default"/> provides useful recommendations for middlebox int
eraction when DTLS is used.</t>
<aside>
<t>Informational note: Since the version number is set to 2 when BFC
P is used over an unreliable transport, cf.&nbsp;the Ver field in <xref target="
sec_format_common" format="default"/>, it is straightforward to distinguish betw
een STUN and BFCP packets even without checking the STUN magic cookie <xref targ
et="RFC5389" format="default"/>.</t>
</aside>
<t>In order to facilitate traversal of BFCP packets through NATs, BFCP
entities using an unreliable transport are <bcp14>RECOMMENDED</bcp14> to use sy
mmetric ports for sending and receiving BFCP packets, as recommended for RTP/RTP
Control Protocol (RTCP) <xref target="RFC4961" format="default"/>.</t>
</section>
</section> </section>
</section>
<section title="ChairAction" anchor="sec:msg_format:ChairAction"> <section anchor="sec_lower-security" numbered="true" toc="default">
<t>Floor chairs send instructions to floor control servers by sending th <name>Lower-Layer Security</name>
em ChairAction messages. The following is the format of the ChairAction message: <t>BFCP relies on lower-layer security mechanisms to provide replay and in
</t> tegrity protection and confidentiality. BFCP floor control servers and clients
<t><figure title="ChairAction format" anchor="fig:chairaction"> (which include both floor participants and floor chairs) <bcp14>MUST</bcp14> sup
<artwork> port TLS for transport over TCP <xref target="RFC8446" format="default"/> and <b
ChairAction = COMMON-HEADER cp14>MUST</bcp14> support DTLS <xref target="RFC6347" format="default"/> for tra
FLOOR-REQUEST-INFORMATION nsport over UDP. Any BFCP entity <bcp14>MAY</bcp14> support other security mecha
*EXTENSION-ATTRIBUTE nisms.</t>
</artwork> <t>BFCP entities <bcp14>MUST</bcp14> support, at a minimum, the TLS_RSA_WI
</figure></t> TH_AES_128_CBC_SHA cipher suite <xref target="RFC5246" format="default"/> for ba
ckwards compatibility with existing implementations of RFC 4582. In accordance w
ith the recommendations and guidelines in <xref target="RFC7525" format="default
"/>, BFCP entities <bcp14>SHOULD</bcp14> support the following cipher suites:</t
>
<ul spacing="normal">
<li>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</li>
<li>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li>
<li>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</li>
<li>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</li>
</ul>
</section>
<section anchor="sec_transactions" numbered="true" toc="default">
<name>Protocol Transactions</name>
<t>In BFCP, there are two types of transactions: client-initiated transact
ions and server-initiated transactions.</t>
<t>Client-initiated transactions consist of a request from a client to a f
loor control server and a response from the floor control server to the client.<
/t>
<t>Server-initiated transactions have different requirements and behavior
depending on underlying transport:</t>
<ul empty="true" spacing="normal">
<li>When using a reliable transport, server-initiated transactions consi
st of a single message from a floor control server to a client (notifications).
They do not trigger any response.</li>
<li>When using an unreliable transport, server-initiated transactions co
nsist of a request from a floor control server to a client and a response from t
he client to the floor control server.</li>
</ul>
<t>When using BFCP over an unreliable transport, retransmission timer T1 (
see <xref target="timers" format="default"/>) <bcp14>MUST</bcp14> be used for al
l requests until the transaction is completed. Note that while T1 varies over t
ime, it remains constant for the duration of a given transaction and is only upd
ated at the completion of a transaction.</t>
<section anchor="sec_transactions_client" numbered="true" toc="default">
<name>Client Behavior</name>
<t>A client starting a client-initiated transaction <bcp14>MUST</bcp14>
set the Conference ID in the COMMON-HEADER of the message to the Conference ID f
or the conference that the client obtained previously.</t>
<t>The client <bcp14>MUST</bcp14> set the Transaction ID value in the CO
MMON-HEADER to a number that is different from 0 and that <bcp14>MUST NOT</bcp14
> be reused in another message from the client until a response from the server
is received for the transaction. The client uses the Transaction ID value to mat
ch this message with the response from the floor control server. When using BFCP
over an unreliable transport, it is important to choose a Transaction ID value
that lets the receiver distinguish the reception of the next message in a sequen
ce of BFCP messages from a retransmission of a previous message. Therefore, BFCP
entities using an unreliable transport <bcp14>MUST</bcp14>&nbsp;use monotonical
ly increasing Transaction ID values (except for wrap-around).</t>
<t>A client receiving a server-initiated transaction over an unreliable
transport <bcp14>MUST</bcp14> copy the Transaction ID from the request received
from the server into the response.</t>
</section> </section>
<section anchor="sec_transactions_server" numbered="true" toc="default">
<section title="ChairActionAck" anchor="sec:msg_format:ChairActionAck"> <name>Server Behavior</name>
<t>Floor control servers confirm that they have accepted a ChairAction m <t>A floor control server sending a response within a client-initiated t
essage by sending a ChairActionAck message. The following is the format of the C ransaction <bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and t
hairActionAck message:</t> he User ID from the request received from the client into the response.</t>
<t><figure title="ChairActionAck format" anchor="fig:chairactionack"> <t>Server-initiated transactions <bcp14>MUST</bcp14> contain a Transacti
<artwork> on ID equal to zero when BFCP is used over a reliable transport. Over an unrelia
ChairActionAck = COMMON-HEADER ble transport, the Transaction ID shall have the same properties as for client-i
*EXTENSION-ATTRIBUTE nitiated transactions. The server uses the Transaction ID value to match this me
</artwork> ssage with the response from the floor participant or floor chair.</t>
</figure></t>
</section> </section>
<section anchor="timers" numbered="true" toc="default">
<section title="Hello" anchor="sec:msg_format:Hello"> <name>Timers</name>
<t>Floor participants and floor chairs MAY check the liveliness of floor <t>When BFCP entities are communicating over an unreliable transport, tw
control servers by sending a Hello message. Additionally, clients communicatin o retransmission timers are employed to help mitigate the loss of datagrams. Ret
g with a floor control server over a an unreliable transport use the Hello messa ransmission and response caching are not required when BFCP entities communicate
ge to initiate communication with the server. The following is the format of th over a reliable transport.</t>
e Hello message:</t> <section anchor="timers_retrans" numbered="true" toc="default">
<t><figure title="Hello format" anchor="fig:hello"> <name>Request Retransmission Timer, T1</name>
<artwork> <t>T1 is a timer that schedules retransmission of a request until an a
Hello = COMMON-HEADER ppropriate response is received or until the maximum number of retransmissions h
*EXTENSION-ATTRIBUTE as occurred. The timer is computed using the smoothed round-trip time algorithm
</artwork> defined in <xref target="RFC6298" format="default"/> with an initial retransmiss
</figure></t> ion timeout (RTO) value of 500 ms and clock granularity (G) of 100 ms. In contr
ast to step 2.4 of <xref target="RFC6298" section="2" sectionFormat="of" format=
"default"/>, if the computed value of RTO is less than 500 ms, then RTO shall be
set to 500 ms. Timer T1 <bcp14>MUST</bcp14> be adjusted with the reception of
a response to each request transmitted in order to compute an accurate RTO value
, which is the effective T1 value. The RTT value R is the time in milliseconds
from the time when a request is transmitted to the time the initial response to
that request is received. Responses to retransmitted packets <bcp14>MUST NOT</b
cp14> be used to recompute the RTO value, as one cannot determine if a response
is to an initial or retransmitted request. If T1 always expires on the initial
transmission of a new request, this would suggest the recommended initial T1 (an
d RTO) value is too low and <bcp14>SHOULD</bcp14> be increased by doubling the i
nitial values of T1 (and RTO) until T1 does not expire when sending a new reques
t.</t>
<t>When retransmitting a request, timer T1 is doubled with each retran
smission, failing after three unacknowledged retransmission attempts.</t>
<t>If a valid response is not received for a client- or server-initiat
ed transaction, the implementation <bcp14>MUST</bcp14> consider the BFCP connect
ion as broken. Implementations <bcp14>SHOULD</bcp14> follow the reestablishment
procedure described in <xref target="sec_transport" format="default"/>.</t>
</section>
<section anchor="timers_cache" numbered="true" toc="default">
<name>Response Retransmission Timer, T2</name>
<t>T2 is a timer that, when fired, signals that the BFCP entity can re
lease knowledge of the transaction against which it is running. It is started up
on the first transmission of the response to a request and is the only mechanism
by which that response is released by the BFCP entity. Any subsequent retransmi
ssions of the same request can be responded to by replaying the cached response,
while that value is retained until the timer has fired. Refer to <xref target="
fragmentation_handling" format="default"/> for this timer's role in the fragment
ation handling scheme.</t>
</section>
<section anchor="timers_values" numbered="true" toc="default">
<name>Timer Values</name>
<t>The table below defines the different timers required when BFCP ent
ities communicate over an unreliable transport.</t>
<table anchor="timertable" align="center">
<name>Timers</name>
<thead>
<tr>
<th align="center">Timer</th>
<th align="left">Description</th>
<th align="center">Value/s</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">T1</td>
<td align="left">Initial request retransmission timer</td>
<td align="center">0.5 s (initial)</td>
</tr>
<tr>
<td align="center">T2</td>
<td align="left">Response retransmission timer</td>
<td align="center">(T1*2<sup>4</sup>)*1.25</td>
</tr>
</tbody>
</table>
<t>The initial value for T1 is 500 ms, which is an estimate of the RTT
for completing the transaction. Computation of this value follows the procedur
es described in <xref target="timers_retrans" format="default"/>, which includes
exponential backoffs on retransmissions.</t>
<t>T2 <bcp14>MUST</bcp14> be set such that it encompasses all legal re
transmissions per T1 plus a factor to accommodate network latency between BFCP e
ntities, processing delays, etc.</t>
</section>
</section> </section>
</section>
<section anchor="sec_auth" numbered="true" toc="default">
<name>Authentication and Authorization</name>
<t>BFCP clients <bcp14>SHOULD</bcp14> authenticate the floor control serve
r before sending any BFCP message to it or accepting any BFCP message from it. S
imilarly, floor control servers <bcp14>SHOULD</bcp14> authenticate a client befo
re accepting any BFCP message from it or sending any BFCP message to it.</t>
<t>If the signaling or control protocol traffic used to set up the confere
nce is authenticated and confidentiality and integrity protected, and the extens
ions in this document are supported, the BFCP clients <bcp14>MUST</bcp14> authen
ticate the floor control server, and the floor control servers <bcp14>MUST</bcp1
4> authenticate the client before communicating as described above. Note that BF
CP entities supporting only the <xref target="RFC4582" format="default"/> subset
may not comply with this mandatory authentication requirement.</t>
<t>BFCP supports TLS/DTLS mutual authentication between clients and floor
control servers, as specified in <xref target="sec_auth_tls" format="default"/>.
This is the <bcp14>RECOMMENDED</bcp14> authentication mechanism in BFCP.</t>
<t>Note that future extensions may define additional authentication mechan
isms.</t>
<section title="HelloAck" anchor="sec:msg_format:HelloAck"> <t>In addition to authenticating BFCP messages, floor control servers need
<t>Floor control servers confirm that they are alive on reception of a H to authorize them. On receiving an authenticated BFCP message, the floor contro
ello message by sending a HelloAck message. The following is the format of the H l server checks whether the client sending the message is authorized. If the cli
elloAck message:</t> ent is not authorized to perform the operation being requested, the floor contro
<t><figure title="HelloAck format" anchor="fig:helloack"> l server generates an Error message, as described in <xref target="sec_server_er
<artwork> ror" format="default"/>, with an error code with a value of 5 (Unauthorized Oper
HelloAck = COMMON-HEADER ation). Messages from a client that cannot be authorized <bcp14>MUST NOT</bcp14>
SUPPORTED-PRIMITIVES be processed further.</t>
SUPPORTED-ATTRIBUTES <section anchor="sec_auth_tls" numbered="true" toc="default">
*EXTENSION-ATTRIBUTE <name>TLS/DTLS Based Mutual Authentication</name>
</artwork> <t>BFCP supports TLS/DTLS based mutual authentication between clients an
</figure></t> d floor control servers. If TLS/DTLS is used, an initial integrity-protected ch
</section> annel is <bcp14>REQUIRED</bcp14> between the client and the floor control server
that can be used to exchange their certificates (which <bcp14>MAY</bcp14> be se
lf-signed certificates) or, more commonly, the fingerprints of these certificate
s. These certificates are used at TLS/DTLS establishment time.</t>
<aside>
<t>The implementation of such an integrity-protected channel using SIP
and the SDP offer/answer model is described in <xref target="RFC8856" format="d
efault"/>.</t>
</aside>
<section title="Error" anchor="sec:msg_format:Error"> <t>BFCP messages received over an authenticated TLS/DTLS connection are
<t>Floor control servers inform floor participants and floor chairs abou considered authenticated. A floor control server that receives a BFCP message ov
t errors processing requests by sending them Error messages. The following is th er TCP/UDP (no TLS/DTLS) <bcp14>MAY</bcp14> request the use of TLS/DTLS by gener
e format of the Error message:</t> ating an Error message, as described in <xref target="sec_server_error" format="
<t><figure title="Error format" anchor="fig:error"> default"/>, with an error code with a value of 9 (Use TLS) or a value of 11 (Use
<artwork> DTLS) respectively. Clients configured to require the use of TLS/DTLS <bcp14>
Error = COMMON-HEADER MUST</bcp14> ignore unauthenticated messages.</t>
ERROR-CODE <t>Note that future extensions may define additional authentication mech
[ERROR-INFO] anisms that may not require an initial integrity-protected channel (e.g., authen
*EXTENSION-ATTRIBUTE tication based on certificates signed by a certificate authority).</t>
</artwork> <t>As described in <xref target="sec_auth" format="default"/>, floor con
</figure></t> trol servers need to perform authorization before processing any message. In par
ticular, the floor control server <bcp14>MUST</bcp14> check that messages arrivi
ng over a given authenticated TLS/DTLS connection use an authorized User ID (i.e
., a User ID that the user that established the authenticated TLS/DTLS connectio
n is allowed to use).</t>
</section> </section>
</section>
<section title="FloorRequestStatusAck"> <section anchor="sec_participant" numbered="true" toc="default">
<t>When communicating over an unreliable transport, floor participants a <name>Floor Participant Operations</name>
nd chairs acknowledge the receipt of a subsequent FloorRequestStatus message fro <t>This section specifies how floor participants can perform different ope
m the floor control server (cf. <xref target="sec:server:request:subsequent"/>) rations, such as requesting a floor, using the protocol elements described in ea
by sending a FloorRequestStatusAck message. The following is the format of the F rlier sections. <xref target="sec_chair" format="default"/> specifies operations
loorRequestStatusAck message:</t> that are specific to floor chairs, such as instructing the floor control server
<t><figure align="left" anchor="FloorRequestStatusAck" title="FloorReque to grant or revoke a floor, and <xref target="sec_client" format="default"/> sp
stStatusAck format"> ecifies operations that can be performed by any client (i.e., both floor partici
<artwork align="left"><![CDATA[ pants and floor chairs).</t>
FloorRequestStatusAck = (COMMON-HEADER) <section anchor="sec_participant_request" numbered="true" toc="default">
*EXTENSION-ATTRIBUTE ]]></artwork> <name>Requesting a Floor</name>
</figure></t> <t>A floor participant that wishes to request one or more floors does so
by sending a FloorRequest message to the floor control server.</t>
<section anchor="sec_participant_request_send" numbered="true" toc="defa
ult">
<name>Sending a FloorRequest Message</name>
<t>The ABNF in <xref target="sec_msg_format_FloorRequest" format="defa
ult"/> describes the attributes that a FloorRequest message can contain. In addi
tion, the ABNF specifies normatively which of these attributes are mandatory, an
d which ones are optional.</t>
<t>The floor participant sets the Conference ID and the Transaction ID
in the COMMON-HEADER following the rules given in <xref target="sec_transaction
s_client" format="default"/>.</t>
<t>The floor participant sets the User ID in the COMMON-HEADER to the
floor participant's identifier. If the sender of the FloorRequest message (iden
tified by the User ID) is not the participant that would eventually get the floo
r (i.e., a third-party floor request), the sender <bcp14>SHOULD</bcp14> add a BE
NEFICIARY-ID attribute to the message identifying the beneficiary of the floor.<
/t>
<aside>
<t>Note that the namespace for both the User ID and the Beneficiary
ID is the same. That is, a given participant is identified by a single 16-bit va
lue that can be used in the User ID in the COMMON-HEADER and in several attribut
es: BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED-BY-INFORMATION.</t>
</aside>
<t>The floor participant <bcp14>MUST</bcp14> insert at least one FLOOR
-ID attribute in the FloorRequest message. If the client inserts more than one F
LOOR-ID attribute, the floor control server will treat all the floor requests as
an atomic package. That is, the floor control server will either grant or deny
all the floors in the FloorRequest message.</t>
<t>The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute
to state the reason why the floor or floors are being requested. The Text field
in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption.</
t>
<t>The floor participant may request that the server handle the floor
request with a certain priority using a PRIORITY attribute.</t>
</section>
<section anchor="sec_client_request_response" numbered="true" toc="defau
lt">
<name>Receiving a Response</name>
<t>A message from the floor control server is considered a response to
the FloorRequest message if the message from the floor control server has the s
ame Conference ID, Transaction ID, and User ID as the FloorRequest message, as d
escribed in <xref target="sec_transactions_client" format="default"/>. On receiv
ing such a response, the floor participant follows the rules in <xref target="se
c_auth" format="default"/> that relate to floor control server authentication.</
t>
<t>The successful processing of a FloorRequest message at the floor co
ntrol server involves generating one or several FloorRequestStatus messages. The
floor participant obtains a Floor Request ID in the Floor Request ID field of a
FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message fro
m the floor control server. Subsequent FloorRequestStatus messages from the floo
r control server regarding the same floor request will carry the same Floor Requ
est ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatu
s message. This way, the floor participant can associate subsequent incoming Flo
orRequestStatus messages with the ongoing floor request.</t>
<t>The floor participant obtains information about the status of the f
loor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequ
estStatus messages received from the floor control server. This attribute is a g
rouped attribute, and as such it includes a number of attributes that provide in
formation about the floor request.</t>
<t>The OVERALL-REQUEST-STATUS attribute provides information about the
overall status of the floor request. If the Request Status value is Granted, al
l the floors that were requested in the FloorRequest message have been granted.
If the Request Status value is Denied, all the floors that were requested in the
FloorRequest message have been denied. A floor request is considered to be ongo
ing while it is in the Pending, Accepted, or Granted states. If the floor reques
t value is unknown, then the response is still processed. However, no meaningfu
l value can be reported to the user.</t>
<t>The STATUS-INFO attribute, if present, provides extra information t
hat the floor participant can display to the user.</t>
<t>The FLOOR-REQUEST-STATUS attributes provide information about the s
tatus of the floor request as it relates to a particular floor. The STATUS-INFO
attribute, if present, provides extra information that the floor participant ca
n display to the user.</t>
<t>The BENEFICIARY-INFORMATION attribute identifies the beneficiary of
the floor request in third-party floor requests. The REQUESTED-BY-INFORMATION
attribute need not be present in FloorRequestStatus messages received by the flo
or participant that requested the floor, as this floor participant is already id
entified by the User ID in the COMMON-HEADER.</t>
<t>The PRIORITY attribute, when present, contains the priority that wa
s requested by the generator of the FloorRequest message.</t>
<t>If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is described in the
Error message.</t>
</section>
<section anchor="sec_recept_frsm" numbered="true" toc="default">
<name>Reception of a Subsequent FloorRequestStatus Message</name>
<t>When communicating over an unreliable transport and upon receiving
a FloorRequestStatus message from a floor control server, the participant <bcp14
>MUST</bcp14> respond with a FloorRequestStatusAck message within the transactio
n failure window to complete the transaction.</t>
</section>
</section> </section>
<section anchor="sec_participant_cancel" numbered="true" toc="default">
<section title="FloorStatusAck"> <name>Cancelling a Floor Request and Releasing a Floor</name>
<t>When communicating over an unreliable transport, floor participants a <t>A floor participant that wishes to cancel an ongoing floor request do
nd chairs acknowledge the receipt of a subsequent FloorStatus message from the f es so by sending a FloorRelease message to the floor control server. The FloorRe
loor control server (cf. <xref target="sec:server:floorinfo:subsequent"/>) by se lease message is also used by floor participants that hold a floor and would lik
nding a FloorStatusAck message. The following is the format of the FloorStatusAc e to release it.</t>
k message:</t> <section anchor="sec_participant_cancel_send" numbered="true" toc="defau
<t><figure align="left" anchor="FloorStatusAck" title="FloorStatusAck fo lt">
rmat"> <name>Sending a FloorRelease Message</name>
<artwork align="left"><![CDATA[ <t>The ABNF in <xref target="sec_msg_format_FloorRelease" format="defa
FloorStatusAck = (COMMON-HEADER) ult"/> describes the attributes that a FloorRelease message can contain. In addi
*EXTENSION-ATTRIBUTE ]]></artwork> tion, the ABNF specifies normatively which of these attributes are mandatory, an
</figure></t> d which ones are optional.</t>
<t>The floor participant sets the Conference ID and the Transaction ID
in the COMMON-HEADER following the rules given in <xref target="sec_transaction
s_client" format="default"/>. The floor participant sets the User ID in the COMM
ON-HEADER to the floor participant's identifier.</t>
<aside>
<t>Note that the FloorRelease message is used to release a floor or
floors that were granted and to cancel ongoing floor requests (from the protocol
perspective, both are ongoing floor requests). Using the same message in both s
ituations helps resolve the race condition that occurs when the FloorRelease mes
sage and the FloorGrant message cross each other on the wire.</t>
</aside>
<t>The floor participant uses the FLOOR-REQUEST-ID that was received i
n the response to the FloorRequest message that the FloorRelease message is canc
elling.</t>
<aside>
<t>Note that if the floor participant requested several floors as an
atomic operation (i.e., in a single FloorRequest message), all the floors are r
eleased as an atomic operation as well (i.e., all are released at the same time)
.</t>
</aside>
</section>
<section anchor="sec_participant_cancel_response" numbered="true" toc="d
efault">
<name>Receiving a Response</name>
<t>A message from the floor control server is considered a response to
the FloorRelease message if the message from the floor control server has the s
ame Conference ID, Transaction ID, and User ID as the FloorRelease message, as d
escribed in <xref target="sec_transactions_client" format="default"/>. On receiv
ing such a response, the floor participant follows the rules in <xref target="se
c_auth" format="default"/> that relate to floor control server authentication.</
t>
<t>If the response is a FloorRequestStatus message, the Request Status
value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMA
TION grouped attribute) will be Cancelled or Released.</t>
<t>If the response is an Error message, the floor control server could
not process the FloorRequest message for some reason, which is described in the
Error message.</t>
<t>It is possible that the FloorRelease message crosses on the wire wi
th a FloorRequestStatus message from the server with a Request Status different
from Cancelled or Released. In any case, such a FloorRequestStatus message will
not be a response to the FloorRelease message, as its Transaction ID will not ma
tch that of the FloorRelease.</t>
</section>
</section> </section>
</section>
<section title="Goodbye"> <section anchor="sec_chair" numbered="true" toc="default">
<t>BFCP entities communicating over an unreliable transport that wish to <name>Chair Operations</name>
dissociate themselves from their remote participant do so through the transmiss <t>This section specifies how floor chairs can instruct the floor control
ion of a Goodbye. The following is the format of the Goodbye message:</t> server to grant or revoke a floor using the protocol elements described in earli
<t><figure align="left" anchor="Goodbye" title="Goodbye format"> er sections.</t>
<artwork align="left"><![CDATA[ <t>Floor chairs that wish to send instructions to a floor control server d
Goodbye = (COMMON-HEADER) o so by sending a ChairAction message.</t>
*EXTENSION-ATTRIBUTE ]]></artwork> <section anchor="sec_chair_send" numbered="true" toc="default">
</figure></t> <name>Sending a ChairAction Message</name>
<t>The ABNF in <xref target="sec_msg_format_ChairAction" format="default
"/> describes the attributes that a ChairAction message can contain. In addition
, the ABNF specifies normatively which of these attributes are mandatory, and wh
ich ones are optional.</t>
<t>The floor chair sets the Conference ID and the Transaction ID in the
COMMON-HEADER following the rules given in <xref target="sec_transactions_client
" format="default"/>. The floor chair sets the User ID in the COMMON-HEADER to t
he floor chair's identifier.</t>
<t>The ChairAction message contains instructions that apply to one or mo
re floors within a particular floor request. The floor or floors are identified
by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by th
e FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message
.</t>
<t>For example, if a floor request consists of two floors that depend on
different floor chairs, each floor chair will grant its floor within the floor
request. Once both chairs have granted their floor, the floor control server wil
l grant the floor request as a whole. On the other hand, if one of the floor cha
irs denies its floor, the floor control server will deny the floor request as a
whole, regardless of the other floor chair's decision.</t>
<t>The floor chair provides the new status of the floor request as it re
lates to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new s
tatus of the floor request is Accepted, the floor chair <bcp14>MAY</bcp14> use t
he Queue Position field to provide a queue position for the floor request. If th
e floor chair does not wish to provide a queue position, all the bits of the Que
ue Position field <bcp14>MUST</bcp14> be set to zero. The floor chair <bcp14>MUS
T</bcp14> use the Status Revoked to revoke a floor that was granted (i.e., Grant
ed status) and <bcp14>MUST</bcp14> use the Status Denied to reject floor request
s in any other status (e.g., Pending and Accepted).</t>
<t>The floor chair <bcp14>MAY</bcp14> add an OVERALL-REQUEST-STATUS attr
ibute to the ChairAction message to provide a new overall status for the floor r
equest. If the new overall status of the floor request is Accepted, the floor c
hair can use the Queue Position field to provide a queue position for the floor
request.</t>
<aside>
<t>Note that a particular floor control server can implement a differe
nt queue for each floor containing all the floor requests that relate to that pa
rticular floor, a general queue for all floor requests, or both. Also note that
a floor request can involve several floors and that a ChairAction message can o
nly deal with a subset of these floors (e.g., if a single floor chair is not aut
horized to manage all the floors). In this case, the floor control server will
combine the instructions received from the different floor chairs in FLOOR-REQUE
ST-STATUS attributes to come up with the overall status of the floor request.</t
>
<t>Note that, while the action of a floor chair may communicate inform
ation in the OVERALL-REQUEST-STATUS attribute, the floor control server may over
ride, modify, or ignore this field's content.</t>
</aside>
<t>The floor chair <bcp14>MAY</bcp14> include STATUS-INFO attributes to
state the reason why the floor or floors are being accepted, granted, or revoked
. The Text in the STATUS-INFO attribute is intended for human consumption.</t>
</section> </section>
<section anchor="sec_chair_instruct_response" numbered="true" toc="default
<section title="GoodbyeAck"> ">
<t>BFCP entities communicating over an unreliable transport acknowledge <name>Receiving a Response</name>
the receipt of a Goodbye message from a peer. The following is the format of the <t>A message from the floor control server is considered a response to t
GoodbyeAck message:</t> he ChairAction message if the message from the server has the same Conference ID
<t><figure align="left" anchor="GoodbyeAck" title="GoodbyeAck format"> , Transaction ID, and User ID as the ChairAction message, as described in <xref
<artwork align="left"><![CDATA[ target="sec_transactions_client" format="default"/>. On receiving such a respons
GoodbyeAck = (COMMON-HEADER) e, the floor chair follows the rules in <xref target="sec_auth" format="default"
*EXTENSION-ATTRIBUTE ]]></artwork> /> that relate to floor control server authentication.</t>
</figure></t> <t>A ChairActionAck message from the floor control server confirms that
the floor control server has accepted the ChairAction message. An Error message
indicates that the floor control server could not process the ChairAction messag
e for some reason, which is described in the Error message.</t>
</section> </section>
</section> </section>
</section> <section anchor="sec_client" numbered="true" toc="default">
<name>General Client Operations</name>
<section title="Transport" anchor="sec:transport"> <t>This section specifies operations that can be performed by any client.
<t>The transport over which BFCP entities exchange messages depends on the i That is, they are not specific to floor participants or floor chairs. They can b
nformation the clients obtain for how to to contact the floor control server, as e performed by both.</t>
described in <xref target="sec:scope:info"/>. Two transports are supported: TCP <section anchor="sec_client_floorinfo" numbered="true" toc="default">
, appropriate where connectivity is not impeded by network elements such as NAT <name>Requesting Information about Floors</name>
devices or media relays; and UDP for those deployments where TCP may not be appl <t>A client can obtain information about the status of a floor or floors
icable or appropriate.</t> in different ways, which include using BFCP and using out-of-band mechanisms. C
lients using BFCP to obtain such information use the procedures described in thi
<t><list style="empty"> s section. </t>
<t>Informational note: In practice, products are configured to try one t <t>Clients request information about the status of one or several floors
ransport first and use the other transport as a fallback. Whether TCP or UDP is by sending a FloorQuery message to the floor control server.</t>
chosen as underlying transport depends on the type of product and the deployment <section anchor="sec_client_floorinfo_send" numbered="true" toc="default
environment. See <xref target="app:motivation"/> for additional considerations. ">
</t> <name>Sending a FloorQuery Message</name>
</list></t> <t>The ABNF in <xref target="sec_msg_format_FloorQuery" format="defaul
t"/> describes the attributes that a FloorQuery message can contain. In addition
<section anchor="tcp_transport" title="Reliable Transport"> , the ABNF specifies normatively which of these attributes are mandatory, and wh
<t>BFCP entities may elect to exchange BFCP messages using TCP connections ich ones are optional.</t>
. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, <t>The client sets the Conference ID and the Transaction ID in the COM
message framing needs to be implemented in the application layer. BFCP implemen MON-HEADER following the rules given in <xref target="sec_transactions_client" f
ts application-layer framing using TLV-encoded attributes.</t> ormat="default"/>. The client sets the User ID in the COMMON-HEADER to the clien
<t>A client MUST NOT use more than one TCP connection to communicate with t's identifier.</t>
a given floor control server within a conference. Nevertheless, if the same phys <t>The client inserts in the message all the Floor IDs it wants to rec
ical box handles different clients (e.g., a floor chair and a floor participant) eive information about. The floor control server will send periodic information
, which are identified by different User IDs, a separate connection per client i about all of these floors. If the client does not want to receive information ab
s allowed.</t> out a particular floor any longer, it sends a new FloorQuery message removing th
<t>If a BFCP entity (a client or a floor control server) receives data tha e FLOOR-ID of this floor. If the client does not want to receive information abo
t cannot be parsed, the entity MUST close the TCP connection, and the connection ut any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribut
SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP m e.</t>
essage and times out or receives an ICMP port unreachable message mid-connection </section>
, the TCP connection SHOULD be reestablished.</t> <section anchor="sec_client_floorinfo_response" numbered="true" toc="def
<t>The way connection reestablishment is handled depends on how the client ault">
obtains information to contact the floor control server. Once the TCP connectio <name>Receiving a Response</name>
n is reestablished, the client MAY resend those messages for which it did not ge <t>A message from the floor control server is considered a response to
t a response from the floor control server.</t> the FloorQuery message if the message from the floor control server has the sam
<t>If a floor control server detects that the TCP connection towards one o e Conference ID, Transaction ID, and User ID as the FloorQuery message, as descr
f the floor participants is lost, it is up to the local policy of the floor cont ibed in <xref target="sec_transactions_client" format="default"/>. On receiving
rol server what to do with the pending floor requests of the floor participant. such a response, the client follows the rules in <xref target="sec_auth" format=
In any case, it is RECOMMENDED that the floor control server keep the floor requ "default"/> that relate to floor control server authentication.</t>
ests (i.e., that it does not cancel them) while the TCP connection is reestablis <t>On reception of the FloorQuery message, the floor control server <b
hed.</t> cp14>MUST</bcp14> respond with a FloorStatus message or with an Error message. I
<t>If a client wishes to end its BFCP connection with a floor control serv f the response is a FloorStatus message, it will contain information about one o
er, the client closes (i.e., a graceful close) the TCP connection towards the fl f the floors the client requested information about. If the client did not inclu
oor control server. If a floor control server wishes to end its BFCP connection de any FLOOR-ID attribute in its FloorQuery message (i.e., the client does not w
with a client (e.g., the Focus of the conference informs the floor control serv ant to receive information about any floor any longer), the FloorStatus message
er that the client has been kicked out from the conference), the floor control s from the floor control server will not include any FLOOR-ID attribute either. </
erver closes (i.e., a graceful close) the TCP connection towards the client.</t> t>
<t>In cases where a BFCP entity reestablishes a connection due to protocol <t>FloorStatus messages that carry information about a floor contain a
errors as described above, the entity SHOULD NOT repeatedly reestablish the con FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus
nection. Rather, if the same protocol errors persist, the entity MUST cease att messages contain information about existing (one or more) floor requests that r
empts and SHOULD report the error to the human user and/or log the event. This elate to that floor. The information about each particular floor request is enco
does not preclude the entity from reestablishing a connection when facing a diff ded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a F
erent set of errors. That said, entities MUST avoid overloading the server with loor Request ID that identifies the floor request, followed by a set of attribut
reestablishment requests. A connection MUST NOT be reestablished too frequentl es that provide information about the floor request.</t>
y. The frequency is a matter of implementation, but SHOULD NOT be attempted mor <t>After the first FloorStatus, the floor control server will continue
e than once in a 30 second period of time.</t> sending FloorStatus messages, periodically informing the client about changes o
</section> n the floors the client requested information about.</t>
</section>
<section anchor="udp_transport" title="Unreliable Transport"> <section anchor="sec_recept_fsm" numbered="true" toc="default">
<t>BFCP entities may elect to exchange BFCP messages using UDP datagrams. <name>Reception of a Subsequent FloorStatus Message</name>
UDP is an unreliable transport where neither delivery nor ordering is assured. E <t>When communicating over an unreliable transport and upon receiving
ach BFCP UDP datagram MUST contain exactly one BFCP message or message fragment. a FloorStatus message from a floor control server, the participant <bcp14>MUST</
To keep large BFCP messages from being fragmented at the IP layer, the fragment bcp14> respond with a FloorStatusAck message within the transaction failure wind
ation of BFCP messages that exceed the path MTU size is performed at the BFCP le ow to complete the transaction.</t>
vel. Considerations related to fragmentation are covered in <xref target="fragme </section>
ntation_handling"/>. The message format for BFCP messages is the same regardless
of whether the messages are sent in UDP datagrams or over a TCP stream.</t>
<t>Clients MUST announce their presence to the floor control server by sen
ding a Hello message. The floor control server responds to the Hello message wit
h a HelloAck message. The client considers the floor control service as present
and available only upon receiving the HelloAck message. The behavior when timers
fire, including the determination that a connection is broken, is described in
<xref target="timers"/>.</t>
<t>As described in <xref target="sec:transactions"/>, each request sent by
a floor participant or chair forms a client transaction that expects an acknowl
edgement message back from the floor control server within a transaction failure
window. Concordantly, messages sent by the floor control server that initiate
new transactions (e.g., FloorStatus announcements as part of a FloorQuery subsc
ription) require acknowledgement messages from the floor participant and chair e
ntities to which they were sent.</t>
<t>If a Floor Control Server receives data that cannot be parsed, the rece
iving server MUST send an Error message with parameter value 10 (Unable to parse
message) indicating receipt of a malformed message, given that it is possible t
o parse the received message to such an extent that an Error message may be buil
t.</t>
<t>Entities MUST have at most one outstanding request transaction per peer
at any one time. Implicit subscriptions occur for a client-initiated request t
ransaction whose acknowledgement is implied by the first server-initiated respon
se for that transaction, followed by zero of more subsequent server-initiated me
ssages corresponding to the same transaction. An example is a FloorRequest messa
ge for which there are potentially multiple responses from the floor control ser
ver as it processes intermediate states until a terminal state (e.g., Granted or
Denied) is attained. The subsequent changes in state for the request are new tr
ansactions whose Transaction ID is determined by the floor control server and wh
ose receipt by the client participant is acknowledged with a FloorRequestStatusA
ck message.</t>
<t>By restricting entities to having at most one pending transaction open
in a BFCP connection, both the out-of-order receipt of messages as well as the p
ossibility for congestion are mitigated. Additional details regarding congestion
control are provided in <xref target="congestion"/>. A server-initiated request
(e.g., a FloorStatus with an update from the floor control server) received by
a participant before the initial FloorRequestStatus message that closes the clie
nt-initiated transaction that was instigated by the FloorRequest MUST be treated
as superseding the information conveyed in any such late arriving response. As
the floor control server cannot send a second update to the implicit floor statu
s subscription until the first is acknowledged, ordinality is maintained.</t>
<t>If a client wishes to end its BFCP connection with a floor control serv
er, it is REQUIRED that the client send a Goodbye message to dissociate itself f
rom any allocated resources. If a floor control server wishes to end its BFCP co
nnection with a client (e.g., the Focus of the conference informs the floor cont
rol server that the client has been kicked out from the conference), it is REQUI
RED that the floor control server send a Goodbye message towards the client.</t>
<!-- Commented out. RFC 5018 behaviour for unreliable transport is explici
tly not supported, cf. anchor="sec:scope:info". In the unlikely case we need UDP
/DTLS support outside offer/answer, a RFC5018bis is needed.
<t>RFC 5018 <xref target="RFC5018"/> specifies how to establish a TCP
connection to a floor control server outside the context of an offer/answer exc
hange. When using UDP the same set of data is needed for a BFCP connection as li
sted in <xref target="RFC5018"/>, Section 3, i.e. transport address of the serve
r, the conference identifier, and the user identifier. The procedures and consid
erations for resolving a host name into an IP address also applies to BFCP over
an unreliable transport. In <xref target="RFC5018"/>, Section 4 applies, but whe
n using BFCP over an unreliable transport the floor control server that receives
a BFCP message over UDP (no DTLS) SHOULD request the use of DTLS by generating
an Error message with an Error code with a value of 11 (Use DTLS). A floor contr
ol server that is configured to require DTLS MUST request the use of DTLS this w
ay. The recommendations for authentication in <xref target="RFC5018"/>, Section
5 and the security considerations in <xref target="RFC5018"/>, Section 6 also ap
ply when an unreliable transport is used, both for certificate-based server auth
entication and for client authentication based on a pre-shared secret.</t> -->
<section anchor="congestion" title="Congestion Control">
<t>BFCP may be characterized to generate "low data-volume" traffic, per
the classification in <xref target="RFC5405"/>. Nevertheless is it necessary to
ensure suitable and necessary congestion control mechanisms are used for BFCP ov
er UDP. As described in <xref target="udp_transport"/>, within the same BFCP con
nection, every entity - client or server - is only allowed to send one request a
t a time, and await the acknowledging response. This way at most one datagram is
sent per RTT given the message is not lost during transmission. In case the mes
sage is lost, the request retransmission timer T1 specified in <xref target="tim
ers_retrans"/> will fire and the message is retransmitted up to three times, in
addition to the original transmission of the message. The default initial interv
al MUST be set to 500ms, but is adjusted dynamically as described in <xref targe
t="timers_retrans"/>. The interval MUST be doubled after each retransmission at
tempt. This is similar to the specification of the timer A and its initial value
T1 in SIP as described in Section 17.1.1.2 of <xref target="RFC3261"/>, except
that the value of T1 in this protocol is not fixed from one transaction to anoth
er.</t>
</section> </section>
<section anchor="sec_client_info" numbered="true" toc="default">
<section anchor="icmp" title="ICMP Error Handling"> <name>Requesting Information about Floor Requests</name>
<t>ICMP is not usable when BFCP is running over an unreliable transport <t>A client can obtain information about the status of one or several fl
due to risks associated with off-path attacks. Any ICMP messages associated wit oor requests in different ways, which include using BFCP and using out-of-band m
h BFCP running over an unreliable transport MUST be ignored.</t> echanisms. Clients using BFCP to obtain such information use the procedures desc
ribed in this section.</t>
<t>Clients request information about the current status of a floor reque
st by sending a FloorRequestQuery message to the floor control server.</t>
<t>Requesting information about a particular floor request is useful in
a number of situations. For example, on reception of a FloorRequest message, a f
loor control server may choose to return FloorRequestStatus messages only when t
he floor request changes its state (e.g., from Accepted to Granted), but not whe
n the floor request advances in its queue. In this situation, if the user reques
ts it, the floor participant can use a FloorRequestQuery message to poll the flo
or control server for the status of the floor request.</t>
<section anchor="sec_client_info_send" numbered="true" toc="default">
<name>Sending a FloorRequestQuery Message</name>
<t>The ABNF in <xref target="sec_msg_format_FloorRequestQuery" format=
"default"/> describes the attributes that a FloorRequestQuery message can contai
n. In addition, the ABNF specifies normatively which of these attributes are man
datory, and which ones are optional.</t>
<t>The client sets the Conference ID and the Transaction ID in the COM
MON-HEADER following the rules given in <xref target="sec_transactions_client" f
ormat="default"/>. The client sets the User ID in the COMMON-HEADER to the clien
t's identifier.</t>
<t>The client <bcp14>MUST</bcp14> insert a FLOOR-REQUEST-ID attribute
that identifies the floor request at the floor control server.</t>
</section>
<section anchor="sec_client_info_response" numbered="true" toc="default"
>
<name>Receiving a Response</name>
<t>A message from the floor control server is considered a response to
the FloorRequestQuery message if the message from the floor control server has
the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery mes
sage, as described in <xref target="sec_transactions_client" format="default"/>.
On receiving such a response, the client follows the rules in <xref target="se
c_auth" format="default"/> that relate to floor control server authentication.</
t>
<t>If the response is a FloorRequestStatus message, the client obtains
information about the status of the FloorRequest the client requested informati
on about in a FLOOR-REQUEST-INFORMATION attribute.</t>
<t>If the response is an Error message, the floor control server could
not process the FloorRequestQuery message for some reason, which is described i
n the Error message.</t>
</section>
</section> </section>
<section anchor="sec_client_user" numbered="true" toc="default">
<section anchor="fragmentation_handling" title="Fragmentation Handling"> <name>Requesting Information about a User</name>
<t>When using UDP, a single BFCP message could be fragmented at the IP l <t>A client can obtain information about a participant and the floor req
ayer if its overall size exceeds the path MTU of the network. To avoid this happ uests related to this participant in different ways, which include using BFCP an
ening at the IP layer, a fragmentation scheme for BFCP is defined below.</t> d using out-of-band mechanisms. Clients using BFCP to obtain such information us
<t>BFCP is designed for achieving small message size, due to the binary e the procedures described in this section.</t>
encoding as described in <xref target="sec:intro"/>. The fragmentation scheme is <t>Clients request information about a participant and the floor request
therefore deliberately kept simple and straightforward, since the probability o s related to this participant by sending a UserQuery message to the floor contro
f fragmentation of BFCP messages being required is small. By design, the fragmen l server.</t>
tation scheme does not acknowledge individual BFCP message fragments. The whole <t>This functionality may be useful for floor chairs or floor participan
BFCP message is acknowledged if received completely.</t> ts interested in the display name and the URI of a particular floor participant.
<t>BFCP entities SHOULD consider the path MTU size available between the In addition, a floor participant may find it useful to request information abou
sender and the receiver and MAY run MTU discovery, such as <xref target="RFC119 t itself. For example, a floor participant, after experiencing connectivity prob
1"/><xref target="RFC1981"/><xref target="RFC4821"/>, for this purpose.</t> lems (e.g., its TCP connection with the floor control server was down for a whil
<t>When transmitting a BFCP message with size greater than the path MTU, e and eventually was re-established), may need to request information about all
the sender MUST fragment the message into a series of N contiguous data ranges. the floor requests associated to itself that still exist.</t>
The size of each of these N messages MUST be smaller than the path MTU to help <section anchor="sec_client_user_send" numbered="true" toc="default">
prevent fragmentation overlap attacks. The value for N is defined as ceil((mess <name>Sending a UserQuery Message</name>
age size - COMMON-HEADER size) / (path MTU size - COMMON-HEADER size)), where ce <t>The ABNF in <xref target="sec_msg_format_UserQuery" format="default
il is the integer ceiling function and the COMMON-HEADER size includes the Fragm "/> describes the attributes that a UserQuery message can contain. In addition,
ent Offset and Fragment Length fields. The sender then creates N BFCP fragment the ABNF specifies normatively which of these attributes are mandatory, and whic
messages (one for each data range) with the same Transaction ID. The size of eac h ones are optional.</t>
h of these N messages, with the COMMON-HEADER included, MUST be smaller than the <t>The client sets the Conference ID and the Transaction ID in the COM
path MTU. The F flag in the COMMON-HEADER in all the fragments is set to indica MON-HEADER following the rules given in <xref target="sec_transactions_client" f
te fragmentation of the BFCP message.</t> ormat="default"/>. The client sets the User ID in the COMMON-HEADER to the clien
<t>For each of these fragments the Fragment Offset and Fragment Length f t's identifier.</t>
ields are included in the COMMON-HEADER. The Fragment Offset field denotes the n <t>If the floor participant the client is requesting information about
umber of 4-octet units contained in the previous fragments, excluding the common is not the client issuing the UserQuery message (which is identified by the Use
header. The Fragment Length contains the length of the fragment itself, also ex r ID in the COMMON-HEADER of the message), the client <bcp14>MUST</bcp14> insert
cluding the common header. Note that the Payload Length field contains the lengt a BENEFICIARY-ID attribute.</t>
h of the entire, unfragmented message.</t> </section>
<t>When a BFCP implementation receives a BFCP message fragment, it MUST <section anchor="sec_client_user_response" numbered="true" toc="default"
buffer the fragment until either it has received the entire BFCP message, or unt >
il the Response Retransmission Timer expires. The state machine should handle th <name>Receiving a Response</name>
e BFCP message only after all the fragments for the message have been received.< <t>A message from the floor control server is considered a response to
/t> the UserQuery message if the message from the floor control server has the same
<t>If a fragment of a BFCP message is lost, the sender will not receive Conference ID, Transaction ID, and User ID as the UserQuery message, as describ
an acknowledgement for the message. Therefore the sender will retransmit the mes ed in <xref target="sec_transactions_client" format="default"/>. On receiving s
sage with same transaction ID as specified in <xref target="timers"/>. If the ac uch a response, the client follows the rules in <xref target="sec_auth" format="
knowledgement message sent by the receiver is lost, then the entire message will default"/> that relate to floor control server authentication.</t>
be resent by the sender. The receiver MUST then retransmit the acknowledgement. <t>If the response is a UserStatus message, the client obtains informa
The receiver MAY discard an incomplete buffer utilizing the Response Retransmis tion about the floor participant in a BENEFICIARY-INFORMATION grouped attribute
sion Timer, starting the timer after the receipt of the first fragment.</t> and about the status of the floor requests associated with the floor participant
<t><list style="empty"> in FLOOR-REQUEST-INFORMATION attributes.</t>
<t>A Denial of Service (DoS) attack utilizing the fragmentation sche <t>If the response is an Error message, the floor control server could
me described above is mitigated by the fact that the Response Retransmission Tim not process the UserQuery message for some reason, which is described in the Er
er is started after receipt of the first BFCP message fragment. In addition, the ror message.</t>
Payload Length field can be compared with the Fragment Offset and Fragment Leng </section>
th fields to verify the message fragments as they arrive. To make DoS attacks wi
th spoofed IP addresses difficult, BFCP entities SHOULD use the cookie exchange
mechanism in DTLS <xref target="RFC6347"/>.</t>
</list></t>
<t>When deciding message fragment size based on path MTU, the BFCP fragm
entation handling should take into account how the DTLS record framing expands t
he datagram size as described in Section 4.1.1.1 of <xref target="RFC6347"/>.</t
>
</section> </section>
<section anchor="sec_client_hello" numbered="true" toc="default">
<section anchor="nat_traversal" title="NAT Traversal"> <name>Obtaining the Capabilities of a Floor Control Server</name>
<t>One of the key benefits when using UDP for BFCP communication is the <t>A client that wishes to obtain the capabilities of a floor control se
ability to leverage the existing NAT traversal infrastructure and strategies dep rver does so by sending a Hello message to the floor control server.</t>
loyed to facilitate transport of the media associated with the video conferencin <section anchor="sec_client_hello_send" numbered="true" toc="default">
g sessions. Depending on the given deployment, this infrastructure typically inc <name>Sending a Hello Message</name>
ludes some subset of ICE <xref target="RFC5245"/>.</t> <t>The ABNF in <xref target="sec_msg_format_Hello" format="default"/>
<t>In order to facilitate the initial establishment of NAT bindings, and describes the attributes that a Hello message can contain. In addition, the ABNF
to maintain those bindings once established, BFCP entities using an unreliable specifies normatively which of these attributes are mandatory, and which ones a
transport are RECOMMENDED to use STUN <xref target="RFC5389"/> Binding Indicatio re optional.</t>
n for keep-alives, as described for ICE <xref target="RFC5245"/>. Section 6.7 of <t>The client sets the Conference ID and the Transaction ID in the COM
<xref target="RFC5763"/> provides useful recommendations for middlebox interact MON-HEADER following the rules given in <xref target="sec_transactions_client" f
ion when DTLS is used.</t> ormat="default"/>. The client sets the User ID in the COMMON-HEADER to the clien
<t><list style="empty"> t's identifier.</t>
<t>Informational note: Since the version number is set to 2 when BFC </section>
P is used over an unreliable transport, cf. the Ver field in <xref target="sec:f <section anchor="sec_client_hello_responses" numbered="true" toc="defaul
ormat:common"/>, it is straight forward to distinguish between STUN and BFCP pac t">
kets even without checking the STUN magic cookie <xref target="RFC5389"/>.</t> <name>Receiving Responses</name>
</list></t> <t>A message from the floor control server is considered a response to
<t>In order to facilitate traversal of BFCP packets through NATs, BFCP e the Hello message by the client if the message from the floor control server ha
ntities using an unreliable transport are RECOMMENDED to use symmetric ports for s the same Conference ID, Transaction ID, and User ID as the Hello message, as d
sending and receiving BFCP packets, as recommended for RTP/RTCP <xref target="R escribed in <xref target="sec_transactions_client" format="default"/>. On receiv
FC4961"/>.</t> ing such a response, the client follows the rules in <xref target="sec_auth" for
mat="default"/> that relate to floor control server authentication.</t>
<t>If the response is a HelloAck message, the floor control server cou
ld process the Hello message successfully. The SUPPORTED-PRIMITIVES and SUPPORTE
D-ATTRIBUTES attributes indicate which primitives and attributes, respectively,
are supported by the server.</t>
<t>If the response is an Error message, the floor control server could
not process the Hello message for some reason, which is described in the Error
message.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="sec_server" numbered="true" toc="default">
<name>Floor Control Server Operations</name>
<section title="Lower-Layer Security" anchor="sec:lower-security"> <t>This section specifies how floor control servers can perform different
<t>BFCP relies on lower-layer security mechanisms to provide replay and inte operations, such as granting a floor, using the protocol elements described in e
grity protection and confidentiality. BFCP floor control servers and clients (w arlier sections.</t>
hich include both floor participants and floor chairs) MUST support TLS for tran
sport over TCP <xref target="RFC5246"/> and MUST support DTLS <xref target="RFC6
347"/> for transport over UDP. Any BFCP entity MAY support other security mechan
isms.</t>
<t>BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SH
A cipher suite <xref target="RFC5246"/> for backwards compatibility with existin
g implementations of RFC 4582. In accordance with the recommendations and guidel
ines in <xref target="RFC7525"/>, BFCP entities SHOULD support the following cip
her suites:</t>
<t><list style="symbols">
<t>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</t>
<t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t>
<t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</t>
<t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</t>
</list></t>
</section>
<section title="Protocol Transactions" anchor="sec:transactions">
<t>In BFCP, there are two types of transactions: client-initiated transactio
ns and server-initiated transactions.</t>
<t>Client-initiated transactions consist of a request from a client to a flo
or control server and a response from the floor control server to the client.</t
>
<t>Server-initiated transactions have different requirements and behavior de
pending on underlying transport:</t>
<t><list style="hanging">
<t>When using a reliable transport, server-initiated transactions consis
t of a single message from a floor control server to a client (notifications). T
hey do not trigger any response.</t>
<t>When using an unreliable transport, server-initiated transactions con
sist of a request from a floor control server to a client and a response from th
e client to the floor control server.</t>
</list></t>
<t>When using BFCP over an unreliable transport, retransmission timer T1 (se
e <xref target="timers"/>) MUST be used for all requests until the transaction i
s completed. Note that while T1 varies over time, it remains constant for the d
uration of a given transaction and is only updated at the completion of a transa
ction.</t>
<section title="Client Behavior" anchor="sec:transactions:client"> <t>On reception of a message from a client, the floor control server <bcp1
<t>A client starting a client-initiated transaction MUST set the Conferenc 4>MUST</bcp14> check whether the value of the primitive is supported. If it is
e ID in the common header of the message to the Conference ID for the conference not, the floor control server <bcp14>MUST</bcp14> send an Error message, as desc
that the client obtained previously.</t> ribed in <xref target="sec_server_error" format="default"/>, with Error Code 3 (
<t>The client MUST set the Transaction ID value in the common header to a Unknown Primitive).</t>
number that is different from 0 and that MUST NOT be reused in another message f
rom the client until a response from the server is received for the transaction.
The client uses the Transaction ID value to match this message with the respons
e from the floor control server. When using BFCP over an unreliable transport, i
t is important to choose a Transaction ID value that lets the receiver distingui
sh the reception of the next message in a sequence of BFCP messages from a retra
nsmission of a previous message.  Therefore, BFCP entities using an unreliable t
ransport MUST use monotonically increasing Transaction ID values (except for wra
p-around).</t>
<t>A client receiving a server-initiated transaction over an unreliable tr
ansport MUST copy the Transaction ID from the request received from the server i
nto the response.</t>
</section>
<section title="Server Behavior" anchor="sec:transactions:server"> <t>On reception of a message from a client, the floor control server <bcp1
<t>A floor control server sending a response within a client-initiated tra 4>MUST</bcp14> check whether the value of the Conference ID matched an existing
nsaction MUST copy the Conference ID, the Transaction ID, and the User ID from t conference. If it does not, the floor control server <bcp14>MUST</bcp14> send an
he request received from the client into the response.</t> Error message, as described in <xref target="sec_server_error" format="default"
<t>Server-initiated transactions MUST contain a Transaction ID equal to 0 />, with Error Code 1 (Conference Does Not Exist).</t>
when BFCP is used over a reliable transport. Over an unreliable transport, the T <t>On reception of a message from a client, the floor control server follo
ransaction ID shall have the same properties as for client-initiated transaction ws the rules in <xref target="sec_auth" format="default"/> that relate to the au
s. The server uses the Transaction ID value to match this message with the respo thentication of the message.</t>
nse from the floor participant or floor chair.</t>
</section>
<section anchor="timers" title="Timers"> <t>On reception of a message from a client, the floor control server <bcp1
<t>When BFCP entities are communicating over an unreliable transport, two 4>MUST</bcp14> check whether it understands all the mandatory ('M' bit set) attr
retransmission timers are employed to help mitigate against loss of datagrams. R ibutes in the message. If the floor control server does not understand all of th
etransmission and response caching are not required when BFCP entities communica em, the floor control server <bcp14>MUST</bcp14> send an Error message, as descr
te over a reliable transport.</t> ibed in <xref target="sec_server_error" format="default"/>, with Error Code 4 (U
nknown Mandatory Attribute). The Error message <bcp14>SHOULD</bcp14> list the at
tributes that were not understood.</t>
<section anchor="sec_server_request" numbered="true" toc="default">
<name>Reception of a FloorRequest Message</name>
<t>On reception of a FloorRequest message, the floor control server foll
ows the rules in <xref target="sec_auth" format="default"/> that relate to clien
t authentication and authorization. If while processing the FloorRequest message
, the floor control server encounters an error, it <bcp14>MUST</bcp14> generate
an Error response following the procedures described in <xref target="sec_server
_error" format="default"/>.</t>
<section anchor="timers_retrans" title="Request Retransmission Timer, T1"> <aside>
<t>T1 is a timer that schedules retransmission of a request until an app <t>BFCP allows floor participants to have several ongoing floor reques
ropriate response is received or until the maximum number of retransmissions hav ts for the same floor (e.g., the same floor participant can occupy more than one
e occurred. The timer is computed using the smoothed round-trip time algorithm d position in a queue at the same time). A floor control server that only support
efind in <xref target="RFC2988"/> with an initial retransmission timeout (RTO) v s a certain number of ongoing floor requests per floor participant (e.g., one) c
alue of 500ms and clock granularity (G) of 100ms. In contrast to step 2.4 of Se an use Error Code 8 (You have Already Reached the Maximum Number of Ongoing Floo
ction 2 of <xref target="RFC2988"/>, if the computed value of RTO is less than 5 r Requests for This Floor) to inform the floor participant.</t>
00ms, then RTO shall be set to 500ms. Timer T1 MUST be adjusted with the recept </aside>
ion of a response to each request transmitted in order to compute an accurate RT <t>When communicating over an unreliable transport and upon receiving a
O value, which is the effective T1 value. The RTT value R is the time in millis FloorRequest from a participant, the floor control server <bcp14>MUST</bcp14> re
econds from the point when a request is transmitted to the time the initial resp spond with a FloorRequestStatus message within the transaction failure window to
onse to that request is received. Responses to retransmitted packets MUST NOT b complete the transaction.</t>
e used to recompute the RTO value, as one cannot determine if a response is to a <section anchor="sec_server_request_first" numbered="true" toc="default"
n initial or retransmitted request. If T1 always expires on the initial transmi >
ssion of a new request, this would suggest the recommended initial T1 (and RTO) <name>Generating the First FloorRequestStatus Message</name>
value is too low and SHOULD be increased by doubling the initial values of T1 (a <t>The successful processing of a FloorRequest message by a floor cont
nd RTO) until T1 does not expire when sending a new request.</t> rol server involves generating one or several FloorRequestStatus messages, the f
<t>When retransmitting a request, timer T1 is doubled with each retransm irst of which <bcp14>SHOULD</bcp14> be generated as soon as possible. If the flo
ission, failing after three unacknowledged retransmission attempts.</t> or control server cannot accept, grant, or deny the floor request right away (e.
<t>If a valid response is not received for a client- or server-initiated g., a decision from a chair is needed), it <bcp14>SHOULD</bcp14> use a Request S
transaction, the implementation MUST consider the BFCP connection as broken. Im tatus value of Pending in the OVERALL-REQUEST-STATUS attribute (within the FLOOR
plementations SHOULD follow the reestablishment procedure described in section 6 -REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message
.</t> it generates.</t>
<aside>
<t>The policy that a floor control server follows to grant or deny f
loors is outside the scope of this document. A given floor control server may pe
rform these decisions automatically while another may contact a human acting as
a chair every time a decision needs to be made.</t>
</aside>
<t>The floor control server <bcp14>MUST</bcp14> copy the Conference ID
, the Transaction ID, and the User ID from the FloorRequest into the FloorReques
tStatus, as described in <xref target="sec_transactions_server" format="default"
/>. Additionally, the floor control server <bcp14>MUST</bcp14> add a FLOOR-REQUE
ST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes conta
ined in this grouped attribute carry information about the floor request.</t>
<t>The floor control server <bcp14>MUST</bcp14> assign an identifier t
hat is unique within the conference to this floor request, and <bcp14>MUST</bcp1
4> insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attr
ibute. This identifier will be used by the floor participant (or by a chair or c
hairs) to refer to this specific floor request in the future.</t>
<t>The floor control server <bcp14>MUST</bcp14> copy the Floor IDs in
the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attrib
utes in the FLOOR-REQUEST-INFORMATION grouped attribute. These Floor IDs identif
y the floors being requested (i.e., the floors associated with this particular f
loor request).</t>
<t>The floor control server <bcp14>SHOULD</bcp14> copy (if present) th
e contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICI
ARY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute
. Additionally, the floor control server <bcp14>MAY</bcp14> provide the display
name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</
t>
<t>The floor control server <bcp14>MAY</bcp14> provide information abo
ut the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute.</t>
<t>The floor control server <bcp14>MAY</bcp14> copy (if present) the P
RIORITY attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION group
ed attribute.</t>
<!-- [auth] note: assumed bug in RFC 4582. s/PARTICIPANT-PROVIDED-INFO
attr/PRIORITY attr/ -->
<aside>
<t>Note that this attribute carries the priority requested by the pa
rticipant. The priority that the floor control server assigns to the floor reque
st depends on the priority requested by the participant and the rights the parti
cipant has according to the policy of the conference. For example, a participant
that is only allowed to use the Normal priority may request Highest priority fo
r a floor request. In that case, the floor control server would ignore the prior
ity requested by the participant.</t>
</aside>
<t>The floor control server <bcp14>MAY</bcp14> copy (if present) the P
ARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-
INFORMATION grouped attribute.</t>
</section>
<section anchor="sec_server_request_subsequent" numbered="true" toc="def
ault">
<name>Generation of Subsequent FloorRequestStatus Messages</name>
<t>A floor request is considered to be ongoing as long as it is not in
the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST-STATUS attri
bute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first Floor
RequestStatus message generated by the floor control server did not indicate any
of these states, the floor control server will need to send subsequent FloorReq
uestStatus messages.</t>
<t>When the status of the floor request changes, the floor control ser
ver <bcp14>SHOULD</bcp14> send new FloorRequestStatus messages with the appropri
ate Request Status. The floor control server <bcp14>MUST</bcp14> add a FLOOR-REQ
UEST-INFORMATION attribute with a Floor Request ID equal to the one sent in the
first FloorRequestStatus message to any new FloorRequestStatus related to the sa
me floor request. (The Floor Request ID identifies the floor request to which th
e FloorRequestStatus applies.)</t>
<t>When using BFCP over a reliable transport, the floor control server
<bcp14>MUST</bcp14> set the Transaction ID of subsequent FloorRequestStatus mes
sages to zero. When using BFCP over an unreliable transport, the Transaction ID
<bcp14>MUST</bcp14> be non-zero and unique in the context of outstanding transac
tions over an unreliable transport as described in <xref target="sec_transaction
s" format="default"/>.</t>
<aside>
<t>The rate at which the floor control server sends FloorRequestStat
us messages is a matter of local policy. A floor control server may choose to se
nd a new FloorRequestStatus message every time the floor request moves in the fl
oor request queue, while another may choose only to send a new FloorRequestStatu
s message when the floor request is Granted or Denied.</t>
</aside>
<t>The floor control server may add a STATUS-INFO attribute to any of
the FloorRequestStatus messages it generates to provide extra information about
its decisions regarding the floor request (e.g., why it was denied).</t>
<aside>
<t>Floor participants and floor chairs may request to be informed ab
out the status of a floor following the procedures in <xref target="sec_client_f
loorinfo" format="default"/>. If the processing of a floor request changes the s
tatus of a floor (e.g., the floor request is granted and consequently the floor
has a new holder), the floor control server needs to follow the procedures in <x
ref target="sec_server_floorinfo" format="default"/> to inform the clients that
have requested that information.</t>
</aside>
<t>The COMMON-HEADER and the rest of the attributes are the same as in
the first FloorRequestStatus message.</t>
<t>The floor control server can discard the state information about a
particular floor request when this reaches a status of Cancelled, Released, or R
evoked.</t>
<t>When communicating over an unreliable transport and a FloorRequestS
tatusAck message is not received within the transaction failure window, the floo
r control server <bcp14>MUST</bcp14> retransmit the FloorRequestStatus message a
ccording to <xref target="udp_transport" format="default"/>.</t>
</section>
</section> </section>
<section anchor="sec_server_requestinfo" numbered="true" toc="default">
<section anchor="timers_cache" title="Response Retransmission Timer, T2"> <name>Reception of a FloorRequestQuery Message</name>
<t>T2 is a timer that, when fired, signals that the BFCP entity can rele <t>On reception of a FloorRequestQuery message, the floor control server
ase knowledge of the transaction against which it is running. It is started upon follows the rules in <xref target="sec_auth" format="default"/> that relate to
the first transmission of the response to a request and is the only mechanism b client authentication and authorization. If while processing the FloorRequestQue
y which that response is released by the BFCP entity. Any subsequent retransmiss ry message, the floor control server encounters an error, it <bcp14>MUST</bcp14>
ions of the same request can be responded to by replaying the cached response, w generate an Error response following the procedures described in <xref target="
hilst that value is retained until the timer has fired. Refer to <xref target="f sec_server_error" format="default"/>.</t>
ragmentation_handling"/> for the role this timer has in the fragmentation handli <t>The successful processing of a FloorRequestQuery message by a floor c
ng scheme.</t> ontrol server involves generating a FloorRequestStatus message, which <bcp14>SHO
ULD</bcp14> be generated as soon as possible.</t>
<t>When communicating over an unreliable transport and upon receiving a
FloorRequestQuery from a participant, the floor control server <bcp14>MUST</bcp1
4> respond with a FloorRequestStatus message within the transaction failure wind
ow to complete the transaction.</t>
<t>The floor control server <bcp14>MUST</bcp14> copy the Conference ID,
the Transaction ID, and the User ID from the FloorRequestQuery message into the
FloorRequestStatus message, as described in <xref target="sec_transactions_serve
r" format="default"/>. Additionally, the floor control server <bcp14>MUST</bcp14
> include information about the floor request in the FLOOR-REQUEST-INFORMATION g
rouped attribute to the FloorRequestStatus.</t>
<t>The floor control server <bcp14>MUST</bcp14> copy the contents of the
FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into the Floor Re
quest ID field of the FLOOR-REQUEST-INFORMATION attribute.</t>
<t>The floor control server <bcp14>MUST</bcp14> add FLOOR-REQUEST-STATUS
attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the f
loors being requested (i.e., the floors associated with the floor request identi
fied by the FLOOR-REQUEST-ID attribute).</t>
<t>The floor control server <bcp14>SHOULD</bcp14> add a BENEFICIARY-ID a
ttribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the bene
ficiary of the floor request. Additionally, the floor control server <bcp14>MAY
</bcp14> provide the display name and the URI of the beneficiary in this BENEFIC
IARY-INFORMATION attribute.</t>
<t>The floor control server <bcp14>MAY</bcp14> provide information about
the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the F
LOOR-REQUEST-INFORMATION grouped attribute.</t>
<t>The floor control server <bcp14>MAY</bcp14> provide the reason why th
e floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.</t>
<t>The floor control server <bcp14>MAY</bcp14> also add to the FLOOR-REQ
UEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value
requested for the floor request and a STATUS-INFO attribute with extra informati
on about the floor request.</t>
<t>The floor control server <bcp14>MUST</bcp14> add an OVERALL-REQUEST-S
TATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the curr
ent status of the floor request. The floor control server <bcp14>MAY</bcp14> pro
vide information about the status of the floor request as it relates to each of
the floors being requested in the FLOOR-REQUEST-STATUS attributes.</t>
</section> </section>
<section anchor="sec_server_userinfo" numbered="true" toc="default">
<section anchor="timers_values" title="Timer Values"> <name>Reception of a UserQuery Message</name>
<t>The table below defines the different timers required when BFCP entit <t>On reception of a UserQuery message, the floor control server follows
ies communicate over an unreliable transport.</t> the rules in <xref target="sec_auth" format="default"/> that relate to client a
<texttable anchor="timertable" title="Timers"> uthentication and authorization. If while processing the UserQuery message, the
<ttcol align='center'>Timer</ttcol> floor control server encounters an error, it <bcp14>MUST</bcp14> generate an Err
<ttcol align='left'>Description</ttcol> or response following the procedures described in <xref target="sec_server_error
<ttcol align='center'>Value/s</ttcol> " format="default"/>.</t>
<c>T1</c> <c>Initial request retransmission timer</c> <c>0.5s (initial) <t>The successful processing of a UserQuery message by a floor control s
</c> erver involves generating a UserStatus message, which <bcp14>SHOULD</bcp14> be g
<c>T2</c> <c>Response retransmission timer</c> <c>(T1*2^4)*1.25< enerated as soon as possible.</t>
/c> <t>When communicating over an unreliable transport and upon receiving a
</texttable> UserQuery from a participant, the floor control server <bcp14>MUST</bcp14> respo
<t></t> nd with a UserStatus message within the transaction failure window to complete t
<t>The initial value for T1 is 500ms, which is an estimate of the RTT fo he transaction.</t>
r completing the transaction. Computation of this value follows the procedures <t>The floor control server <bcp14>MUST</bcp14> copy the Conference ID,
described in <xref target="timers_retrans"/>, which includes exponential backoff the Transaction ID, and the User ID from the UserQuery message into the UserStat
s on retransmissions.</t> us message, as described in <xref target="sec_transactions_server" format="defau
<t>T2 MUST be set such that it encompasses all legal retransmissions per lt"/>.</t>
T1 plus a factor to accommodate network latency between BFCP entities, processi <t>The sender of the UserQuery message is requesting information about a
ng delays, etc.</t> ll the floor requests associated with a given participant (i.e., the floor reque
sts where the participant is either the beneficiary or the requester). This part
icipant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENE
FICIARY-ID attribute, by a the User ID in the COMMON-HEADER of the UserQuery mes
sage.</t>
<t>The floor control server <bcp14>MUST</bcp14> copy, if present, the co
ntents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFIC
IARY-INFORMATION attribute in the UserStatus message. Additionally, the floor co
ntrol server <bcp14>MAY</bcp14> provide the display name and the URI of the part
icipant about which the UserStatus message provides information in this BENEFICI
ARY-INFORMATION attribute.</t>
<t>The floor control server <bcp14>SHOULD</bcp14> add to the UserStatus
message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request rel
ated to the participant about which the message provides information (i.e., the
floor requests where the participant is either the beneficiary or the requester)
. For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows
the following steps.</t>
<t>The floor control server <bcp14>MUST</bcp14> identify the floor reque
st the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Reque
st ID field of the FLOOR-REQUEST-INFORMATION attribute.</t>
<t>The floor control server <bcp14>MUST</bcp14> add FLOOR-REQUEST-STATUS
attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the f
loors being requested (i.e., the floors associated with the floor request identi
fied by the FLOOR-REQUEST-ID attribute).</t>
<t>The floor control server <bcp14>SHOULD</bcp14> add a BENEFICIARY-ID a
ttribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the bene
ficiary of the floor request. Additionally, the floor control server <bcp14>MAY
</bcp14> provide the display name and the URI of the beneficiary in this BENEFIC
IARY-INFORMATION attribute.</t>
<t>The floor control server <bcp14>MAY</bcp14> provide information about
the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the F
LOOR-REQUEST-INFORMATION grouped attribute.</t>
<t>The floor control server <bcp14>MAY</bcp14> provide the reason why th
e floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.</t>
<t>The floor control server <bcp14>MAY</bcp14> also add to the FLOOR-REQ
UEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value
requested for the floor request.</t>
<t>The floor control server <bcp14>MUST</bcp14> include the current stat
us of the floor request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQU
EST-INFORMATION grouped attribute. The floor control server <bcp14>MAY</bcp14> a
dd a STATUS-INFO attribute with extra information about the floor request.</t>
<t>The floor control server <bcp14>MAY</bcp14> provide information about
the status of the floor request as it relates to each of the floors being reque
sted in the FLOOR-REQUEST-STATUS attributes.</t>
</section> </section>
</section> <section anchor="sec_server_release" numbered="true" toc="default">
</section> <name>Reception of a FloorRelease Message</name>
<t>On reception of a FloorRelease message, the floor control server foll
<section title="Authentication and Authorization" anchor="sec:auth"> ows the rules in <xref target="sec_auth" format="default"/> that relate to clien
<t>BFCP clients SHOULD authenticate the floor control server before sending t authentication and authorization. If while processing the FloorRelease message
any BFCP message to it or accepting any BFCP message from it. Similarly, floor c , the floor control server encounters an error, it <bcp14>MUST</bcp14> generate
ontrol servers SHOULD authenticate a client before accepting any BFCP message fr an Error response following the procedures described in <xref target="sec_server
om it or sending any BFCP message to it.</t> _error" format="default"/>.</t>
<t>If the signaling or control protocol traffic used to set up the conferenc <t>The successful processing of a FloorRelease message by a floor contro
e is authenticated and confidentiality and integrity protected, and the extensio l server involves generating a FloorRequestStatus message, which <bcp14>SHOULD</
ns in this document are supported, the BFCP clients MUST authenticate the floor bcp14> be generated as soon as possible.</t>
control server and the floor control servers MUST authenticate the client before <t>When communicating over an unreliable transport and upon receiving a
communicating as described above. Note that BFCP entities supporting only the < FloorRelease from a participant, the floor control server <bcp14>MUST</bcp14> re
xref target="RFC4582"/> subset may not comply with this mandatory authentication spond with a FloorRequestStatus message within the transaction failure window to
requirement.</t> complete the transaction.</t>
<t>BFCP supports TLS/DTLS mutual authentication between clients and floor co <t>The floor control server <bcp14>MUST</bcp14> copy the Conference ID,
ntrol servers, as specified in <xref target="sec:auth:tls"/>. This is the RECOMM the Transaction ID, and the User ID from the FloorRelease message into the Floor
ENDED authentication mechanism in BFCP.</t> RequestStatus message, as described in <xref target="sec_transactions_server" fo
<t>Note that future extensions may define additional authentication mechanis rmat="default"/>.</t>
ms.</t> <t>The floor control server <bcp14>MUST</bcp14> add a FLOOR-REQUEST-INFO
<t>In addition to authenticating BFCP messages, floor control servers need t RMATION grouped attribute to the FloorRequestStatus. The attributes contained in
o authorize them. On receiving an authenticated BFCP message, the floor control this grouped attribute carry information about the floor request.</t>
server checks whether the client sending the message is authorized. If the clien <t>The FloorRelease message identifies the floor request it applies to u
t is not authorized to perform the operation being requested, the floor control sing a FLOOR-REQUEST-ID. The floor control server <bcp14>MUST</bcp14> copy the c
server generates an Error message, as described in <xref target="sec:server:erro ontents of the FLOOR-REQUEST-ID attribute from the FloorRelease message into the
r"/>, with an Error code with a value of 5 (Unauthorized Operation). Messages fr Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.</t>
om a client that cannot be authorized MUST NOT be processed further.</t> <t>The floor control server <bcp14>MUST</bcp14> identify the floors bein
g released (i.e., the floors associated with the floor request identified by the
<section title="TLS/DTLS Based Mutual Authentication" anchor="sec:auth:tls"> FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQ
<t>BFCP supports TLS/DTLS based mutual authentication between clients and UEST-INFORMATION grouped attribute.</t>
floor control servers. If TLS/DTLS is used, an initial integrity-protected chan <t>The floor control server <bcp14>MUST</bcp14> add an OVERALL-REQUEST-S
nel is REQUIRED between the client and the floor control server that can be used TATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request
to exchange their certificates (which MAY be self-signed certificates) or, more Status value <bcp14>SHOULD</bcp14> be Released, if the floor (or floors) had be
commonly, the fingerprints of these certificates. These certificates are used en previously granted, or Cancelled, if the floor (or floors) had not been previ
at TLS/DTLS establishment time.</t> ously granted. The floor control server <bcp14>MAY</bcp14> add a STATUS-INFO at
<t><list style="hanging"> tribute with extra information about the floor request.</t>
<t>The implementation of such an integrity-protected channel using SIP
and the SDP offer/answer model is described in <xref target="I-D.ietf-bfcpbis-r
fc4583bis"/>.</t>
</list></t>
<t>BFCP messages received over an authenticated TLS/DTLS connection are co
nsidered authenticated. A floor control server that receives a BFCP message over
TCP/UDP (no TLS/DTLS) MAY request the use of TLS/DTLS by generating an Error me
ssage, as described in <xref target="sec:server:error"/>, with an Error code wit
h a value of 9 (Use TLS) or a value of 11 (Use DTLS) respectively. Clients con
figured to require the use of TLS/DTLS MUST ignore unauthenticated messages.</t>
<t>Note that future extensions may define additional authentication mechan
isms that may not require an initial integrity-protected channel (e.g., authenti
cation based on certificates signed by a certificate authority).</t>
<t>As described in <xref target="sec:auth"/>, floor control servers need t
o perform authorization before processing any message. In particular, the floor
control server MUST check that messages arriving over a given authenticated TLS/
DTLS connection use an authorized User ID (i.e., a User ID that the user that es
tablished the authenticated TLS/DTLS connection is allowed to use).</t>
</section>
</section>
<section title="Floor Participant Operations" anchor="sec:participant">
<t>This section specifies how floor participants can perform different opera
tions, such as requesting a floor, using the protocol elements described in earl
ier sections. <xref target="sec:chair"/> specifies operations that are specific
to floor chairs, such as instructing the floor control server to grant or revoke
a floor, and <xref target="sec:client"/> specifies operations that can be perfo
rmed by any client (i.e., both floor participants and floor chairs).</t>
<section title="Requesting a Floor" anchor="sec:participant:request">
<t>A floor participant that wishes to request one or more floors does so b
y sending a FloorRequest message to the floor control server.</t>
<section title="Sending a FloorRequest Message" anchor="sec:participant:re
quest:send">
<t>The ABNF in <xref target="sec:msg_format:FloorRequest"/> describes th
e attributes that a FloorRequest message can contain. In addition, the ABNF spec
ifies normatively which of these attributes are mandatory, and which ones are op
tional.</t>
<t>The floor participant sets the Conference ID and the Transaction ID i
n the common header following the rules given in <xref target="sec:transactions:
client"/>.</t>
<t>The floor participant sets the User ID in the common header to the fl
oor participant's identifier. If the sender of the FloorRequest message (identi
fied by the User ID) is not the participant that would eventually get the floor
(i.e., a third-party floor request), the sender SHOULD add a BENEFICIARY-ID attr
ibute to the message identifying the beneficiary of the floor.</t>
<t><list style="hanging">
<t>Note that the name space for both the User ID and the Beneficiary
ID is the same. That is, a given participant is identified by a single 16-bit v
alue that can be used in the User ID in the common header and in several attribu
tes: BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED-BY-INFORMATION.</t>
</list></t>
<t>The floor participant MUST insert at least one FLOOR-ID attribute in
the FloorRequest message. If the client inserts more than one FLOOR-ID attribute
, the floor control server will treat all the floor requests as an atomic packag
e. That is, the floor control server will either grant or deny all the floors in
the FloorRequest message.</t>
<t>The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute t
o state the reason why the floor or floors are being requested. The Text field i
n the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption.</t>
<t>The floor participant may request that the server handle the floor re
quest with a certain priority using a PRIORITY attribute.</t>
</section> </section>
<section anchor="sec_server_floorinfo" numbered="true" toc="default">
<section title="Receiving a Response" anchor="sec:client:request:response" <name>Reception of a FloorQuery Message</name>
> <t>On reception of a FloorQuery message, the floor control server follow
<t>A message from the floor control server is considered a response to t s the rules in <xref target="sec_auth" format="default"/> that relate to client
he FloorRequest message if the message from the floor control server has the sam authentication. If while processing the FloorQuery message, the floor control se
e Conference ID, Transaction ID, and User ID as the FloorRequest message, as des rver encounters an error, it <bcp14>MUST</bcp14> generate an Error response foll
cribed in <xref target="sec:transactions:client"/>. On receiving such a response owing the procedures described in <xref target="sec_server_error" format="defaul
, the floor participant follows the rules in <xref target="sec:auth"/> that rela t"/>.</t>
te to floor control server authentication.</t> <t>When communicating over an unreliable transport and upon receiving a
<t>The successful processing of a FloorRequest message at the floor cont FloorQuery from a participant, the floor control server <bcp14>MUST</bcp14> resp
rol server involves generating one or several FloorRequestStatus messages. The f ond with a FloorStatus message within the transaction failure window to complete
loor participant obtains a Floor Request ID in the Floor Request ID field of a F the transaction.</t>
LOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from <t>A floor control server receiving a FloorQuery message from a client <
the floor control server. Subsequent FloorRequestStatus messages from the floor bcp14>SHOULD</bcp14> keep this client informed about the status of the floors id
control server regarding the same floor request will carry the same Floor Reques entified by FLOOR-ID attributes in the FloorQuery message. Floor control servers
t ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus keep clients informed by using FloorStatus messages.</t>
message. This way, the floor participant can associate subsequent incoming Floor <t>An individual FloorStatus message carries information about a single
RequestStatus messages with the ongoing floor request.</t> floor. So, when a FloorQuery message requests information about more than one fl
<t>The floor participant obtains information about the status of the flo oor, the floor control server needs to send separate FloorStatus messages for di
or request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorReques fferent floors.</t>
tStatus messages received from the floor control server. This attribute is a gro <t>The information FloorQuery messages carry may depend on the user requ
uped attribute, and as such it includes a number of attributes that provide info esting the information. For example, a chair may be able to receive information
rmation about the floor request.</t> about pending requests, while a regular user may not be authorized to do so.</t>
<t>The OVERALL-REQUEST-STATUS attribute provides information about the o <section anchor="sec_server_floorinfo_first" numbered="true" toc="defaul
verall status of the floor request. If the Request Status value is Granted, all t">
the floors that were requested in the FloorRequest message have been granted. If <name>Generation of the First FloorStatus Message</name>
the Request Status value is Denied, all the floors that were requested in the F <t>The successful processing of a FloorQuery message by a floor contro
loorRequest message have been denied. A floor request is considered to be ongoin l server involves generating one or several FloorStatus messages, the first of w
g while it is in the Pending, Accepted, or Granted states. If the floor request hich <bcp14>SHOULD</bcp14> be generated as soon as possible.</t>
value is unknown, then the response is still processed. However, no meaningful <t>The floor control server <bcp14>MUST</bcp14> copy the Conference ID
value can be reported to the user.</t> , the Transaction ID, and the User ID from the FloorQuery message into the Floor
<t>The STATUS-INFO attribute, if present, provides extra information tha Status message, as described in <xref target="sec_transactions_server" format="d
t the floor participant can display to the user.</t> efault"/>.</t>
<t>The FLOOR-REQUEST-STATUS attributes provide information about the sta <t>If the FloorQuery message did not contain any FLOOR-ID attribute, t
tus of the floor request as it relates to a particular floor. The STATUS-INFO a he floor control server sends the FloorStatus message without adding any additio
ttribute, if present, provides extra information that the floor participant can nal attribute and does not send any subsequent FloorStatus message to the floor
display to the user.</t> participant.</t>
<t>The BENEFICIARY-INFORMATION attribute identifies the beneficiary of t <t>If the FloorQuery message contained one or more FLOOR-ID attributes
he floor request in third-party floor requests. The REQUESTED-BY-INFORMATION at , the floor control server chooses one from among them and adds this FLOOR-ID at
tribute need not be present in FloorRequestStatus messages received by the floor tribute to the FloorStatus message. The floor control server <bcp14>SHOULD</bcp1
participant that requested the floor, as this floor participant is already iden 4> add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request asso
tified by the User ID in the common header.</t> ciated to the floor. Each FLOOR-REQUEST-INFORMATION grouped attribute contains a
<t>The PRIORITY attribute, when present, contains the priority that was number of attributes that provide information about the floor request. For each
requested by the generator of the FloorRequest message.</t> FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the follo
<t>If the response is an Error message, the floor control server could n wing steps.</t>
ot process the FloorRequest message for some reason, which is described in the E <t>The floor control server <bcp14>MUST</bcp14> identify the floor req
rror message.</t> uest the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Req
uest ID field of the FLOOR-REQUEST-INFORMATION attribute.</t>
<t>The floor control server <bcp14>MUST</bcp14> add FLOOR-REQUEST-STAT
US attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the
floors being requested (i.e., the floors associated with the floor request iden
tified by the FLOOR-REQUEST-ID attribute).</t>
<t>The floor control server <bcp14>SHOULD</bcp14> add a BENEFICIARY-ID
attribute to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the be
neficiary of the floor request. Additionally, the floor control server <bcp14>M
AY</bcp14> provide the display name and the URI of the beneficiary in this BENEF
ICIARY-INFORMATION attribute.</t>
<t>The floor control server <bcp14>MAY</bcp14> provide information abo
ut the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the
FLOOR-REQUEST-INFORMATION grouped attribute.</t>
<t>The floor control server <bcp14>MAY</bcp14> provide the reason why
the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.</t>
<t>The floor control server <bcp14>MAY</bcp14> also add to the FLOOR-R
EQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority valu
e requested for the floor request.</t>
<t>The floor control server <bcp14>MUST</bcp14> add an OVERALL-REQUEST
-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute with the cu
rrent status of the floor request. The floor control server <bcp14>MAY</bcp14> a
dd a STATUS-INFO attribute with extra information about the floor request.</t>
<t>The floor control server <bcp14>MAY</bcp14> provide information abo
ut the status of the floor request as it relates to each of the floors being req
uested in the FLOOR-REQUEST-STATUS attributes.</t>
</section>
<section anchor="sec_server_floorinfo_subsequent" numbered="true" toc="d
efault">
<name>Generation of Subsequent FloorStatus Messages</name>
<t>If the FloorQuery message carried more than one FLOOR-ID attribute,
the floor control server <bcp14>SHOULD</bcp14> generate a FloorStatus message f
or each of them (except for the FLOOR-ID attribute chosen for the first FloorSta
tus message) as soon as possible. These FloorStatus messages are generated follo
wing the same rules as those for the first FloorStatus message (see <xref target
="sec_server_floorinfo_first" format="default"/>), but their Transaction ID is 0
when using a reliable transport and non-zero and unique in the context of outst
anding transactions when using an unreliable transport (cf.&nbsp;<xref target="s
ec_transactions" format="default"/>).</t>
<t>After generating these messages, the floor control server sends Flo
orStatus messages, periodically keeping the client informed about all the floors
for which the client requested information. The Transaction ID of these message
s <bcp14>MUST</bcp14> be 0 when using a reliable transport and non-zero and uniq
ue in the context of outstanding transactions when using an unreliable transport
(cf.&nbsp;<xref target="sec_transactions" format="default"/>).</t>
<aside>
<t>The rate at which the floor control server sends FloorStatus mess
ages is a matter of local policy. A floor control server may choose to send a ne
w FloorStatus message every time a new floor request arrives, while another may
choose to only send a new FloorStatus message when a new floor request is Grante
d.</t>
</aside>
<t>When communicating over an unreliable transport and a FloorStatusAc
k message is not received within the transaction failure window, the floor contr
ol server <bcp14>MUST</bcp14> retransmit the FloorStatus message according to <x
ref target="udp_transport" format="default"/>.</t>
</section>
</section> </section>
<section anchor="sec_server_chairaction" numbered="true" toc="default">
<section title="Reception of a Subsequent FloorRequestStatus Message" anch <name>Reception of a ChairAction Message</name>
or="sec:recept:frsm"> <t>On reception of a ChairAction message, the floor control server follo
<t>When communicating over an unreliable transport and upon receiving a F ws the rules in <xref target="sec_auth" format="default"/> that relate to client
loorRequestStatus message from a floor control server, the participant MUST resp authentication and authorization. If while processing the ChairAction message,
ond with a FloorRequestStatusAck message within the transaction failure window t the floor control server encounters an error, it <bcp14>MUST</bcp14> generate an
o complete the transaction.</t> Error response following the procedures described in <xref target="sec_server_e
rror" format="default"/>.</t>
<t>The successful processing of a ChairAction message by a floor control
server involves generating a ChairActionAck message, which <bcp14>SHOULD</bcp14
> be generated as soon as possible.</t>
<t>When communicating over an unreliable transport and upon receiving a
ChairAction from a chair, the floor control server <bcp14>MUST</bcp14> respond w
ith a ChairActionAck message within the transaction failure window to complete t
he transaction.</t>
<t>The floor control server <bcp14>MUST</bcp14> copy the Conference ID,
the Transaction ID, and the User ID from the ChairAction message into the ChairA
ctionAck message, as described in <xref target="sec_transactions_server" format=
"default"/>.</t>
<t>The floor control server needs to take into consideration the operati
on requested in the ChairAction message (e.g., granting a floor) but does not ne
cessarily need to perform it as requested by the floor chair. The operation that
the floor control server performs depends on the ChairAction message and on the
internal state of the floor control server.</t>
<t>For example, a floor chair may send a ChairAction message granting a
floor that was requested as part of an atomic floor request operation that invol
ved several floors. Even if the chair responsible for one of the floors instruct
s the floor control server to grant the floor, the floor control server will not
grant it until the chairs responsible for the other floors agree to grant them
as well.</t>
<t>So, the floor control server is ultimately responsible for keeping a
coherent floor state using instructions from floor chairs as input to this state
.</t>
<t>If the new Status in the ChairAction message is Accepted and all the
bits of the Queue Position field are zero, the floor chair is requesting that th
e floor control server assign a queue position (e.g., the last in the queue) to
the floor request based on the local policy of the floor control server. (Of cou
rse, such a request only applies if the floor control server implements a queue.
)</t>
</section> </section>
</section> <section anchor="sec_server_helloack" numbered="true" toc="default">
<name>Reception of a Hello Message</name>
<section title="Cancelling a Floor Request and Releasing a Floor" anchor="se <t>On reception of a Hello message, the floor control server follows the
c:participant:cancel"> rules in <xref target="sec_auth" format="default"/> that relate to client authe
<t>A floor participant that wishes to cancel an ongoing floor request does ntication. If while processing the Hello message, the floor control server encou
so by sending a FloorRelease message to the floor control server. The FloorRele nters an error, it <bcp14>MUST</bcp14> generate an Error response following the
ase message is also used by floor participants that hold a floor and would like procedures described in <xref target="sec_server_error" format="default"/>.</t>
to release it.</t> <t>If the version of BFCP specified in the version field of the COMMON-H
EADER is supported by the floor control server, it <bcp14>MUST</bcp14> respond w
<section title="Sending a FloorRelease Message" anchor="sec:participant:ca ith the same version number in the HelloAck; this defines the version for all su
ncel:send"> bsequent BFCP messages within this BFCP Connection.</t>
<t>The ABNF in <xref target="sec:msg_format:FloorRelease"/> describes th <t>When communicating over an unreliable transport and upon receiving a
e attributes that a FloorRelease message can contain. In addition, the ABNF spec Hello from a participant, the floor control server <bcp14>MUST</bcp14> respond w
ifies normatively which of these attributes are mandatory, and which ones are op ith a HelloAck message within the transaction failure window to complete the tra
tional.</t> nsaction.</t>
<t>The floor participant sets the Conference ID and the Transaction ID i <t>The successful processing of a Hello message by a floor control serve
n the common header following the rules given in <xref target="sec:transactions: r involves generating a HelloAck message, which <bcp14>SHOULD</bcp14> be generat
client"/>. The floor participant sets the User ID in the common header to the fl ed as soon as possible. The floor control server <bcp14>MUST</bcp14> copy the Co
oor participant's identifier.</t> nference ID, the Transaction ID, and the User ID from the Hello into the HelloAc
<t><list style="empty"> k, as described in <xref target="sec_transactions_server" format="default"/>.</t
<t>Note that the FloorRelease message is used to release a floor or >
floors that were granted and to cancel ongoing floor requests (from the protocol <t>The floor control server <bcp14>MUST</bcp14> add a SUPPORTED-PRIMITIV
perspective, both are ongoing floor requests). Using the same message in both s ES attribute to the HelloAck message listing all the primitives (i.e., BFCP mess
ituations helps resolve the race condition that occurs when the FloorRelease mes ages) supported by the floor control server.</t>
sage and the FloorGrant message cross each other on the wire.</t> <t>The floor control server <bcp14>MUST</bcp14> add a SUPPORTED-ATTRIBUT
</list></t> ES attribute to the HelloAck message listing all the attributes supported by the
<t>The floor participant uses the FLOOR-REQUEST-ID that was received in floor control server.</t>
the response to the FloorRequest message that the FloorRelease message is cancel
ling.</t>
<t><list style="empty">
<t>Note that if the floor participant requested several floors as an
atomic operation (i.e., in a single FloorRequest message), all the floors are r
eleased as an atomic operation as well (i.e., all are released at the same time)
.</t>
</list></t>
</section> </section>
<section anchor="sec_server_error" numbered="true" toc="default">
<section title="Receiving a Response" anchor="sec:participant:cancel:respo <name>Error Message Generation</name>
nse"> <t>Error messages are always sent in response to a previous message from
<t>A message from the floor control server is considered a response to t the client as part of a client-initiated transaction. The ABNF in <xref target=
he FloorRelease message if the message from the floor control server has the sam "sec_msg_format_Error" format="default"/> describes the attributes that an Error
e Conference ID, Transaction ID, and User ID as the FloorRelease message, as des message can contain. In addition, the ABNF specifies normatively which of these
cribed in <xref target="sec:transactions:client"/>. On receiving such a response attributes are mandatory and which ones are optional.</t>
, the floor participant follows the rules in <xref target="sec:auth"/> that rela <t>The floor control server <bcp14>MUST</bcp14> copy the Conference ID,
te to floor control server authentication.</t> the Transaction ID, and the User ID from the message from the client into the Er
<t>If the response is a FloorRequestStatus message, the Request Status v ror message, as described in <xref target="sec_transactions_server" format="defa
alue in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATI ult"/>.</t>
ON grouped attribute) will be Cancelled or Released.</t> <t>The floor control server <bcp14>MUST</bcp14> add an ERROR-CODE attrib
<t>If the response is an Error message, the floor control server could n ute to the Error message. The ERROR-CODE attribute contains an error code from <
ot process the FloorRequest message for some reason, which is described in the E xref target="tab_errorcode" format="default"/>. Additionally, the floor control
rror message.</t> server may add an ERROR-INFO attribute with extra information about the error.</
<t>It is possible that the FloorRelease message crosses on the wire with t>
a FloorRequestStatus message from the server with a Request Status different fr
om Cancelled or Released. In any case, such a FloorRequestStatus message will no
t be a response to the FloorRelease message, as its Transaction ID will not matc
h that of the FloorRelease.</t>
</section> </section>
</section> </section>
</section> <section anchor="sec_security" numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Chair Operations" anchor="sec:chair"> <t>BFCP uses TLS/DTLS to provide mutual authentication between clients and
<t>This section specifies how floor chairs can instruct the floor control se servers. TLS/DTLS also provides replay and integrity protection and confidentia
rver to grant or revoke a floor using the protocol elements described in earlier lity. It is <bcp14>RECOMMENDED</bcp14> that TLS/DTLS with an encryption algorit
sections.</t> hm according to <xref target="sec_lower-security" format="default"/> always be u
<t>Floor chairs that wish to send instructions to a floor control server do sed. In cases where signaling/control traffic is properly protected, as describ
so by sending a ChairAction message.</t> ed in <xref target="sec_auth" format="default"/>, it is <bcp14>REQUIRED</bcp14>
to use a mandated encryption algorithm. BFCP entities <bcp14>MAY</bcp14> use ot
<section title="Sending a ChairAction Message" anchor="sec:chair:send"> her security mechanisms to interwork with legacy implementation that do not use
<t>The ABNF in <xref target="sec:msg_format:ChairAction"/> describes the a TLS/DTLS as long as these mechanisms provide similar security properties. An ex
ttributes that a ChairAction message can contain. In addition, the ABNF specifie ample of other mechanisms to effectively secure a nonsecure BFCP connection is I
s normatively which of these attributes are mandatory, and which ones are option Psec <xref target="RFC4301" format="default"/>.</t>
al.</t> <t>The remainder of this section analyzes some of the threats against BFCP
<t>The floor chair sets the Conference ID and the Transaction ID in the co and how they are addressed.</t>
mmon header following the rules given in <xref target="sec:transactions:client"/ <t>An attacker may attempt to impersonate a client (a floor participant or
>. The floor chair sets the User ID in the common header to the floor chair's id a floor chair) in order to generate forged floor requests or to grant or deny e
entifier.</t> xisting floor requests. Client impersonation is avoided by having servers only a
<t>The ChairAction message contains instructions that apply to one or more ccept BFCP messages over authenticated TLS/DTLS connections. The floor control s
floors within a particular floor request. The floor or floors are identified by erver assumes that attackers cannot hijack the TLS/DTLS connection and, therefor
the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the e, that messages over the TLS/DTLS connection come from the client that was init
FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message.< ially authenticated.</t>
/t> <t>An attacker may attempt to impersonate a floor control server. A succes
<t>For example, if a floor request consists of two floors that depend on d sful attacker would be able to make clients think that they hold a particular fl
ifferent floor chairs, each floor chair will grant its floor within the floor re oor so that they would try to access a resource (e.g., sending media) without ha
quest. Once both chairs have granted their floor, the floor control server will ving legitimate rights to access it. Floor control server impersonation is avoid
grant the floor request as a whole. On the other hand, if one of the floor chair ed by having servers only accept BFCP messages over authenticated TLS/DTLS conne
s denies its floor, the floor control server will deny the floor request as a wh ctions, as well as ensuring clients only send and accept messages over authentic
ole, regardless of the other floor chair's decision.</t> ated TLS/DTLS connections.</t>
<t>The floor chair provides the new status of the floor request as it rela <t>Attackers may attempt to modify messages exchanged by a client and a fl
tes to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new sta oor control server. The integrity protection provided by TLS/DTLS connections pr
tus of the floor request is Accepted, the floor chair MAY use the Queue Position events this attack.</t>
field to provide a queue position for the floor request. If the floor chair doe <t>An attacker may attempt to fetch a valid message sent by a client to a
s not wish to provide a queue position, all the bits of the Queue Position field floor control server and replay it over a connection between the attacker and th
MUST be set to zero. The floor chair MUST use the Status Revoked to revoke a fl e floor control server. This attack is prevented by having floor control servers
oor that was granted (i.e., Granted status) and MUST use the Status Denied to re check that messages arriving over a given authenticated TLS/DTLS connection use
ject floor requests in any other status (e.g., Pending and Accepted).</t> an authorized user ID (i.e., a user ID that the user that established the authe
<t>The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the Chai nticated TLS/DTLS connection is allowed to use).</t>
rAction message to provide a new overall status for the floor request. If the n <t>Attackers may attempt to pick messages from the network to get access t
ew overall status of the floor request is Accepted, the floor chair can use the o confidential information between the floor control server and a client (e.g.,
Queue Position field to provide a queue position for the floor request.</t> why a floor request was denied). TLS/DTLS confidentiality prevents this attack.
<t><list style="hanging"> Therefore, it is <bcp14>REQUIRED</bcp14> that TLS/DTLS be used with an encryptio
<t>Note that a particular floor control server can implement a differe n algorithm according to <xref target="sec_lower-security" format="default"/>.</
nt queue for each floor containing all the floor requests that relate to that pa t>
rticular floor, a general queue for all floor requests, or both. Also note that
a floor request can involve several floors and that a ChairAction message can o
nly deal with a subset of these floors (e.g., if a single floor chair is not aut
horized to manage all the floors). In this case, the floor control server will
combine the instructions received from the different floor chairs in FLOOR-REQUE
ST-STATUS attributes to come up with the overall status of the floor request.</t
>
<t>Note that, while the action of a floor chair may communicate inform
ation in the OVERALL-REQUEST-STATUS attribute, the floor control server may over
ride, modify, or ignore this field's content.</t>
</list></t>
<t>The floor chair MAY include STATUS-INFO attributes to state the reason
why the floor or floors are being accepted, granted, or revoked. The Text in the
STATUS-INFO attribute is intended for human consumption.</t>
</section>
<section title="Receiving a Response" anchor="sec:chair:instruct:response">
<t>A message from the floor control server is considered a response to the
ChairAction message if the message from the server has the same Conference ID,
Transaction ID, and User ID as the ChairAction message, as described in <xref ta
rget="sec:transactions:client"/>. On receiving such a response, the floor chair
follows the rules in <xref target="sec:auth"/> that relate to floor control serv
er authentication.</t>
<t>A ChairActionAck message from the floor control server confirms that th
e floor control server has accepted the ChairAction message. An Error message in
dicates that the floor control server could not process the ChairAction message
for some reason, which is described in the Error message.</t>
</section> </section>
</section> <!-- [rfced] Please note that, per discussion with IANA, we have updated
registry names to be plural and not include "Subregistry". If this change is
accepted, We will ask IANA to udpate the registries accordingly.
<section title="General Client Operations" anchor="sec:client"> Current IANA page:
<t>This section specifies operations that can be performed by any client. Th Attribute Subregistry
at is, they are not specific to floor participants or floor chairs. They can be Primitive Subregistry
performed by both.</t> Request Status Subregistry
Error Code Subregistry
<section title="Requesting Information about Floors" anchor="sec:client:floo This document now refers to these as:
rinfo"> "Attributes" subregistry
<t>A client can obtain information about the status of a floor or floors i "Primitives" subregistry
n different ways, which include using BFCP and using out-of-band mechanisms. Cli "Request Statuses" subregistry
ents using BFCP to obtain such information use the procedures described in this "Error Codes" subregistry
section. </t> -->
<t>Clients request information about the status of one or several floors b
y sending a FloorQuery message to the floor control server.</t>
<section title="Sending a FloorQuery Message" anchor="sec:client:floorinfo <section anchor="sec_iana" numbered="true" toc="default">
:send"> <name>IANA Considerations</name>
<t>The ABNF in <xref target="sec:msg_format:FloorQuery"/> describes the
attributes that a FloorQuery message can contain. In addition, the ABNF specifie
s normatively which of these attributes are mandatory, and which ones are option
al.</t>
<t>The client sets the Conference ID and the Transaction ID in the commo
n header following the rules given in <xref target="sec:transactions:client"/>.
The client sets the User ID in the common header to the client's identifier.</t>
<t>The client inserts in the message all the Floor IDs it wants to recei
ve information about. The floor control server will send periodic information ab
out all of these floors. If the client does not want to receive information abou
t a particular floor any longer, it sends a new FloorQuery message removing the
FLOOR-ID of this floor. If the client does not want to receive information about
any floor any longer, it sends a FloorQuery message with no FLOOR-ID attribute.
</t>
</section>
<section title="Receiving a Response" anchor="sec:client:floorinfo:respons <t>The IANA has created a registry for BFCP parameters called "The Binary
e"> Floor Control Protocol (BFCP) Parameters". This registry has a number of subregi
<t>A message from the floor control server is considered a response to t stries, which are described in the following sections.</t>
he FloorQuery message if the message from the floor control server has the same <section numbered="true" toc="default">
Conference ID, Transaction ID, and User ID as the FloorQuery message, as describ <name>Attributes Subregistry</name>
ed in <xref target="sec:transactions:client"/>. On receiving such a response, th <t>This section establishes the "Attributes" subregistry under the BFCP
e client follows the rules in <xref target="sec:auth"/> that relate to floor con Parameters registry. As per the terminology in RFC 8126 <xref
trol server authentication.</t> target="RFC8126" format="default"/>, the registration policy for BFCP
<t>On reception of the FloorQuery message, the floor control server MUST attributes is "Specification Required". For the purposes of this
respond with a FloorStatus message or with an Error message. If the response is subregistry, the BFCP attributes for which IANA registration is
a FloorStatus message, it will contain information about one of the floors the requested <bcp14>MUST</bcp14> be defined by a Standards Track
client requested information about. If the client did not include any FLOOR-ID a RFC. Such an RFC <bcp14>MUST</bcp14> specify the attribute's type,
ttribute in its FloorQuery message (i.e., the client does not want to receive in name, format, and semantics.</t>
formation about any floor any longer), the FloorStatus message from the floor co <t>For each BFCP attribute, the IANA registers its type, its name, and
ntrol server will not include any FLOOR-ID attribute either. </t> the reference to the RFC where the attribute is defined. The following
<t>FloorStatus messages that carry information about a floor contain a F table contains the initial values of this subregistry.</t>
LOOR-ID attribute that identifies the floor. After this attribute, FloorStatus m <table anchor="tab_iana-attributes" align="center">
essages contain information about existing (one or more) floor requests that rel <name>Initial values of the BFCP Attributes subregistry</name>
ate to that floor. The information about each particular floor request is encode <thead>
d in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Flo <tr>
or Request ID that identifies the floor request, followed by a set of attributes <th align="center">Type</th>
that provide information about the floor request.</t> <th align="left">Attribute</th>
<t>After the first FloorStatus, the floor control server will continue s <th align="left">Reference</th>
ending FloorStatus messages, periodically informing the client about changes on </tr>
the floors the client requested information about.</t> </thead>
<tbody>
<tr>
<td align="center">1</td>
<td align="left">BENEFICIARY-ID</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left">FLOOR-ID</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">FLOOR-REQUEST-ID</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">PRIORITY</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left">REQUEST-STATUS</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left">ERROR-CODE</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left">ERROR-INFO</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">8</td>
<td align="left">PARTICIPANT-PROVIDED-INFO</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">9</td>
<td align="left">STATUS-INFO</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">10</td>
<td align="left">SUPPORTED-ATTRIBUTES</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">11</td>
<td align="left">SUPPORTED-PRIMITIVES</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">12</td>
<td align="left">USER-DISPLAY-NAME</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">13</td>
<td align="left">USER-URI</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">14</td>
<td align="left">BENEFICIARY-INFORMATION</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">15</td>
<td align="left">FLOOR-REQUEST-INFORMATION</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">16</td>
<td align="left">REQUESTED-BY-INFORMATION</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">17</td>
<td align="left">FLOOR-REQUEST-STATUS</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">18</td>
<td align="left">OVERALL-REQUEST-STATUS</td>
<td align="left">RFC 8855</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec_iana_primitive" numbered="true" toc="default">
<name>Primitives Subregistry</name>
<section title="Reception of a Subsequent FloorStatus Message" anchor="sec <t>This section establishes the "Primitives" subregistry under the
:recept:fsm"> BFCP Parameters registry. As per the terminology in RFC 8126 <xref
<t>When communicating over an unreliable transport and upon receiving a F target="RFC8126" format="default"/>, the registration policy for BFCP
loorStatus message from a floor control server, the participant MUST respond wit primitives is "Specification Required". For the purposes of this
h a FloorStatusAck message within the transaction failure window to complete the subregistry, the BFCP primitives for which IANA registration is
transaction.</t> requested <bcp14>MUST</bcp14> be defined by a Standards Track
RFC. Such an RFC <bcp14>MUST</bcp14> specify the primitive's value,
name, format, and semantics.</t>
<t>For each BFCP primitive, the IANA registers its value, its name, and
the reference to the RFC where the primitive is defined. The following table con
tains the initial values of this subregistry.</t>
<table anchor="tab_iana-primitives" align="center">
<name>Initial values of the BFCP Primitives subregistry</name>
<thead>
<tr>
<th align="center">Value</th>
<th align="left">Primitive</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">1</td>
<td align="left">FloorRequest</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left">FloorRelease</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">FloorRequestQuery</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">FloorRequestStatus</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left">UserQuery</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left">UserStatus</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left">FloorQuery</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">8</td>
<td align="left">FloorStatus</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">9</td>
<td align="left">ChairAction</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">10</td>
<td align="left">ChairActionAck</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">11</td>
<td align="left">Hello</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">12</td>
<td align="left">HelloAck</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">13</td>
<td align="left">Error</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">14</td>
<td align="left">FloorRequestStatusAck</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">15</td>
<td align="left">FloorStatusAck</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">16</td>
<td align="left">Goodbye</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">17</td>
<td align="left">GoodbyeAck</td>
<td align="left">RFC 8855</td>
</tr>
</tbody>
</table>
</section> </section>
</section> <section numbered="true" toc="default">
<name>Request Statuses Subregistry</name>
<section title="Requesting Information about Floor Requests" anchor="sec:cli <t>This section establishes the "Request Statuses" subregistry under the
ent:info"> BFCP Parameters registry. As per the terminology in RFC 8126 <xref
<t>A client can obtain information about the status of one or several floo target="RFC8126" format="default"/>, the registration policy for BFCP
r requests in different ways, which include using BFCP and using out-of-band mec request statuses is "Specification Required". For the purposes of
hanisms. Clients using BFCP to obtain such information use the procedures descri this subregistry, the BFCP request statuses for which IANA registration
bed in this section.</t> is requested <bcp14>MUST</bcp14> be defined by a Standards Track
<t>Clients request information about the current status of a floor request RFC. Such an RFC <bcp14>MUST</bcp14> specify the value and the
by sending a FloorRequestQuery message to the floor control server.</t> semantics of the request status.</t>
<t>Requesting information about a particular floor request is useful in a <t>For each BFCP request status, the IANA registers its value, its meani
number of situations. For example, on reception of a FloorRequest message, a flo ng, and the reference to the RFC where the request status is defined. The follow
or control server may choose to return FloorRequestStatus messages only when the ing table contains the initial values of this subregistry.</t>
floor request changes its state (e.g., from Accepted to Granted), but not when <table anchor="tab_iana-requeststatusvalues" align="center">
the floor request advances in its queue. In this situation, if the user requests <name>Initial values of the Request Statuses subregistry</name>
it, the floor participant can use a FloorRequestQuery message to poll the floor <thead>
control server for the status of the floor request.</t> <tr>
<th align="center">Value</th>
<section title="Sending a FloorRequestQuery Message" anchor="sec:client:in <th align="left">Status</th>
fo:send"> <th align="left">Reference</th>
<t>The ABNF in <xref target="sec:msg_format:FloorRequestQuery"/> describ </tr>
es the attributes that a FloorRequestQuery message can contain. In addition, the </thead>
ABNF specifies normatively which of these attributes are mandatory, and which o <tbody>
nes are optional.</t> <tr>
<t>The client sets the Conference ID and the Transaction ID in the commo <td align="center">1</td>
n header following the rules given in <xref target="sec:transactions:client"/>. <td align="left">Pending</td>
The client sets the User ID in the common header to the client's identifier.</t> <td align="left">RFC 8855</td>
<t>The client MUST insert a FLOOR-REQUEST-ID attribute that identifies t </tr>
he floor request at the floor control server.</t> <tr>
<td align="center">2</td>
<td align="left">Accepted</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">Granted</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">Denied</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left">Cancelled</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left">Released</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left">Revoked</td>
<td align="left">RFC 8855</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec_iana_errorcode" numbered="true" toc="default">
<name>Error Codes Subregistry</name>
<section title="Receiving a Response" anchor="sec:client:info:response"> <t>This section establishes the "Error Codes" subregistry under the BFCP
<t>A message from the floor control server is considered a response to t Parameters registry. As per the terminology in RFC 8126 <xref
he FloorRequestQuery message if the message from the floor control server has th target="RFC8126" format="default"/>, the registration policy for BFCP
e same Conference ID, Transaction ID, and User ID as the FloorRequestQuery messa error codes is "Specification Required". For the purposes of
ge, as described in <xref target="sec:transactions:client"/>. On receiving such this subregistry, the BFCP error codes for which IANA registration is
a response, the client follows the rules in <xref target="sec:auth"/> that rela requested <bcp14>MUST</bcp14> be defined by a Standards Track
te to floor control server authentication.</t> RFC. Such an RFC <bcp14>MUST</bcp14> specify the value and the
<t>If the response is a FloorRequestStatus message, the client obtains i semantics of the error code, and any Error Specific Details that apply
nformation about the status of the FloorRequest the client requested information to it.</t>
about in a FLOOR-REQUEST-INFORMATION attribute.</t> <t>For each BFCP primitive, the IANA registers its value, its meaning, a
<t>If the response is an Error message, the floor control server could n nd the reference to the RFC where the primitive is defined. The following table
ot process the FloorRequestQuery message for some reason, which is described in contains the initial values of this subregistry.</t>
the Error message.</t> <!-- [rfced] Is the goal to use title capitalization for these error codes?
</section> May we update the meanings in the table and throughout for consistency? For
</section> exapmle, we note that the "Unable to parse message" (value 10 below) is also
referenced as "Unable to Parse Message" in the text.
<section title="Requesting Information about a User" anchor="sec:client:user current -> proposed
"> Conference does not Exist -> Conference Does Not Exist
<t>A client can obtain information about a participant and the floor reque
sts related to this participant in different ways, which include using BFCP and
using out-of-band mechanisms. Clients using BFCP to obtain such information use
the procedures described in this section.</t>
<t>Clients request information about a participant and the floor requests
related to this participant by sending a UserQuery message to the floor control
server.</t>
<t>This functionality may be useful for floor chairs or floor participants
interested in the display name and the URI of a particular floor participant. I
n addition, a floor participant may find it useful to request information about
itself. For example, a floor participant, after experiencing connectivity proble
ms (e.g., its TCP connection with the floor control server was down for a while
and eventually was re-established), may need to request information about all th
e floor requests associated to itself that still exist.</t>
<section title="Sending a UserQuery Message" anchor="sec:client:user:send" User does not Exist -> User Does Not Exist
>
<t>The ABNF in <xref target="sec:msg_format:UserQuery"/> describes the a
ttributes that a UserQuery message can contain. In addition, the ABNF specifies
normatively which of these attributes are mandatory, and which ones are optional
.</t>
<t>The client sets the Conference ID and the Transaction ID in the commo
n header following the rules given in <xref target="sec:transactions:client"/>.
The client sets the User ID in the common header to the client's identifier.</t>
<t>If the floor participant the client is requesting information about i
s not the client issuing the UserQuery message (which is identified by the User
ID in the common header of the message), the client MUST insert a BENEFICIARY-ID
attribute.</t>
</section>
<section title="Receiving a Response" anchor="sec:client:user:response"> You have Already Reached the Maximum Number of Ongoing Floor Requests for this
<t>A message from the floor control server is considered a response to t Floor -> You Have Already Reached the Maximum Number of Ongoing Floor Requests
he UserQuery message if the message from the floor control server has the same C for This Floor
onference ID, Transaction ID, and User ID as the UserQuery message, as described
in <xref target="sec:transactions:client"/>. On receiving such a response, the
client follows the rules in <xref target="sec:auth"/> that relate to floor cont
rol server authentication.</t>
<t>If the response is a UserStatus message, the client obtains informati
on about the floor participant in a BENEFICIARY-INFORMATION grouped attribute an
d about the status of the floor requests associated with the floor participant i
n FLOOR-REQUEST-INFORMATION attributes.</t>
<t>If the response is an Error message, the floor control server could n
ot process the UserQuery message for some reason, which is described in the Erro
r message.</t>
</section>
</section>
<section title="Obtaining the Capabilities of a Floor Control Server" anchor Unable to parse message -> Unable to Parse Message
="sec:client:hello">
<t>A client that wishes to obtain the capabilities of a floor control serv
er does so by sending a Hello message to the floor control server.</t>
<section title="Sending a Hello Message" anchor="sec:client:hello:send"> If any changes are made, we will ask IANA to update the registry accordingly.
<t>The ABNF in <xref target="sec:msg_format:Hello"/> describes the attri -->
butes that a Hello message can contain. In addition, the ABNF specifies normativ
ely which of these attributes are mandatory, and which ones are optional.</t>
<t>The client sets the Conference ID and the Transaction ID in the commo
n header following the rules given in <xref target="sec:transactions:client"/>.
The client sets the User ID in the common header to the client's identifier.</t>
</section>
<section title="Receiving Responses" anchor="sec:client:hello:responses"> <table anchor="tab_iana-errorcode" align="center">
<t>A message from the floor control server is considered a response to t <name>Initial values of the Error Codes subregistry</name>
he Hello message by the client if the message from the floor control server has <thead>
the same Conference ID, Transaction ID, and User ID as the Hello message, as des <tr>
cribed in <xref target="sec:transactions:client"/>. On receiving such a response <th align="center">Value</th>
, the client follows the rules in <xref target="sec:auth"/> that relate to floor <th align="left">Meaning</th>
control server authentication.</t> <th align="left">Reference</th>
<t>If the response is a HelloAck message, the floor control server could </tr>
process the Hello message successfully. The SUPPORTED-PRIMITIVES and SUPPORTED- </thead>
ATTRIBUTES attributes indicate which primitives and attributes, respectively, ar <tbody>
e supported by the server.</t> <tr>
<t>If the response is an Error message, the floor control server could n <td align="center">1</td>
ot process the Hello message for some reason, which is described in the Error me <td align="left">Conference Does Not Exist</td>
ssage.</t> <td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">2</td>
<td align="left">User Does Not Exist</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">3</td>
<td align="left">Unknown Primitive</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">4</td>
<td align="left">Unknown Mandatory Attribute</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">5</td>
<td align="left">Unauthorized Operation</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">6</td>
<td align="left">Invalid Floor ID</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">7</td>
<td align="left">Floor Request ID Does Not Exist</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">8</td>
<td align="left">You have Already Reached the Maximum Number
of Ongoing Floor Requests for This Floor</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">9</td>
<td align="left">Use TLS</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">10</td>
<td align="left">Unable to Parse Message</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">11</td>
<td align="left">Use DTLS</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">12</td>
<td align="left">Unsupported Version</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">13</td>
<td align="left">Incorrect Message Length</td>
<td align="left">RFC 8855</td>
</tr>
<tr>
<td align="center">14</td>
<td align="left">Generic Error</td>
<td align="left">RFC 8855</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
</section> <section anchor="sec_changes" numbered="true" toc="default">
<name>Changes from RFC 4582</name>
<section title="Floor Control Server Operations" anchor="sec:server"> <t>The following is the list of technical changes and other non-trivial fi
<t>This section specifies how floor control servers can perform different op xes from <xref target="RFC4582" format="default"/>.</t>
erations, such as granting a floor, using the protocol elements described in ear <section numbered="true" toc="default">
lier sections.</t> <name>Extensions for an Unreliable Transport</name>
<t>On reception of a message from a client, the floor control server MUST ch <t>The main purpose of this work was to revise the specification to supp
eck whether the value of the Primitive is supported. If it is not, the floor co ort BFCP over an unreliable transport, resulting in the following changes:</t>
ntrol server MUST send an Error message, as described in <xref target="sec:serve <ol spacing="normal" type="1">
r:error"/>, with Error code 3 (Unknown Primitive).</t> <li>
<t>On reception of a message from a client, the floor control server MUST ch <t>Overview of Operation (<xref target="sec_overview" format="defaul
eck whether the value of the Conference ID matched an existing conference. If it t"/>):</t>
does not, the floor control server MUST send an Error message, as described in <t>
<xref target="sec:server:error"/>, with Error code 1 (Conference does not Exist) Changed the description of client-initiated and server-initiated tra
.</t> nsactions, referring to <xref target="sec_transactions" format="default"/>.</t>
<t>On reception of a message from a client, the floor control server follows </li>
the rules in <xref target="sec:auth"/> that relate to the authentication of the <li>
message.</t> <t>COMMON-HEADER Format (<xref target="sec_format_common" format="de
<t>On reception of a message from a client, the floor control server MUST ch fault"/>):</t>
eck whether it understands all the mandatory ('M' bit set) attributes in the mes <t>
sage. If the floor control server does not understand all of them, the floor con Ver(sion) field, where the value 2 is used for the extensions for an
trol server MUST send an Error message, as described in <xref target="sec:server unreliable transport. Added new R and F flag bits for an unreliable transport.
:error"/>, with Error code 4 (Unknown Mandatory Attribute). The Error message SH Res(erved) field is now 3 bit. New optional Fragment Offset and Fragment Length
OULD list the attributes that were not understood.</t> fields.</t>
</li>
<section title="Reception of a FloorRequest Message" anchor="sec:server:requ <li>
est"> <t>New primitives (<xref target="sec_format_common" format="default"
<t>On reception of a FloorRequest message, the floor control server follow />):</t>
s the rules in <xref target="sec:auth"/> that relate to client authentication an <t>
d authorization. If while processing the FloorRequest message, the floor control Added four new primitives: FloorRequestStatusAck, FloorStatusAck, Go
server encounters an error, it MUST generate an Error response following the pr odbye, and GoodbyeAck.</t>
ocedures described in <xref target="sec:server:error"/>.</t> </li>
<t><list style="hanging"> <li>
<t>BFCP allows floor participants to have several ongoing floor reques <t>New error codes (<xref target="sec_format_attributes_error-code"
ts for the same floor (e.g., the same floor participant can occupy more than one format="default"/>):</t>
position in a queue at the same time). A floor control server that only support
s a certain number of ongoing floor requests per floor participant (e.g., one) c
an use Error Code 8 (You have Already Reached the Maximum Number of Ongoing Floo
r Requests for this Floor) to inform the floor participant.</t>
</list></t>
<t>When communicating over an unreliable transport and upon receiving a Fl
oorRequest from a participant, the floor control server MUST respond with a Floo
rRequestStatus message within the transaction failure window to complete the tra
nsaction.</t>
<section title="Generating the First FloorRequestStatus Message" anchor="s <t>
ec:server:request:first"> Added three new error codes: "Unable to Parse Message", "Use DTLS" a
<t>The successful processing of a FloorRequest message by a floor contro nd "Unsupported Version". Note that two additional error codes were added, see <
l server involves generating one or several FloorRequestStatus messages, the fir xref target="sec_changes_other" format="default"/>.</t>
st of which SHOULD be generated as soon as possible. If the floor control server </li>
cannot accept, grant, or deny the floor request right away (e.g., a decision fr <li>
om a chair is needed), it SHOULD use a Request Status value of Pending in the OV <t>ABNF for new primitives (<xref target="sec_msg_format" format="de
ERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped att fault"/>):</t>
ribute) of the first FloorRequestStatus message it generates.</t> <t>
<t><list style="hanging"> Added new subsections with normative ABNF for the new primitives.</t
<t>The policy that a floor control server follows to grant or deny f >
loors is outside the scope of this document. A given floor control server may pe </li>
rform these decisions automatically while another may contact a human acting as <li>
a chair every time a decision needs to be made.</t> <t>Transport split in two (<xref target="sec_transport" format="defa
</list></t> ult"/>):</t>
<t>The floor control server MUST copy the Conference ID, the Transaction <t><xref target="sec_transport" format="default"/> specifying the tr
ID, and the User ID from the FloorRequest into the FloorRequestStatus, as descr ansport was split in two subsections; <xref target="tcp_transport" format="defau
ibed in <xref target="sec:transactions:server"/>. Additionally, the floor contro lt"/> for a reliable transport and <xref target="udp_transport" format="default"
l server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequ /> for an unreliable transport. The specification for an unreliable transport, a
estStatus. The attributes contained in this grouped attribute carry information mong other issues, deals with reliability, congestion control, fragmentation and
about the floor request.</t> ICMP.</t>
<t>The floor control server MUST assign an identifier that is unique wit </li>
hin the conference to this floor request, and MUST insert it in the Floor Reques <li>
t ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be u <t>Mandated DTLS (<xref target="sec_lower-security" format="default"
sed by the floor participant (or by a chair or chairs) to refer to this specific /> and <xref target="sec_auth" format="default"/>):</t>
floor request in the future.</t> <t>
<t>The floor control server MUST copy the Floor IDs in the FLOOR-ID attr Mandated DTLS support when transport over UDP is used.</t>
ibutes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR </li>
-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors bein <li>
g requested (i.e., the floors associated with this particular floor request).</t <t>Transaction changes (<xref target="sec_transactions" format="defa
> ult"/>):</t>
<t>The floor control server SHOULD copy (if present) the contents of the <t>
BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-INFORMATION a Server-initiated transactions over an unreliable transport have non-
ttribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, t zero and unique Transaction IDs. Over an unreliable transport, the retransmit ti
he floor control server MAY provide the display name and the URI of the benefici mers T1 and T2 described in <xref target="timers" format="default"/> apply.</t>
ary in this BENEFICIARY-INFORMATION attribute.</t> </li>
<t>The floor control server MAY provide information about the requester <li>
of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-IN <t>Timely response required (<xref target="timers" format="default"/
FORMATION grouped attribute.</t> >, <xref target="sec_client_request_response" format="default"/>, <xref target="
<t>The floor control server MAY copy (if present) the PRIORITY attribute sec_participant_cancel_response" format="default"/>, <xref target="sec_chair_ins
from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.</t> truct_response" format="default"/>, <xref target="sec_client_floorinfo_response"
<!-- note: assumed bug in RFC 4582. s/PARTICIPANT-PROVIDED-INFO attr/PRIORITY a format="default"/>, <xref target="sec_client_info_response" format="default"/>,
ttr/ --> <xref target="sec_client_user_response" format="default"/>, <xref target="sec_c
<t><list style="empty"> lient_hello_responses" format="default"/>, <xref target="sec_recept_frsm" format
<t>Note that this attribute carries the priority requested by the ="default"/> and <xref target="sec_recept_fsm" format="default"/>):</t>
participant. The priority that the floor control server assigns to the floor req <t>
uest depends on the priority requested by the participant and the rights the par Described that a given response must be sent within the transaction
ticipant has according to the policy of the conference. For example, a participa failure window to complete the transaction.</t>
nt that is only allowed to use the Normal priority may request Highest priority </li>
for a floor request. In that case, the floor control server would ignore the pri <li>
ority requested by the participant.</t> <t>Updated IANA Considerations (<xref target="sec_iana" format="defa
</list></t> ult"/>):</t>
<t>The floor control server MAY copy (if present) the PARTICIPANT-PROVID <t>
ED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION group Added the new primitives and error codes to <xref target="sec_iana_p
ed attribute.</t> rimitive" format="default"/> and <xref target="sec_iana_errorcode" format="defau
lt"/> respectively.</t>
</li>
<li>
<t>Examples over an unreliable transport (<xref target="app_unrelcal
lflow" format="default"/>):</t>
<t>
Added sample interactions over an unreliable transport for the scena
rios in <xref target="fig_flow1" format="default"/> and <xref target="fig_flow2"
format="default"/> </t>
</li>
<li>
<t>Motivation for an unreliable transport (<xref target="app_motivat
ion" format="default"/>):</t>
<t>
Added introduction to and motivation for extending BFCP to support a
n unreliable transport.</t>
</li>
</ol>
</section> </section>
<section anchor="sec_changes_other" numbered="true" toc="default">
<section title="Generation of Subsequent FloorRequestStatus Messages" anch <name>Other Changes</name>
or="sec:server:request:subsequent"> <t>Clarifications and bug fixes:</t>
<t>A floor request is considered to be ongoing as long as it is not in t <ol spacing="normal" type="1">
he Cancelled, Released, or Revoked states. If the OVERALL-REQUEST-STATUS attribu <li>
te (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRe <t>ABNF fixes (<xref target="fig_ben-information" format="default"/>
questStatus message generated by the floor control server did not indicate any o , <xref target="fig_floor-request-information" format="default"/>, <xref target=
f these states, the floor control server will need to send subsequent FloorReque "fig_reqby-information" format="default"/>, <xref target="fig_floor-req-status"
stStatus messages.</t> format="default"/>, <xref target="fig_overall-req-status" format="default"/>, an
<t>When the status of the floor request changes, the floor control serve d the ABNF figures in <xref target="sec_msg_format" format="default"/>):</t>
r SHOULD send new FloorRequestStatus messages with the appropriate Request Statu <t>
s. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with Although formally correct in <xref target="RFC4582" format="default"/
a Floor Request ID equal to the one sent in the first FloorRequestStatus message >, the notation has changed in a number of figures to an equivalent form for cla
to any new FloorRequestStatus related to the same floor request. (The Floor Req rity, e.g., <tt>s/*1(FLOOR-ID)/[FLOOR-ID]/</tt> in <xref target="fig_floorstatus
uest ID identifies the floor request to which the FloorRequestStatus applies.)</ " format="default"/> and <tt>s/*[XXX]/*(XXX)/</tt> in the other figures.</t>
t> </li>
<t>When using BFCP over a reliable transport, the floor control server M <li>
UST set the Transaction ID of subsequent FloorRequestStatus messages to 0. When <t>Typo (<xref target="sec_client_hello_responses" format="default"/
using BFCP over an unreliable transport, the Transaction ID MUST be non-zero and >):</t>
unique in the context of outstanding transactions over an unreliable transport <t>
as described in <xref target="sec:transactions"/>.</t> Changed from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the secon
<t><list style="hanging"> d paragraph.</t>
<t>The rate at which the floor control server sends FloorRequestStat </li>
us messages is a matter of local policy. A floor control server may choose to se <li>
nd a new FloorRequestStatus message every time the floor request moves in the fl <t>Corrected attribute type (<xref target="sec_server_request_first"
oor request queue, while another may choose only to send a new FloorRequestStatu format="default"/>):</t>
s message when the floor request is Granted or Denied.</t> <t>
</list></t> Changed from PARTICIPANT-PROVIDED-INFO to PRIORITY attribute in the ei
<t>The floor control server may add a STATUS-INFO attribute to any of th ghth paragraph, since the note below describes priority and that the last paragr
e FloorRequestStatus messages it generates to provide extra information about it aph deals with PARTICIPANT-PROVIDED-INFO.</t>
s decisions regarding the floor request (e.g., why it was denied).</t> </li>
<t><list style="hanging"> <li>
<t>Floor participants and floor chairs may request to be informed ab <t>New error codes (<xref target="sec_format_attributes_error-code"
out the status of a floor following the procedures in <xref target="sec:client:f format="default"/>):</t>
loorinfo"/>. If the processing of a floor request changes the status of a floor <t>
(e.g., the floor request is granted and consequently the floor has a new holder) Added two additional error codes: "Incorrect Message Length" and "Gene
, the floor control server needs to follow the procedures in <xref target="sec:s ric Error".</t>
erver:floorinfo"/> to inform the clients that have requested that information.</ </li>
t> <li>
</list></t> <t>New cipher suites (<xref target="sec_lower-security" format="def
<t>The common header and the rest of the attributes are the same as in t ault"/>)</t>
he first FloorRequestStatus message.</t> <t>Additional cipher suites are now specified which should be suppo
<t>The floor control server can discard the state information about a pa rted.</t>
rticular floor request when this reaches a status of Cancelled, Released, or Rev </li>
oked.</t> <li>
<t>When communicating over an unreliable transport and a FloorRequestSta <t>Assorted clarifications (Across the document):</t>
tusAck message is not received within the transaction failure window, the floor <t>
control server MUST retransmit the FloorRequestStatus message according to <xref Language clarifications as a result of reviews. Also, the normative la
target="udp_transport"/>.</t> nguage was tightened where appropriate, i.e. changed from <bcp14>SHOULD</bcp14>
strength to <bcp14>MUST</bcp14> in a number of places.</t>
</li>
</ol>
</section> </section>
</section> </section>
<!-- [rfced] The following terms, which are carried over from
RFC 4582, are inconsistently capitalized:
<section title="Reception of a FloorRequestQuery Message" anchor="sec:server o Error Code/Error code - Perhaps it can be capitalized
:requestinfo"> when referring to a specific code (Error Code 8), and
<t>On reception of a FloorRequestQuery message, the floor control server f lowercase otherwise.
ollows the rules in <xref target="sec:auth"/> that relate to client authenticati
on and authorization. If while processing the FloorRequestQuery message, the flo
or control server encounters an error, it MUST generate an Error response follow
ing the procedures described in <xref target="sec:server:error"/>.</t>
<t>The successful processing of a FloorRequestQuery message by a floor con
trol server involves generating a FloorRequestStatus message, which SHOULD be ge
nerated as soon as possible.</t>
<t>When communicating over an unreliable transport and upon receiving a Fl
oorRequestQuery from a participant, the floor control server MUST respond with a
FloorRequestStatus message within the transaction failure window to complete th
e transaction.</t>
<t>The floor control server MUST copy the Conference ID, the Transaction I
D, and the User ID from the FloorRequestQuery message into the FloorRequestStatu
s message, as described in <xref target="sec:transactions:server"/>. Additionall
y, the floor control server MUST include information about the floor request in
the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus.</t>
<t>The floor control server MUST copy the contents of the FLOOR-REQUEST-ID
attribute from the FloorRequestQuery message into the Floor Request ID field of
the FLOOR-REQUEST-INFORMATION attribute.</t>
<t>The floor control server MUST add FLOOR-REQUEST-STATUS attributes to th
e FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being reque
sted (i.e., the floors associated with the floor request identified by the FLOOR
-REQUEST-ID attribute).</t>
<t>The floor control server SHOULD add a BENEFICIARY-ID attribute to the F
LOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the fl
oor request. Additionally, the floor control server MAY provide the display nam
e and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t>
<t>The floor control server MAY provide information about the requester of
the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFO
RMATION grouped attribute.</t>
<t>The floor control server MAY provide the reason why the floor participa
nt requested the floor in a PARTICIPANT-PROVIDED-INFO.</t>
<t>The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION
grouped attribute a PRIORITY attribute with the Priority value requested for the
floor request and a STATUS-INFO attribute with extra information about the floo
r request.</t>
<t>The floor control server MUST add an OVERALL-REQUEST-STATUS attribute t
o the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the
floor request. The floor control server MAY provide information about the statu
s of the floor request as it relates to each of the floors being requested in th
e FLOOR-REQUEST-STATUS attributes.</t>
</section>
<section title="Reception of a UserQuery Message" anchor="sec:server:userinf o Priority value/priority value - Which way do you prefer
o"> for it to be capitalized?
<t>On reception of a UserQuery message, the floor control server follows t
he rules in <xref target="sec:auth"/> that relate to client authentication and a
uthorization. If while processing the UserQuery message, the floor control serve
r encounters an error, it MUST generate an Error response following the procedur
es described in <xref target="sec:server:error"/>.</t>
<t>The successful processing of a UserQuery message by a floor control ser
ver involves generating a UserStatus message, which SHOULD be generated as soon
as possible.</t>
<t>When communicating over an unreliable transport and upon receiving a Us
erQuery from a participant, the floor control server MUST respond with a UserSta
tus message within the transaction failure window to complete the transaction.</
t>
<t>The floor control server MUST copy the Conference ID, the Transaction I
D, and the User ID from the UserQuery message into the UserStatus message, as de
scribed in <xref target="sec:transactions:server"/>.</t>
<t>The sender of the UserQuery message is requesting information about all
the floor requests associated with a given participant (i.e., the floor request
s where the participant is either the beneficiary or the requester). This partic
ipant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFI
CIARY-ID attribute, by a the User ID in the common header of the UserQuery messa
ge.</t>
<t>The floor control server MUST copy, if present, the contents of the BEN
EFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION
attribute in the UserStatus message. Additionally, the floor control server MAY
provide the display name and the URI of the participant about which the UserStat
us message provides information in this BENEFICIARY-INFORMATION attribute.</t>
<t>The floor control server SHOULD add to the UserStatus message a FLOOR-R
EQUEST-INFORMATION grouped attribute for each floor request related to the parti
cipant about which the message provides information (i.e., the floor requests wh
ere the participant is either the beneficiary or the requester). For each FLOOR-
REQUEST-INFORMATION attribute, the floor control server follows the following st
eps.</t>
<t>The floor control server MUST identify the floor request the FLOOR-REQU
EST-INFORMATION attribute applies to by filling the Floor Request ID field of th
e FLOOR-REQUEST-INFORMATION attribute.</t>
<t>The floor control server MUST add FLOOR-REQUEST-STATUS attributes to th
e FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being reque
sted (i.e., the floors associated with the floor request identified by the FLOOR
-REQUEST-ID attribute).</t>
<t>The floor control server SHOULD add a BENEFICIARY-ID attribute to the F
LOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the fl
oor request. Additionally, the floor control server MAY provide the display nam
e and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t>
<t>The floor control server MAY provide information about the requester of
the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFO
RMATION grouped attribute.</t>
<t>The floor control server MAY provide the reason why the floor participa
nt requested the floor in a PARTICIPANT-PROVIDED-INFO.</t>
<t>The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION
grouped attribute a PRIORITY attribute with the Priority value requested for the
floor request.</t>
<t>The floor control server MUST include the current status of the floor r
equest in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION g
rouped attribute. The floor control server MAY add a STATUS-INFO attribute with
extra information about the floor request.</t>
<t>The floor control server MAY provide information about the status of th
e floor request as it relates to each of the floors being requested in the FLOOR
-REQUEST-STATUS attributes.</t>
</section>
<section title="Reception of a FloorRelease Message" anchor="sec:server:rele o COMMON-HEADER/common header - In RFC 4582 text, COMMON-HEADER
ase"> is used in the ABNF, but when discussing fields within it,
<t>On reception of a FloorRelease message, the floor control server follow the term common header is used. In the newer text,
s the rules in <xref target="sec:auth"/> that relate to client authentication an COMMON-HEADER is used when discussing fields within it.
d authorization. If while processing the FloorRelease message, the floor control Please let us know if any changes are required.
server encounters an error, it MUST generate an Error response following the pr
ocedures described in <xref target="sec:server:error"/>.</t>
<t>The successful processing of a FloorRelease message by a floor control
server involves generating a FloorRequestStatus message, which SHOULD be generat
ed as soon as possible.</t>
<t>When communicating over an unreliable transport and upon receiving a Fl
oorRelease from a participant, the floor control server MUST respond with a Floo
rRequestStatus message within the transaction failure window to complete the tra
nsaction.</t>
<t>The floor control server MUST copy the Conference ID, the Transaction I
D, and the User ID from the FloorRelease message into the FloorRequestStatus mes
sage, as described in <xref target="sec:transactions:server"/>.</t>
<t>The floor control server MUST add a FLOOR-REQUEST-INFORMATION grouped a
ttribute to the FloorRequestStatus. The attributes contained in this grouped att
ribute carry information about the floor request.</t>
<t>The FloorRelease message identifies the floor request it applies to usi
ng a FLOOR-REQUEST-ID. The floor control server MUST copy the contents of the FL
OOR-REQUEST-ID attribute from the FloorRelease message into the Floor Request ID
field of the FLOOR-REQUEST-INFORMATION attribute.</t>
<t>The floor control server MUST identify the floors being released (i.e.,
the floors associated with the floor request identified by the FLOOR-REQUEST-ID
attribute) in FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION
grouped attribute.</t>
<t>The floor control server MUST add an OVERALL-REQUEST-STATUS attribute t
o the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status value SHO
ULD be Released, if the floor (or floors) had been previously granted, or Cancel
led, if the floor (or floors) had not been previously granted. The floor contro
l server MAY add a STATUS-INFO attribute with extra information about the floor
request.</t>
</section>
<section title="Reception of a FloorQuery Message" anchor="sec:server:floori The term Error Specific Details is hyphenated
nfo"> inconsistently (this is also a carryover from RFC 4582).
<t>On reception of a FloorQuery message, the floor control server follows Do you prefer "Error Specific Details" or
the rules in <xref target="sec:auth"/> that relate to client authentication. If "Error-Specific Details"?
while processing the FloorQuery message, the floor control server encounters an -->
error, it MUST generate an Error response following the procedures described in </middle>
<xref target="sec:server:error"/>.</t> <back>
<t>When communicating over an unreliable transport and upon receiving a Fl
oorQuery from a participant, the floor control server MUST respond with a FloorS
tatus message within the transaction failure window to complete the transaction.
</t>
<t>A floor control server receiving a FloorQuery message from a client SHO
ULD keep this client informed about the status of the floors identified by FLOOR
-ID attributes in the FloorQuery message. Floor Control Servers keep clients inf
ormed by using FloorStatus messages.</t>
<t>An individual FloorStatus message carries information about a single fl
oor. So, when a FloorQuery message requests information about more than one floo
r, the floor control server needs to send separate FloorStatus messages for diff
erent floors.</t>
<t>The information FloorQuery messages carry may depend on the user reques
ting the information. For example, a chair may be able to receive information ab
out pending requests, while a regular user may not be authorized to do so.</t>
<section title="Generation of the First FloorStatus Message" anchor="sec:s <references>
erver:floorinfo:first"> <name>References</name>
<t>The successful processing of a FloorQuery message by a floor control <references>
server involves generating one or several FloorStatus messages, the first of whi <name>Normative References</name>
ch SHOULD be generated as soon as possible.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>The floor control server MUST copy the Conference ID, the Transaction FC.2119.xml"/>
ID, and the User ID from the FloorQuery message into the FloorStatus message, a <!-- RFC 2988 obsoleted by RFC 6298 -->
s described in <xref target="sec:transactions:server"/>.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>If the FloorQuery message did not contain any FLOOR-ID attribute, the FC.6298.xml"/>
floor control server sends the FloorStatus message without adding any additiona <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
l attribute and does not send any subsequent FloorStatus message to the floor pa FC.4582.xml"/>
rticipant.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>If the FloorQuery message contained one or more FLOOR-ID attributes, FC.5018.xml"/>
the floor control server chooses one from among them and adds this FLOOR-ID attr <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ibute to the FloorStatus message. The floor control server SHOULD add a FLOOR-RE FC.5234.xml"/>
QUEST-INFORMATION grouped attribute for each floor request associated to the flo <!-- RFC 5226 obsoleted by RFC 8126 -->
or. Each FLOOR-REQUEST-INFORMATION grouped attribute contains a number of attrib <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
utes that provide information about the floor request. For each FLOOR-REQUEST-IN FC.8126.xml"/>
FORMATION attribute, the floor control server follows the following steps.</t> <!-- Reference to RFC 5246 kept for backward compatibility -->
<t>The floor control server MUST identify the floor request the FLOOR-RE <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
QUEST-INFORMATION attribute applies to by filling the Floor Request ID field of FC.5246.xml"/>
the FLOOR-REQUEST-INFORMATION attribute.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>The floor control server MUST add FLOOR-REQUEST-STATUS attributes to FC.6347.xml"/>
the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being req <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
uested (i.e., the floors associated with the floor request identified by the FLO FC.3629.xml"/>
OR-REQUEST-ID attribute).</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>The floor control server SHOULD add a BENEFICIARY-ID attribute to the FC.8174.xml"/>
FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the <!-- RFC 5246 obsoleted by RFC 8446 -->
floor request. Additionally, the floor control server MAY provide the display n <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ame and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t FC.8446.xml"/>
>
<t>The floor control server MAY provide information about the requester
of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-IN
FORMATION grouped attribute.</t>
<t>The floor control server MAY provide the reason why the floor partici
pant requested the floor in a PARTICIPANT-PROVIDED-INFO.</t>
<t>The floor control server MAY also add to the FLOOR-REQUEST-INFORMATIO
N grouped attribute a PRIORITY attribute with the Priority value requested for t
he floor request.</t>
<t>The floor control server MUST add an OVERALL-REQUEST-STATUS attribute
to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of t
he floor request. The floor control server MAY add a STATUS-INFO attribute with
extra information about the floor request.</t>
<t>The floor control server MAY provide information about the status of
the floor request as it relates to each of the floors being requested in the FLO
OR-REQUEST-STATUS attributes.</t>
</section>
<section title="Generation of Subsequent FloorStatus Messages" anchor="sec <!-- draft-ietf-bfcpbis-rfc4583bis; in EDIT*R state as of 1/6/20; companion docu
:server:floorinfo:subsequent"> ment RFC 8856 -->
<t>If the FloorQuery message carried more than one FLOOR-ID attribute, t
he floor control server SHOULD generate a FloorStatus message for each of them (
except for the FLOOR-ID attribute chosen for the first FloorStatus message) as s
oon as possible. These FloorStatus messages are generated following the same rul
es as those for the first FloorStatus message (see <xref target="sec:server:floo
rinfo:first"/>), but their Transaction ID is 0 when using a reliable transport a
nd non-zero and unique in the context of outstanding transactions when using an
unreliable transport (cf. <xref target="sec:transactions"/>).</t>
<t>After generating these messages, the floor control server sends Floor
Status messages, periodically keeping the client informed about all the floors f
or which the client requested information. The Transaction ID of these messages
MUST be 0 when using a reliable transport and non-zero and unique in the context
of outstanding transactions when using an unreliable transport (cf. <xref targe
t="sec:transactions"/>).</t>
<t><list style="hanging">
<t>The rate at which the floor control server sends FloorStatus mess
ages is a matter of local policy. A floor control server may choose to send a ne
w FloorStatus message every time a new floor request arrives, while another may
choose to only send a new FloorStatus message when a new floor request is Grante
d.</t>
</list></t>
<t>When communicating over an unreliable transport and a FloorStatusAck
message is not received within the transaction failure window, the floor control
server MUST retransmit the FloorStatus message according to <xref target="udp_t
ransport"/>.</t>
</section>
</section>
<section title="Reception of a ChairAction Message" anchor="sec:server:chair <reference anchor='RFC8856' target="https://www.rfc-editor.org/info/rfc8856">
action"> <front>
<t>On reception of a ChairAction message, the floor control server follows <title>Session Description Protocol (SDP) Format for Binary Floor Control Protoc
the rules in <xref target="sec:auth"/> that relate to client authentication and ol (BFCP) Streams</title>
authorization. If while processing the ChairAction message, the floor control s
erver encounters an error, it MUST generate an Error response following the proc
edures described in <xref target="sec:server:error"/>.</t>
<t>The successful processing of a ChairAction message by a floor control s
erver involves generating a ChairActionAck message, which SHOULD be generated as
soon as possible.</t>
<t>When communicating over an unreliable transport and upon receiving a Ch
airAction from a chair, the floor control server MUST respond with a ChairAction
Ack message within the transaction failure window to complete the transaction.</
t>
<t>The floor control server MUST copy the Conference ID, the Transaction I
D, and the User ID from the ChairAction message into the ChairActionAck message,
as described in <xref target="sec:transactions:server"/>.</t>
<t>The floor control server needs to take into consideration the operation
requested in the ChairAction message (e.g., granting a floor) but does not nece
ssarily need to perform it as requested by the floor chair. The operation that t
he floor control server performs depends on the ChairAction message and on the i
nternal state of the floor control server.</t>
<t>For example, a floor chair may send a ChairAction message granting a fl
oor that was requested as part of an atomic floor request operation that involve
d several floors. Even if the chair responsible for one of the floors instructs
the floor control server to grant the floor, the floor control server will not g
rant it until the chairs responsible for the other floors agree to grant them as
well.</t>
<t>So, the floor control server is ultimately responsible for keeping a co
herent floor state using instructions from floor chairs as input to this state.<
/t>
<t>If the new Status in the ChairAction message is Accepted and all the bi
ts of the Queue Position field are zero, the floor chair is requesting that the
floor control server assign a queue position (e.g., the last in the queue) to th
e floor request based on the local policy of the floor control server. (Of cours
e, such a request only applies if the floor control server implements a queue.)<
/t>
</section>
<section title="Reception of a Hello Message" anchor="sec:server:helloack"> <author initials='G' surname='Camarillo' fullname='Gonzalo Camarillo'>
<t>On reception of a Hello message, the floor control server follows the r <organization />
ules in <xref target="sec:auth"/> that relate to client authentication. If while </author>
processing the Hello message, the floor control server encounters an error, it
MUST generate an Error response following the procedures described in <xref targ
et="sec:server:error"/>.</t>
<t>If the version of BFCP specified in the Version field of the COMMON-HEA
DER is supported by the floor control server, it MUST respond with the same vers
ion number in the HelloAck; this defines the version for all subsequent BFCP mes
sages within this BFCP Connection.</t>
<t>When communicating over an unreliable transport and upon receiving a He
llo from a participant, the floor control server MUST respond with a HelloAck me
ssage within the transaction failure window to complete the transaction.</t>
<t>The successful processing of a Hello message by a floor control server
involves generating a HelloAck message, which SHOULD be generated as soon as pos
sible. The floor control server MUST copy the Conference ID, the Transaction ID,
and the User ID from the Hello into the HelloAck, as described in <xref target=
"sec:transactions:server"/>.</t>
<t>The floor control server MUST add a SUPPORTED-PRIMITIVES attribute to t
he HelloAck message listing all the primitives (i.e., BFCP messages) supported b
y the floor control server.</t>
<t>The floor control server MUST add a SUPPORTED-ATTRIBUTES attribute to t
he HelloAck message listing all the attributes supported by the floor control se
rver.</t>
</section>
<section title="Error Message Generation" anchor="sec:server:error"> <author initials='T' surname='Kristensen' fullname='Tom Kristensen'>
<t>Error messages are always sent in response to a previous message from t <organization />
he client as part of a client-initiated transaction. The ABNF in <xref target="s </author>
ec:msg_format:Error"/> describes the attributes that an Error message can contai
n. In addition, the ABNF specifies normatively which of these attributes are man
datory and which ones are optional.</t>
<t>The floor control server MUST copy the Conference ID, the Transaction I
D, and the User ID from the message from the client into the Error message, as d
escribed in <xref target="sec:transactions:server"/>.</t>
<t>The floor control server MUST add an ERROR-CODE attribute to the Error
message. The ERROR-CODE attribute contains an Error Code from <xref target="tab:
errorcode"/>. Additionally, the floor control server may add an ERROR-INFO attri
bute with extra information about the error.</t>
</section>
</section>
<section title="Security Considerations" anchor="sec:security"> <author initials='C.' surname='Holmberg' fullname='Christer Holmberg'>
<t>BFCP uses TLS/DTLS to provide mutual authentication between clients and s <organization />
ervers. TLS/DTLS also provides replay and integrity protection and confidentiali </author>
ty. It is RECOMMENDED that TLS/DTLS with an encryption algorithm according to <
xref target="sec:lower-security"/> always be used. In cases where signaling/con
trol traffic is properly protected, as described in <xref target="sec:auth"/> it
is REQUIRED to use a mandated encryption algorithm. BFCP entities MAY use othe
r security mechanisms to interwork with legacy implementation that do not use TL
S/DTLS as long as these mechanisms provide similar security properties. An exam
ple of other mechanisms is IPSec <xref target="RFC4301"/> to effectively secure
a non-secure BFCP connection.</t>
<t>The remainder of this section analyzes some of the threats against BFCP a
nd how they are addressed.</t>
<t>An attacker may attempt to impersonate a client (a floor participant or a
floor chair) in order to generate forged floor requests or to grant or deny exi
sting floor requests. Client impersonation is avoided by having servers only acc
ept BFCP messages over authenticated TLS/DTLS connections. The floor control ser
ver assumes that attackers cannot hijack the TLS/DTLS connection and, therefore,
that messages over the TLS/DTLS connection come from the client that was initia
lly authenticated.</t>
<t>An attacker may attempt to impersonate a floor control server. A successf
ul attacker would be able to make clients think that they hold a particular floo
r so that they would try to access a resource (e.g., sending media) without havi
ng legitimate rights to access it. Floor control server impersonation is avoided
by having servers only accept BFCP messages over authenticated TLS/DTLS connect
ions, as well as ensuring clients only send and accept messages over authenticat
ed TLS/DTLS connections.</t>
<t>Attackers may attempt to modify messages exchanged by a client and a floo
r control server. The integrity protection provided by TLS/DTLS connections prev
ents this attack.</t>
<t>An attacker may attempt to fetch a valid message sent by a client to a fl
oor control server and replay it over a connection between the attacker and the
floor control server. This attack is prevented by having floor control servers c
heck that messages arriving over a given authenticated TLS/DTLS connection use a
n authorized user ID (i.e., a user ID that the user that established the authent
icated TLS/DTLS connection is allowed to use).</t>
<t>Attackers may attempt to pick messages from the network to get access to
confidential information between the floor control server and a client (e.g., wh
y a floor request was denied). TLS/DTLS confidentiality prevents this attack. Th
erefore, it is REQUIRED that TLS/DTLS be used with an encryption algorithm accor
ding to <xref target="sec:lower-security"/>.</t>
</section>
<section title="IANA Considerations" anchor="sec:iana"> <date month='April' year='2020' />
<t><list style="empty"> </front>
<t>[Note to IANA: Much of this text exists from the previous version of <seriesInfo name="RFC" value="8856"/>
this document. While the old and new additions to the registries are presented <seriesInfo name="DOI" value="10.17487/RFC8856"/>
here, the items for which IANA needs to take action with respect to this draft a </reference>
re highlighted with "Note to IANA", as with this note and the one immediately fo
llowing. Throughout this document, though, RFC XXXX needs to be replaced with t
his RFC and the IANA registries for BFCP should to refer only to this RFC.]</t>
</list></t>
<t><list style="empty">
<t>[Note to IANA: This section instructs the IANA to register new entrie
s in the BFCP Primitive subregistry in <xref target="sec:iana:primitive"/> and f
or the BFCP Error Code subregistry in <xref target="sec:iana:errorcode"/>.]</t>
</list></t>
<t>The IANA has created a registry for BFCP parameters called "Binary Floor
Control Protocol (BFCP) Parameters". This registry has a number of subregistries
, which are described in the following sections.</t>
<section title="Attribute Subregistry"> <!-- [auth] TBD increase version! -->
<t>This section establishes the Attribute subregistry under the BFCP Param <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
eters registry. As per the terminology in RFC 5226 <xref target="RFC5226"/>, the FC.4961.xml"/>
registration policy for BFCP attributes shall be "Specification Required". For <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
the purposes of this subregistry, the BFCP attributes for which IANA registratio FC.5389.xml"/>
n is requested MUST be defined by a standards-track RFC. Such an RFC MUST specif <!-- RFC 5405 obsoleted by RFC 8085 -->
y the attribute's type, name, format, and semantics.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>For each BFCP attribute, the IANA registers its type, its name, and the FC.8085.xml"/>
reference to the RFC where the attribute is defined. The following table contai <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
ns the initial values of this subregistry.</t> FC.8445.xml"/>
<texttable title="Initial values of the BFCP Attribute subregistry" </references>
anchor="tab:iana-attributes"> <references>
<ttcol align="center">Type</ttcol> <name>Informative References</name>
<ttcol>Attribute</ttcol> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<ttcol>Reference</ttcol> FC.3264.xml"/>
<c>1</c> <c>BENEFICIARY-ID</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c>2</c> <c>FLOOR-ID</c> <c>[RFC XXXX]</c> FC.4376.xml"/>
<c>3</c> <c>FLOOR-REQUEST-ID</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c>4</c> <c>PRIORITY</c> <c>[RFC XXXX]</c> FC.5239.xml"/>
<c>5</c> <c>REQUEST-STATUS</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c>6</c> <c>ERROR-CODE</c> <c>[RFC XXXX]</c> FC.3261.xml"/>
<c>7</c> <c>ERROR-INFO</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c>8</c> <c>PARTICIPANT-PROVIDED-INFO</c> <c>[RFC XXXX]</c> FC.4301.xml"/>
<c>9</c> <c>STATUS-INFO</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c>10</c> <c>SUPPORTED-ATTRIBUTES</c> <c>[RFC XXXX]</c> FC.6501.xml"/>
<c>11</c> <c>SUPPORTED-PRIMITIVES</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c>12</c> <c>USER-DISPLAY-NAME</c> <c>[RFC XXXX]</c> FC.6503.xml"/>
<c>13</c> <c>USER-URI</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c>14</c> <c>BENEFICIARY-INFORMATION</c> <c>[RFC XXXX]</c> FC.6504.xml"/>
<c>15</c> <c>FLOOR-REQUEST-INFORMATION</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<c>16</c> <c>REQUESTED-BY-INFORMATION</c> <c>[RFC XXXX]</c> FC.1191.xml"/>
<c>17</c> <c>FLOOR-REQUEST-STATUS</c> <c>[RFC XXXX]</c> <!-- RFC 1981 obsoleted by RFC 8201 -->
<c>18</c> <c>OVERALL-REQUEST-STATUS</c> <c>[RFC XXXX]</c> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</texttable> FC.8201.xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4821.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5763.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6951.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7525.xml"/>
<!-- [auth] Add reference to IMTC role-based video BCP, at some stage.
Refer to it in an informational note somehow. -->
<!-- [auth] Motivation appendix references below -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4380.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6081.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6544.xml"/>
<section title="Primitive Subregistry" anchor="sec:iana:primitive"> <!-- draft-manner-tsvwg-gut-02; IESG state Expired, expired 2011 January 13 -->
<t><list style="empty"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
<t>[Note to IANA: This section instructs the IANA to register the foll rence.I-D.draft-manner-tsvwg-gut-02.xml"/>
owing new values for the BFCP Primitive subregistry: FloorRequestStatusAck, Floo
rStatusAck, Goodbye, and GoodbyeAck.]</t>
</list></t>
<t>This section establishes the Primitive subregistry under the BFCP Param
eters registry. As per the terminology in RFC 5226 <xref target="RFC5226"/>, the
registration policy for BFCP primitives shall be "Specification Required". For
the purposes of this subregistry, the BFCP primitives for which IANA registratio
n is requested MUST be defined by a standards-track RFC. Such an RFC MUST specif
y the primitive's value, name, format, and semantics.</t>
<t>For each BFCP primitive, the IANA registers its value, its name, and th
e reference to the RFC where the primitive is defined. The following table conta
ins the initial values of this subregistry.</t>
<texttable title="Initial values of the BFCP primitive subregistry" anchor
="tab:iana-primitives">
<ttcol align="center">Value</ttcol>
<ttcol>Primitive</ttcol>
<ttcol>Reference</ttcol>
<c>1</c> <c>FloorRequest</c> <c>[RFC XXXX]</c>
<c>2</c> <c>FloorRelease</c> <c>[RFC XXXX]</c>
<c>3</c> <c>FloorRequestQuery</c> <c>[RFC XXXX]</c>
<c>4</c> <c>FloorRequestStatus</c> <c>[RFC XXXX]</c>
<c>5</c> <c>UserQuery</c> <c>[RFC XXXX]</c>
<c>6</c> <c>UserStatus</c> <c>[RFC XXXX]</c>
<c>7</c> <c>FloorQuery</c> <c>[RFC XXXX]</c>
<c>8</c> <c>FloorStatus</c> <c>[RFC XXXX]</c>
<c>9</c> <c>ChairAction</c> <c>[RFC XXXX]</c>
<c>10</c> <c>ChairActionAck</c> <c>[RFC XXXX]</c>
<c>11</c> <c>Hello</c> <c>[RFC XXXX]</c>
<c>12</c> <c>HelloAck</c> <c>[RFC XXXX]</c>
<c>13</c> <c>Error</c> <c>[RFC XXXX]</c>
<c>14</c> <c>FloorRequestStatusAck</c> <c>[RFC XXXX]</c>
<c>15</c> <c>FloorStatusAck</c> <c>[RFC XXXX]</c>
<c>16</c> <c>Goodbye</c> <c>[RFC XXXX]</c>
<c>17</c> <c>GoodbyeAck</c> <c>[RFC XXXX]</c>
</texttable>
</section>
<section title="Request Status Subregistry"> <!-- draft-ietf-mmusic-media-path-middleboxes-07; IESG state Expired, expired 20
<t>This section establishes the Request Status subregistry under the BFCP 13 December 01 -->
Parameters registry. As per the terminology in RFC 5226 <xref target="RFC5226"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
, the registration policy for BFCP request status shall be "Specification Requir rence.I-D.draft-ietf-mmusic-media-path-middleboxes-07.xml"/>
ed". For the purposes of this subregistry, the BFCP request status for which IAN
A registration is requested MUST be defined by a standards-track RFC. Such an RF
C MUST specify the value and the semantics of the request status.</t>
<t>For each BFCP request status, the IANA registers its value, its meaning
, and the reference to the RFC where the request status is defined. The followin
g table contains the initial values of this subregistry.</t>
<texttable title="Initial values of the Request Status subregistry" anchor
="tab:iana-requeststatusvalues">
<ttcol align="center">Value</ttcol>
<ttcol>Status</ttcol>
<ttcol>Reference</ttcol>
<c>1</c> <c>Pending</c> <c>[RFC XXXX]</c>
<c>2</c> <c>Accepted</c> <c>[RFC XXXX]</c>
<c>3</c> <c>Granted</c> <c>[RFC XXXX]</c>
<c>4</c> <c>Denied</c> <c>[RFC XXXX]</c>
<c>5</c> <c>Cancelled</c> <c>[RFC XXXX]</c>
<c>6</c> <c>Released</c> <c>[RFC XXXX]</c>
<c>7</c> <c>Revoked</c> <c>[RFC XXXX]</c>
</texttable>
</section>
<section title="Error Code Subregistry" anchor="sec:iana:errorcode"> <!-- [rfced] The URL appears to be for a personal site. We have updated the
<t><list style="empty"> the URL as shown below. Please let us know if corrections are required.
<t>[Note to IANA: This section instructs the IANA to register the foll
owing new values for the BFCP Error Code subregistry: 10, 11, 12, 13 and 14.]</t
>
</list></t>
<t>This section establishes the Error Code subregistry under the BFCP Para
meters registry. As per the terminology in RFC 5226 <xref target="RFC5226"/>, th
e registration policy for BFCP error codes shall be "Specification Required". Fo
r the purposes of this subregistry, the BFCP error codes for which IANA registra
tion is requested MUST be defined by a standards-track RFC. Such an RFC MUST spe
cify the value and the semantics of the error code, and any Error Specific Detai
ls that apply to it.</t>
<t>For each BFCP primitive, the IANA registers its value, its meaning, and
the reference to the RFC where the primitive is defined. The following table co
ntains the initial values of this subregistry.</t>
<texttable title="Initial Values of the Error Code subregistry" anchor="ta
b:iana-errorcode">
<ttcol align="center">Value</ttcol>
<ttcol>Meaning</ttcol>
<ttcol>Reference</ttcol>
<c>1</c> <c>Conference does not Exist</c> <c>[RFC XXXX]</c>
<c>2</c> <c>User does not Exist</c> <c>[RFC XXXX]</c>
<c>3</c> <c>Unknown Primitive</c> <c>[RFC XXXX]</c>
<c>4</c> <c>Unknown Mandatory Attribute</c> <c>[RFC XXXX]</c>
<c>5</c> <c>Unauthorized Operation</c> <c>[RFC XXXX]</c>
<c>6</c> <c>Invalid Floor ID</c> <c>[RFC XXXX]</c>
<c>7</c> <c>Floor Request ID Does Not Exist</c> <c>[RFC XXXX]</c>
<c>8</c> <c>You have Already Reached the Maximum</c> <c>[RFC XXXX]</c>
<c></c> <c> Number of Ongoing Floor Requests for</c> <c></c>
<c></c> <c> this Floor</c> <c></c>
<c>9</c> <c>Use TLS</c> <c>[RFC XXXX]</c>
<c>10</c> <c>Unable to parse message</c> <c>[RFC XXXX]</c>
<c>11</c> <c>Use DTLS</c> <c>[RFC XXXX]</c>
<c>12</c> <c>Unsupported Version</c> <c>[RFC XXXX]</c>
<c>13</c> <c>Incorrect Message Length</c> <c>[RFC XXXX]</c>
<c>14</c> <c>Generic Error</c> <c>[RFC XXXX]</c>
</texttable>
</section>
</section>
<section title="Changes from RFC 4582" anchor="sec:changes"> Original:
<t>Following is the list of technical changes and other non-trivial fixes fr [35] Guha, S. and P. Francis, "Characterization and Measurement
om <xref target="RFC4582"/>.</t> of TCP Traversal through NATs and Firewalls", 2005,
<section title="Extensions for an unreliable transport"> <http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>.
<t>Main purpose of this work was to revise the specification to support BF
CP over an unreliable transport, resulting in the following changes:</t>
<t><list style="numbers">
<t>Overview of Operation (<xref target="sec:overview"/>):<vspace/>
Changed the description of client-initiated and server-initiated tra
nsactions, referring to <xref target="sec:transactions"/>.</t>
<t>COMMON-HEADER Format (<xref target="sec:format:common"/>):<vspace/>
Ver(sion) field, where the value 2 is used for the extensions for an
unreliable transport. Added new R and F flag-bits for an unreliable transport.
Res(erved) field is now 3 bit. New optional Fragment Offset and Fragment Length
fields.</t>
<t>New primitives (<xref target="sec:format:common"/>):<vspace/>
Added four new primitives: FloorRequestStatusAck, FloorStatusAck, Go
odbye, and GoodbyeAck.</t>
<t>New error codes (<xref target="sec:format:attributes:error-code"/>)
:<vspace/>
Added three new error codes: "Unable to Parse Message", "Use DTLS" a
nd "Unsupported Version". Note that two additional error codes were added, see <
xref target="sec:changes:other"/>.</t>
<t>ABNF for new primitives (<xref target="sec:msg_format"/>):<vspace/>
New subsections with normative ABNF for the new primitives.</t>
<t>Transport split in two (<xref target="sec:transport"/>):<vspace/>
<xref target="sec:transport"/> specifying the transport was split in
two subsections; <xref target="tcp_transport"/> for a reliable transport and <x
ref target="udp_transport"/> for an unreliable transport. Where the specificatio
n for an unreliable transport amongst other issues deals with reliability, conge
stion control, fragmentation and ICMP.</t>
<t>Mandate DTLS (<xref target="sec:lower-security"/> and <xref target=
"sec:auth"/>):<vspace/>
Mandate DTLS support when transport over UDP is used.</t>
<t>Transaction changes (<xref target="sec:transactions"/>):<vspace/>
Server-initiated transactions over an unreliable transport has non-z
ero and unique Transaction ID. Over an unreliable transport, the retransmit time
rs T1 and T2 described in <xref target="timers"/> apply.</t>
<t>Requiring timely response (<xref target="timers"/>, <xref target="s
ec:client:request:response"/>, <xref target="sec:participant:cancel:response"/>,
<xref target="sec:chair:instruct:response"/>, <xref target="sec:client:floorinf
o:response"/>, <xref target="sec:client:info:response"/>, <xref target="sec:clie
nt:user:response"/>, <xref target="sec:client:hello:responses"/>, <xref target="
sec:recept:frsm"/> and <xref target="sec:recept:fsm"/>):<vspace/>
Describing that a given response must be sent within the transaction
failure window to complete the transaction.</t>
<t>Updated IANA Considerations (<xref target="sec:iana"/>):<vspace/>
Added the new primitives and error codes to <xref target="sec:iana:p
rimitive"/> and <xref target="sec:iana:errorcode"/> respectively.</t>
<t>Examples over an unreliable transport (<xref target="app:unrelcallf
low"/>):<vspace/>
Added sample interactions over an unreliable transport for the scena
rios in <xref target="fig:flow1"/> and <xref target="fig:flow2"/> </t>
<t>Motivation for an unreliable transport (<xref target="app:motivatio
n"/>):<vspace/>
Introduction to and motivation for extending BFCP to support an unre
liable transport.</t>
</list></t>
</section>
<section title="Other changes" anchor="sec:changes:other">
<t>Clarifications and bug fixes:</t>
<t><list style="numbers">
<t>ABNF fixes (<xref target="fig:ben-information"/>, <xref target="fig
:floor-request-information"/>, ="fig:reqby-information"/>, <xref target="fig:flo
or-req-status"/>, <xref target="fig:overall-req-status"/>, and the ABNF figures
in <xref target="sec:msg_format"/>):<vspace/>
Although formally correct in <xref target="RFC4582"/>, the notation h
as changed in a number of Figures to an equivalent form for clarity, e.g., s/*1(
FLOOR-ID)/[FLOOR-ID]/ in <xref target="fig:floorstatus"/> and s/*[XXX]/*(XXX)/ i
n the other figures.</t>
<t>Typo (<xref target="sec:client:hello:responses"/>):<vspace/>
Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the second
paragraph.</t>
<t>Corrected attribute type (<xref target="sec:server:request:first"/>):
<vspace/>
Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in the ei
ghth paragraph, since the note below describes priority and that the last paragr
aph deals with PARTICIPANT-PROVIDED-INFO.</t>
<t>New error codes (<xref target="sec:format:attributes:error-code"/>):<
vspace/>
Added two additional error codes: "Incorrect Message Length" and "Gene
ric Error".</t>
<t>Assorted clarifications (Across the document):<vspace/>
Language clarifications as a result of reviews. Also, the normative la
nguage where tightened where appropriate, i.e. changed from SHOULD strength to M
UST in a number of places.</t>
</list></t>
</section>
</section>
<section title="Acknowledgements" anchor="sec:acks"> Current:
<t>The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas f [37] Guha, S. and P. Francis, "Characterization and Measurement
or RFC 4582 <xref target="RFC4582"/>. Additionally, Xiaotao Wu, Paul Kyzivat, Jo of TCP Traversal through NATs and Firewalls", 2005,
nathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morga <https://www.usenix.org/legacy/event/imc05/tech/
n, and Oscar Novo provided useful comments during the work with RFC 4582. The au full_papers/guha/guha.pdf>.
thors also acknowledge contributions to the revision of BFCP for use over an unr -->
eliable transport from Geir Arne Sandbakken who had the initial idea, Alfred E.
Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Joe
rg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Cullen Jennings
, David Benham, Nivedita Melinkeri, Woo Johnman, Vijaya Mandava and Alan Ford. I
n the final phase Ernst Horvath did a thorough review revealing issues that need
ed clarification and changes. Useful and important final reviews were done by Ma
ry Barnes. Paul Jones helped tremendously as editor for changes addressing IESG
review comments.</t>
</section>
</middle>
<back> <reference anchor="IMC05" target="https://www.usenix.org/legacy/event/imc
<references title="Normative References"> 05/tech/full_papers/guha/guha.pdf">
<?rfc include="reference.RFC.2119" ?> <front>
<?rfc include="reference.RFC.2988" ?> <title>Characterization and Measurement of TCP Traversal through NAT
<?rfc include="reference.RFC.4582" ?> s and Firewalls</title>
<?rfc include="reference.RFC.5018" ?> <author initials="S" surname="Guha"/>
<?rfc include="reference.RFC.5234" ?> <author initials="P" surname="Francis"/>
<?rfc include="reference.RFC.5226" ?> <date month="" year="2005"/>
<?rfc include="reference.RFC.5246" ?> </front>
<?rfc include="reference.RFC.6347" ?> </reference>
<?rfc include="reference.RFC.3629" ?>
<?rfc include="reference.I-D.draft-ietf-bfcpbis-rfc4583bis-12" ?> <!-- T
BD increase version! -->
<?rfc include="reference.RFC.4961" ?>
<?rfc include="reference.RFC.5389" ?>
<?rfc include="reference.RFC.5405" ?>
</references>
<references title="Informational References"> <!-- [rfced] The URL appears to be for a personal site. We have updated the
<?rfc include="reference.RFC.3264" ?> the URL as shown below. Please let us know if corrections are required.
<?rfc include="reference.RFC.4376" ?>
<?rfc include="reference.RFC.5239" ?>
<?rfc include="reference.RFC.5245" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.4301" ?>
<?rfc include="reference.RFC.6501" ?>
<?rfc include="reference.RFC.6503" ?>
<?rfc include="reference.RFC.6504" ?>
<?rfc include="reference.RFC.1191" ?>
<?rfc include="reference.RFC.1981" ?>
<?rfc include="reference.RFC.4821" ?>
<?rfc include="reference.RFC.5763" ?>
<?rfc include="reference.RFC.6951" ?>
<?rfc include="reference.RFC.7525" ?>
<!-- Add reference to IMTC role-based video BCP, at some stage. Original:
Refer to it in an informational note somehow. --> [36] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
Communication Across Network Address Translators", April
2005, <http://www.brynosaurus.com/pub/net/p2pnat.pdf/>.
<!-- Motivation appendix references below --> Current:
<?rfc include="reference.RFC.4380" ?> [38] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
<?rfc include="reference.RFC.6081" ?> Communication Across Network Address Translators", April
<?rfc include="reference.RFC.4960" ?> 2005, <https://www.usenix.org/legacy/events/usenix05/tech/
<?rfc include="reference.RFC.6544" ?> general/full_papers/ford/ford.pdf>.
<?rfc include="reference.I-D.draft-manner-tsvwg-gut-02" ?> -->
<?rfc include="reference.I-D.draft-ietf-mmusic-media-path-middleboxes-07" ?>
<reference anchor="IMC05" target="http://saikat.guha.cc/pub/imc05-tcpnat.pdf
/">
<front>
<title>Characterization and Measurement of TCP Traversal through NATs an
d Firewalls</title>
<author initials="S" surname="Guha"/>
<author initials="P" surname="Francis"/>
<date month="" year="2005"/>
</front>
</reference>
<reference anchor="P2PNAT" target="http://www.brynosaurus.com/pub/net/p2pnat
.pdf/">
<front>
<title>Peer-to-Peer Communication Across Network Address Translators</ti
tle>
<author initials="B" surname="Ford"/>
<author initials="P" surname="Srisuresh"/>
<author initials="D" surname="Kegel"/>
<date month="April" year="2005"/>
</front>
</reference>
</references>
<!-- Appendices --> <reference anchor="P2PNAT" target="https://www.usenix.org/legacy/events/
<section title="Example Call Flows for BFCP over an Unreliable Transport" anch usenix05/tech/general/full_papers/ford/ford.pdf">
or="app:unrelcallflow"> <front>
<t>With reference to <xref target="sec:overview:user"/>, the following figur <title>Peer-to-Peer Communication Across Network Address Translators
es show representative call-flows for requesting and releasing a floor, and obta </title>
ining status information about a floor when BFCP is deployed over an unreliable <author initials="B" surname="Ford"/>
transport. The figures here show a loss-less interaction.</t> <author initials="P" surname="Srisuresh"/>
<t><figure align="left" anchor="ReqRelUnrelExample" title="Requesting and re <author initials="D" surname="Kegel"/>
leasing a floor"> <date month="April" year="2005"/>
<artwork align="left"><![CDATA[ </front>
</reference>
</references>
</references>
<!-- [auth] Appendices -->
<section anchor="app_unrelcallflow" numbered="true" toc="default">
<name>Example Call Flows for BFCP over an Unreliable Transport</name>
<t>With reference to <xref target="sec_overview_user" format="default"/>,
the following figures show representative call flows for requesting and releasin
g a floor, and obtaining status information about a floor when BFCP is deployed
over an unreliable transport. The figures here show a lossless interaction.</t>
<figure anchor="ReqRelUnrelExample">
<name>Requesting and releasing a floor</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorRequest | |(1) FloorRequest |
|Transaction Responder: 0 | |Transaction Responder: 0 |
|Transaction ID: 123 | |Transaction ID: 123 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorRequestStatus | |(2) FloorRequestStatus |
skipping to change at line 1899 skipping to change at line 2809
|(8) FloorRequestStatus | |(8) FloorRequestStatus |
|Transaction Responder: 1 | |Transaction Responder: 1 |
|Transaction ID: 126 | |Transaction ID: 126 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 | | Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Released | | Request Status: Released |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| ]]> |<----------------------------------------------|]]></artwork>
</artwork> </figure>
</figure></t>
<t>Note that in <xref target="ReqRelUnrelExample"/>, the FloorRequestStatus <t>Note that in <xref target="ReqRelUnrelExample" format="default"/>, the
message from the floor control server to the floor participant is a transaction- FloorRequestStatus message from the floor control server to the floor
closing message as a response to the client-initiated transaction with Transacti participant is a transaction-closing message as a response to the
on ID 154. As such, it is not followed by a FloorRequestStatusAck message from t client-initiated transaction with Transaction ID 126. As such, it is not
he floor participant to the floor control server.</t> followed by a FloorRequestStatusAck message from the floor participant to
<t><figure align="left" anchor="StatusUnrelExample" title="Obtaining status the floor control server.</t>
information about a floor"> <figure anchor="StatusUnrelExample">
<artwork align="left"><![CDATA[ <name>Obtaining status information about a floor</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
Floor Participant Floor Control Floor Participant Floor Control
Server Server
|(1) FloorQuery | |(1) FloorQuery |
|Transaction Responder: 0 | |Transaction Responder: 0 |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID: 543 | |FLOOR-ID: 543 |
|---------------------------------------------->| |---------------------------------------------->|
| | | |
|(2) FloorStatus | |(2) FloorStatus |
skipping to change at line 1988 skipping to change at line 2904
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |<----------------------------------------------|
| | | |
|(6) FloorStatusAck | |(6) FloorStatusAck |
|Transaction Responder: 1 | |Transaction Responder: 1 |
|Transaction ID: 259 | |Transaction ID: 259 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| ]]> |---------------------------------------------->|]]></artwork>
</artwork> </figure>
</figure></t> </section>
</section> <section anchor="app_motivation" numbered="true" toc="default">
<name>Motivation for Supporting an Unreliable Transport</name>
<section title="Motivation for Supporting an Unreliable Transport" anchor="app <t>This appendix is provided as an aid to understand the background and ra
:motivation"> tionale for adding support for unreliable transport.</t>
<t>This appendix is contained in this document as an aid to understand the b <section anchor="motivation" numbered="true" toc="default">
ackground and rationale for adding support for unreliable transport.</t> <name>Motivation</name>
<t>In existing video conferencing deployments, BFCP is used to manage th
<section anchor="motivation" title="Motivation"> e floor for the content sharing associated with the conference. For peer-to-peer
<t>In existing video conferencing deployments, BFCP is used to manage the scenarios, including business-to-business conferences and point-to-point confer
floor for the content sharing associated with the conference. For peer to peer s ences in general, it is frequently the case that one or both endpoints exist beh
cenarios, including business to business conferences and point to point conferen ind a NAT. BFCP roles are negotiated in the offer/answer exchange as specified i
ces in general, it is frequently the case that one or both endpoints exists behi n <xref target="RFC8856" format="default"/>, resulting in one endpoint being res
nd a NAT. BFCP roles are negotiated in the offer/answer exchange as specified in ponsible for opening the TCP connection used for the BFCP communication.</t>
<xref target="I-D.ietf-bfcpbis-rfc4583bis"/>, resulting in one endpoint being r <figure anchor="use_case">
esponsible for opening the TCP connection used for the BFCP communication.</t> <name>Use case</name>
<t><figure align="left" anchor="use_case" title="Use Case"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
+---------+ +---------+
| Network | | Network |
+---------+ +---------+
+-----+ / \ +-----+ +-----+ / \ +-----+
| NAT |/ \| NAT | | NAT |/ \| NAT |
+-----+ +-----+ +-----+ +-----+
+----+ / \ +----+ +----+ / \ +----+
|BFCP|/ \|BFCP| |BFCP|/ \|BFCP|
| UA | | UA | | UA | | UA |
+----+ +----+ ]]></artwork> +----+ +----+]]></artwork>
</figure></t> </figure>
<t>The communication session between the video conferencing endpoints ty
<t>The communication session between the video conferencing endpoints typi pically consists of a number of RTP over UDP media streams for audio and video a
cally consists of a number of RTP over UDP media streams, for audio and video, a nd a BFCP connection for floor control. Existing deployments are most common in,
nd a BFCP connection for floor control. Existing deployments are most common in, but not limited to, enterprise networks. In existing deployments, NAT traversal
but not limited to, enterprise networks. In existing deployments, NAT traversal for the RTP streams works using ICE and/or other methods, including those descr
for the RTP streams works using ICE and/or other methods, including those descr ibed in <xref target="I-D.ietf-mmusic-media-path-middleboxes" format="default"/>
ibed in <xref target="I-D.ietf-mmusic-media-path-middleboxes"/>.</t> .</t>
<t>When enhancing an existing SIP based video conferencing deployment with <t>When enhancing an existing SIP-based video conferencing deployment wi
support for content sharing, the BFCP connection often poses a problem. The rea th support for content sharing, the BFCP connection often poses a problem. The r
sons for this fall into two general classes. First, there may be a strong prefer easons for this fall into two general classes. First, there may be a strong pref
ence for UDP based signaling in general. On high capacity endpoints (e.g., PSTN erence for UDP-based signaling in general. On high-capacity endpoints (e.g., Pub
gateways or SIP/H.323 inter-working gateways), TCP can suffer from head of line lic Switched Telephone Network (PSTN) gateways or SIP/H.323 inter-working gatewa
blocking, and it uses many kernel buffers. Network operators view UDP as a way t ys), TCP can suffer from head-of-line blocking, and it uses many kernel buffers.
o avoid both of these. Second, establishment and traversal of the TCP connection Network operators view UDP as a way to avoid both of these. Second, the establi
involving ephemeral ports, as is typically the case with BFCP over TCP, can be shment and traversal of the TCP connection involving ephemeral ports, as is typi
problematic, as described in Appendix A of <xref target="RFC6544"/>. A broad stu cally the case with BFCP over TCP, can be problematic, as described in <xref tar
dy of NAT behavior and peer-to-peer TCP establishment for a comprehensive set of get="RFC6544" section="A" sectionFormat="of" format="default"/>. A broad study o
TCP NAT traversal techniques over a wide range of commercial NAT products concl f NAT behavior and peer-to-peer TCP establishment for a comprehensive set of TCP
uded it was not possible to establish a TCP connection in 11% of the cases <xref NAT traversal techniques over a wide range of commercial NAT products concluded
target="IMC05"/>. The results are worse when focusing on enterprise NATs. A stu that it was not possible to establish a TCP connection in 11% of the cases <xre
dy of hole punching as a NAT traversal technique across a wide variety of deploy f target="IMC05" format="default"/>. The results are worse when focusing on ente
ed NATs reported consistently higher success rates when using UDP than when usin rprise NATs. A study of hole-punching as a NAT traversal technique across a wide
g TCP <xref target="P2PNAT"/>.</t> variety of deployed NATs reported consistently higher success rates when using
<t>It is worth noticing that BFCP over UDP is already being used in real d UDP than when using TCP <xref target="P2PNAT" format="default"/>.</t>
eployments, underlining the necessity to specify a common way to exchange BFCP m <t>It is worth noting that BFCP over UDP is already being used in real d
essages where TCP is not appropriate, to avoid a situation where multiple differ eployments, underlining the necessity to specify a common way to exchange BFCP m
ent and non-interoperable implementations would co-exist in the market. The purp essages where TCP is not appropriate, to avoid a situation where multiple differ
ose of this draft is to formalize and publish the extension from the standard sp ent and non-interoperable implementations would coexist in the market. The purpo
ecification to facilitate complete interoperability between implementations.</t> se of this document is to extend the standard specification to support unreliabl
e transport in order to facilitate complete interoperability between implementat
<section anchor="alternatives" title="Alternatives Considered"> ions.</t>
<t>In selecting the approach of defining UDP as an alternate transport f <section anchor="alternatives" numbered="true" toc="default">
or BFCP, several alternatives were considered and explored to some degree. Each <name>Alternatives Considered</name>
of these is discussed briefly in the following subsections. In summary, while th <t>In selecting the approach of defining UDP as an alternate transport
e not chosen alternatives work in a number of scenarios, they are not sufficient for BFCP, several alternatives were considered and explored to some degree. Eac
, in and of themselves, to address the use case targeted by this draft. The last h of these is discussed briefly in the following subsections. In summary, while
alternative, presented in <xref target="thisextension"/>, is the selected one a the alternatives that were not chosen work in a number of scenarios, they are no
nd is specified in this draft.</t> t sufficient, in and of themselves, to address the use case targeted by this doc
<t>It is also worth noting that the IETF Transport Area were asked for a ument. The last alternative, presented in <xref target="thisextension" format="d
way to tunnel TCP over UDP, but at that point there was no consensus on how to efault"/>, was selected and is specified in this document.</t>
achieve that.</t> <t>It is also worth noting that the IETF Transport Area was asked for
a way to tunnel TCP over UDP, but at that point there was no consensus on how to
<section anchor="ice_tcp" title="ICE TCP"> achieve that.</t>
<t>ICE TCP <xref target="RFC6544"/> extends ICE to TCP based media, in <section anchor="ice_tcp" numbered="true" toc="default">
cluding the ability to offer a mix of TCP and UDP based candidates for a single <name>ICE TCP</name>
stream. ICE TCP has, in general, a lower success probability for enabling TCP co <t>ICE TCP <xref target="RFC6544" format="default"/> extends ICE to
nnectivity without a relay if both of the hosts are behind a NAT (see Appendix A TCP-based media, including the ability to offer a mix of TCP- and UDP-based cand
of <xref target="RFC6544"/>) than enabling UDP connectivity in the same scenari idates for a single stream. ICE TCP has, in general, a lower success probability
os. The happens because many of the currently deployed NATs in video conferencin for enabling TCP connectivity without a relay if both of the hosts are behind a
g networks do not support the flow of TCP hand shake packets seen in case of TCP NAT (see <xref target="RFC6544" section="A" sectionFormat="of" format="default"
simultaneous-open, either because they do not allow incoming TCP SYN packets fr />) than enabling UDP connectivity in the same scenarios. The happens because ma
om an address to which a SYN packet has been sent to recently, or because they d ny of the currently deployed NATs in video conferencing networks do not support
o not properly process the subsequent SYNACK. Implementing various techniques ad the flow of TCP handshake packets seen in the case of TCP simultaneous-open, eit
vocated for candidate collection in <xref target="RFC6544"/> should increase the her because they do not allow incoming TCP SYN packets from an address to which
success probability, but many of these techniques require support from some net a SYN packet has been sent recently, or because they do not properly process the
work elements (e.g., from the NATs). Such support is not common in enterprise NA subsequent SYNACK. Implementing various techniques advocated for candidate coll
Ts.</t> ection in <xref target="RFC6544" format="default"/> should increase the success
</section> probability, but many of these techniques require support from some network elem
ents (e.g., from the NATs). Such support is not common in enterprise NATs.</t>
<section anchor="teredo" title="Teredo"> </section>
<t>Teredo <xref target="RFC4380"/> enables nodes located behind one or <section anchor="teredo" numbered="true" toc="default">
more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. Tere <name>Teredo</name>
do extensions <xref target="RFC6081"/> provide additional capabilities to Teredo <t>Teredo <xref target="RFC4380" format="default"/> enables nodes lo
, including support for more types of NATs and support for more efficient commun cated behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling pack
ication.</t> ets over UDP. Teredo extensions <xref target="RFC6081" format="default"/> provi
<t>As defined, Teredo could be used to make BFCP work for the video co de additional capabilities to Teredo, including support for more types of NATs a
nferencing use cases addressed in this draft. However, running the service requi nd support for more efficient communication.</t>
res the help of "Teredo servers" and "Teredo relays" <xref target="RFC4380"/>. T <t>As defined, Teredo could be used to make BFCP work for the video
hese servers and relays generally do not exist in the existing video conferencin conferencing use cases addressed in this document. However, running the service
g deployments. It also requires IPv6 awareness on the endpoints. It should also requires the help of "Teredo servers" and "Teredo relays" <xref target="RFC4380"
be noted that ICMP6, as used with Teredo to complete an initial protocol exchang format="default"/>. These servers and relays generally do not exist in current
e and confirm that the appropriate NAT bindings have been set up, is not a conve video conferencing deployments. It also requires IPv6 awareness on the endpoints
ntional feature of IPv4 or even IPv6, and some currently deployed IPv6 firewalls . It should also be noted that ICMP6, as used with Teredo to complete an initial
discard ICMP messages. As these networks continue to evolve and tackle the tran protocol exchange and confirm that the appropriate NAT bindings have been set u
saction to IPv6, Teredo servers and relays may be deployed, making Teredo availa p, is not a conventional feature of IPv4 or even IPv6, and some currently deploy
ble as a suitable alternative to BFCP over UDP.</t> ed IPv6 firewalls discard ICMP messages. As these networks continue to evolve an
</section> d tackle the transaction to IPv6, Teredo servers and relays may be deployed, mak
ing Teredo available as a suitable alternative to BFCP over UDP.</t>
<section anchor="gut" title="GUT"> </section>
<t>GUT <xref target="I-D.manner-tsvwg-gut"/> attempts to facilitate tu <section anchor="gut" numbered="true" toc="default">
nneling over UDP by encapsulating the native transport protocol and its payload <name>GUT</name>
(in general the whole IP payload) within a UDP packet destined to the well-known <t>GUT <xref target="I-D.manner-tsvwg-gut" format="default"/>
port GUT_P. Unfortunately, it requires user-space TCP, for which there is not a attempts to facilitate tunneling over UDP by encapsulating the
readily available implementation, and creating one is a large project in itself native transport protocol and its payload (in general the whole IP
. This draft has expired and its future is still not clear as it has not yet bee payload) within a UDP packet destined to the well-known port
n adopted by a working group.</t> GUT_P. Unfortunately, it requires user-space TCP, for which there
</section> is not a readily available implementation, and creating one is a
large project in itself. This document has expired, and its future is
<section anchor="upnp_igd" title="UPnP IGD"> still unclear as it has not yet been adopted by a working group.</t>
<t>Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on </section>
the edge of the network, providing connectivity to the Internet for computers in <section anchor="upnp_igd" numbered="true" toc="default">
ternal to the LAN, but do not allow Internet devices to connect to computers on <name>UPnP IGD</name>
the internal LAN. IGDs enable a computer on an internal LAN to create port mappi <t>Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit o
ngs on their NAT, through which hosts on the Internet can send data that will be n the edge of the network, providing connectivity to the Internet for computers
forwarded to the computer on the internal LAN. IGDs may be self-contained hardw internal to the LAN, but do not allow Internet devices to connect to computers o
are devices or may be software components provided within an operating system.</ n the internal LAN. IGDs enable a computer on an internal LAN to create port map
t> pings on their NAT, through which hosts on the Internet can send data that will
<t>In considering UPnP IGD, several issues exist. Not all NATs support be forwarded to the computer on the internal LAN. IGDs may be self-contained har
UPnP, and many that do support it are configured with it turned off by default. dware devices or may be software components provided within an operating system.
NATs are often multilayered, and UPnP does not work well with such NATs. For ex </t>
ample, a typical DSL modems acts as a NAT, and the user plugs in a wireless acce <t>In considering UPnP IGD, several issues exist. Not all NATs suppo
ss point behind that, which adds another layer NAT. The client can discover the rt UPnP, and many that do support it are configured with it turned off by defaul
first layer of NAT using multicast but it is harder to figure out how to discove t. NATs are often multilayered, and UPnP does not work well with such NATs. For
r and control NATs in the next layer up.</t> example, a typical DSL modem acts as a NAT, and the user plugs in a wireless acc
</section> ess point behind that, which adds another layer of NAT. The client can discover
the first layer of NAT using multicast, but it is harder to figure out how to di
<section anchor="nat_pmp" title="NAT PMP"> scover and control NATs in the next layer up.</t>
<t>The NAT Port Mapping Protocol (NAT PMP) allows a computer in a priv </section>
ate network (behind a NAT router) to automatically configure the router to allow <section anchor="nat_pmp" numbered="true" toc="default">
parties outside the private network to contact it. NAT PMP runs over UDP. It es <name>NAT PMP</name>
sentially automates the process of port forwarding. Included in the protocol is <t>The NAT Port Mapping Protocol (NAT PMP) allows a computer in a pr
a method for retrieving the public IP address of a NAT gateway, thus allowing a ivate network (behind a NAT router) to automatically configure the router to all
client to make this public IP address and port number known to peers that may wi ow parties outside the private network to contact it. NAT PMP runs over UDP. It
sh to communicate with it.</t> essentially automates the process of port forwarding. Included in the protocol i
<t>Many NATs do not support PMP. In those that do support it, it has s s a method for retrieving the public IP address of a NAT gateway, thus allowing
imilar issues with negotiation of multilayer NATs as UPnP. Video conferencing is a client to make this public IP address and port number known to peers that may
used extensively in enterprise networks, and NAT PMP is not generally available wish to communicate with it.</t>
in enterprise-class routers.</t> <t>Many NATs do not support PMP. In those that do support it, it has
</section> similar issues with negotiation of multilayer NATs as UPnP. Video conferencing
is used extensively in enterprise networks, and NAT PMP is not generally availab
<section anchor="sctp_udp" title="SCTP"> le in enterprise-class routers.</t>
<t>It would be quite straight forward to specify a BFCP binding for SC </section>
TP <xref target="RFC4960"/>, and then tunnel SCTP over UDP in the use case descr <section anchor="sctp_udp" numbered="true" toc="default">
ibed in <xref target="motivation"/>. SCTP is gaining some momentum currently. Th <name>SCTP</name>
ere was ongoing discussion in the RTCWeb WG regarding this approach, which resul <t>It would be quite straightforward to specify a BFCP binding for S
ted in <xref target="RFC6951"/>. However, this approach for tunneling over UDP w tream Control Transmission Protocol (SCTP) <xref target="RFC4960" format="defaul
as not mature enough when considered and not even fully specified.</t> t"/>, and then tunnel SCTP over UDP in the use case described in <xref target="m
</section> otivation" format="default"/>. SCTP is gaining some momentum currently. There wa
s ongoing discussion in the RTCWeb Working Group regarding this approach, which
resulted in <xref target="RFC6951" format="default"/>. However, this approach to
tunneling over UDP was not mature enough when considered and was not even fully
specified.</t>
</section>
<section anchor="thisextension" numbered="true" toc="default">
<name>BFCP over UDP Transport</name>
<t>To overcome the problems with establishing TCP flows between BFCP
entities, an alternative is to define UDP as an alternate transport for BFCP, l
everaging the same mechanisms in place for the RTP over UDP media streams for th
e BFCP communication. When using UDP as the transport, following the guidelines
provided in <xref target="RFC8085" format="default"/> is recommended.</t>
<t>Minor changes to the transaction model have been introduced in th
at all requests now have an appropriate response to complete the transaction. Th
e requests are sent with a retransmission timer associated with the response to
achieve reliability. This alternative does not change the semantics of BFCP. It
permits UDP as an alternate transport.</t>
<section anchor="thisextension" title="BFCP over UDP transport"> <t>Existing implementations, in the spirit of the approach detailed
<t>To overcome the problems with establishing TCP flows between BFCP e in earlier draft versions of this document, have demonstrated that this approach
ntities, an alternative is to define UDP as an alternate transport for BFCP, lev is feasible. Initial compatibility among implementations has been achieved at p
eraging the same mechanisms in place for the RTP over UDP media streams for the revious interoperability events. The authors view this extension as a pragmatic
BFCP communication. When using UDP as the transport, it is recommended to follow solution to an existing deployment challenge. This is the chosen approach, and t
the guidelines provided in <xref target="RFC5405"/>.</t> he extensions are specified in this document.</t>
<t>Minor changes to the transaction model are introduced in that all r </section>
equests now have an appropriate response to complete the transaction. The reques
ts are sent with a retransmit timer associated with the response to achieve reli
ability. This alternative does not change the semantics of BFCP. It permits UDP
as an alternate transport.</t>
<t>Existing implementations, in the spirit of the approach detailed in
earlier versions of this draft, have demonstrated this approach to be feasible.
Initial compatibility among implementations has been achieved at previous inter
operability events. The authors view this extension as a pragmatic solution to a
n existing deployment challenge. This is the chosen approach, and the extensions
are specified in this document.</t>
</section> </section>
</section> </section>
</section> </section>
</section> <section anchor="sec_acks" numbered="false" toc="default">
<name>Acknowledgements</name>
</back> <t>The XCON Working Group chairs, <contact fullname="Adam Roach"/> and <co
ntact fullname="Alan Johnston"/>, provided useful ideas for RFC 4582 <xref targe
t="RFC4582" format="default"/>. Additionally, <contact fullname="Xiaotao Wu"/>,
<contact fullname="Paul Kyzivat"/>, <contact fullname="Jonathan Rosenberg"/>, <c
ontact fullname="Miguel A.&nbsp;Garcia-Martin"/>, <contact fullname="Mary Barnes
"/>, <contact fullname="Ben Campbell"/>, <contact fullname="Dave Morgan"/>, and
<contact fullname="Oscar Novo"/> provided useful comments during the work with R
FC 4582. The authors also acknowledge contributions to the revision of BFCP for
use over an unreliable transport from <contact fullname="Geir Arne Sandbakken"/>
who had the initial idea, <contact fullname="Alfred E.&nbsp;Heggestad"/>, <cont
act fullname="Trond G. Andersen"/>, <contact fullname="Gonzalo Camarillo"/>, <co
ntact fullname="Roni Even"/>, <contact fullname="Lorenzo Miniero"/>, <contact fu
llname="Jörg Ott"/>, <contact fullname="Eoin McLeod"/>, <contact fullname="Mark
K.&nbsp;Thompson"/>, <contact fullname="Hadriel Kaplan"/>, <contact fullname="Da
n Wing"/>, <contact fullname="Cullen Jennings"/>, <contact fullname="David Benha
m"/>, <contact fullname="Nivedita Melinkeri"/>, <contact fullname="Woo Johnman"/
>, <contact fullname="Vijaya Mandava"/>, and <contact fullname="Alan Ford"/>. In
the final phase, <contact fullname="Ernst Horvath"/> did a thorough review, rev
ealing issues that needed clarification and changes. Useful and important final
reviews were done by <contact fullname="Mary Barnes"/>. <contact fullname="Paul
Jones"/> helped tremendously as editor for changes addressing IESG review comme
nts.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 135 change blocks. 
3055 lines changed or deleted 3952 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/