rfc8855xml2.original.xml   rfc8855.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> nsus="true" docName="draft-ietf-bfcpbis-rfc4582bis-16" indexInclude="true" ipr="
trust200902" number="8855" obsoletes="4582" prepTime="2021-01-17T13:06:20" scrip
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> ts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="false" tocDepth
="4" tocInclude="true" xml:lang="en">
<rfc category="std" ipr="trust200902" docName="draft-ietf-bfcpbis-rfc4582bis-16" <link href="https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis-16"
obsoletes="4582"> rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8855" rel="alternate"/>
<?rfc strict="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc toc="yes"?> <front>
<?rfc tocdepth="4"?> <title abbrev="BFCP">The Binary Floor Control Protocol (BFCP)</title>
<?rfc symrefs="no"?> <seriesInfo name="RFC" value="8855" stream="IETF"/>
<?rfc sortrefs="yes" ?> <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<?rfc compact="yes" ?> <organization showOnFrontPage="true">Ericsson</organization>
<?rfc subcompact="no" ?> <address>
<postal>
<front> <street>Hirsalantie 11</street>
<title abbrev="BFCP">The Binary Floor Control Protocol (BFCP)</title> <code>02420</code>
<city>Jorvas</city>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo"> <country>Finland</country>
<organization>Ericsson</organization> </postal>
<address> <email>gonzalo.camarillo@ericsson.com</email>
<postal> </address>
<street>Hirsalantie 11</street> </author>
<city>FI-02420 Jorvas</city> <author initials="K." surname="Drage" fullname="Keith Drage">
<country>Finland</country> <address>
</postal> <postal>
<email>gonzalo.camarillo@ericsson.com</email> </postal>
</address> <email>drageke@ntlworld.com</email>
</author> </address>
</author>
<author initials="K." surname="Drage" fullname="Keith Drage"> <author fullname="Tom Kristensen" initials="T." surname="Kristensen">
<organization>Alcatel-Lucent</organization> <organization abbrev="Jotron" showOnFrontPage="true">Jotron AS</organizati
<address> on>
<postal> <address>
<street>Quadrant, StoneHill Green, Westlea</street> <postal>
<street>Swindon, Wilts</street> <street>Ringdalskogen 8</street>
<country>UK</country> <code>3270</code>
</postal> <city>Larvik</city>
<email>drage@alcatel-lucent.com</email> <country>Norway</country>
</address> </postal>
</author> <email>tom.kristensen@jotron.com, tomkri@ifi.uio.no</email>
</address>
<author fullname="Tom Kristensen" initials="T." surname="Kristensen"> </author>
<organization>Cisco</organization> <author initials="J." surname="Ott" fullname="Jörg Ott">
<address> <organization showOnFrontPage="true">Technical University Munich</organiza
<postal> tion>
<street>Philip Pedersens vei 1</street> <address>
<city>NO-1366 Lysaker</city> <postal>
<country>Norway</country> <street>Boltzmannstrasse 3</street>
</postal> <code>85748</code>
<email>tomkrist@cisco.com, tomkri@ifi.uio.no</email> <city>Garching</city>
</address> <country>Germany</country>
</author> </postal>
<email>ott@in.tum.de</email>
<author initials="J." surname="Ott" fullname="Joerg Ott"> </address>
<organization>Aalto University</organization> </author>
<address> <author fullname="Charles Eckel" initials="C." surname="Eckel">
<postal> <organization showOnFrontPage="true">Cisco</organization>
<street>Otakaari 5 A</street> <address>
<city>FI-02150 Espoo</city> <postal>
<country>Finland</country> <street>707 Tasman Drive</street>
</postal> <city>Milpitas</city>
<email>jo@comnet.tkk.fi</email> <region>California</region>
</address> <code>95035</code>
</author> <country>United States of America</country>
</postal>
<author fullname="Charles Eckel" initials="C." surname="Eckel"> <email>eckelcu@cisco.com</email>
<organization>Cisco</organization> </address>
<address> </author>
<postal> <date month="01" year="2021"/>
<street>707 Tasman Drive</street> <area>Real-time Applications and Infrastructure</area>
<city>California, CA 95035</city> <workgroup>BFCPbis Working Group</workgroup>
<country>United States</country> <keyword>floor control</keyword>
</postal> <keyword>conference</keyword>
<email>eckelcu@cisco.com</email> <abstract pn="section-abstract">
</address> <t indent="0" pn="section-abstract-1">Floor control is a means to manage j
</author> oint or exclusive access to
shared resources in a (multiparty) conferencing environment. Thereby,
<!-- Maximum 5 authors in current xml2rfc floor control complements other functions -- such as conference and
<author fullname="Paul E. Jones" initials="P.E." surname="Jones"> media session setup, conference policy manipulation, and media control
<organization>Cisco</organization> -- that are realized by other protocols.</t>
<address> <t indent="0" pn="section-abstract-2">This document specifies the Binary F
<postal> loor Control Protocol
<street>7025 Kit Creek Rd.</street> (BFCP). BFCP is used between floor participants and floor control
<city>Research Triangle Park, NC 27709</city> servers, and between floor chairs (i.e., moderators) and floor control
<country>USA</country> servers.</t>
</postal> <t indent="0" pn="section-abstract-3">This document obsoletes RFC 4582.</t
<email>paulej@packetizer.com</email> >
</address> </abstract>
</author> <boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<date/> "exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
<area>Real-time Applications and Infrastructure</area> >
<workgroup>BFCPbis Working Group</workgroup> <t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
<keyword>floor control</keyword> </t>
<keyword>conference</keyword> <t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
<abstract> (IETF). It represents the consensus of the IETF community. It has
<t>Floor control is a means to manage joint or exclusive access to shared re received public review and has been approved for publication by
sources in a (multiparty) conferencing environment. Thereby, floor control compl the Internet Engineering Steering Group (IESG). Further
ements other functions -- such as conference and media session setup, conference information on Internet Standards is available in Section 2 of
policy manipulation, and media control -- that are realized by other protocols. RFC 7841.
</t> </t>
<t>This document specifies the Binary Floor Control Protocol (BFCP). BFCP is <t indent="0" pn="section-boilerplate.1-3">
used between floor participants and floor control servers, and between floor ch Information about the current status of this document, any
airs (i.e., moderators) and floor control servers.</t> errata, and how to provide feedback on it may be obtained at
<t>This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in <eref target="https://www.rfc-editor.org/info/rfc8855" brackets="non
Section 16.</t> e"/>.
<!-- Ensure correct section #, as xref is no </t>
t allowed in abstract --> </section>
</abstract> <section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
</front> ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<middle> <t indent="0" pn="section-boilerplate.2-1">
<section title="Introduction" anchor="sec:intro"> Copyright (c) 2021 IETF Trust and the persons identified as the
<t>Within a conference, some applications need to manage the access to a set document authors. All rights reserved.
of shared resources, such as the right to send media to a particular media sess </t>
ion. Floor control enables such applications to provide users with coordinated ( <t indent="0" pn="section-boilerplate.2-2">
shared or exclusive) access to these resources.</t> This document is subject to BCP 78 and the IETF Trust's Legal
<t>The Requirements for Floor Control Protocol <xref target="RFC4376"/> list Provisions Relating to IETF Documents
a set of requirements that need to be met by floor control protocols. The Binar (<eref target="https://trustee.ietf.org/license-info" brackets="none
y Floor Control Protocol (BFCP), which is specified in this document, meets thes "/>) in effect on the date of
e requirements.</t> publication of this document. Please review these documents
<t>In addition, BFCP has been designed so that it can be used in low-bandwid carefully, as they describe your rights and restrictions with
th environments. The binary encoding used by BFCP achieves a small message size respect to this document. Code Components extracted from this
(when message signatures are not used) that keeps the time it takes to transmit document must include Simplified BSD License text as described in
delay-sensitive BFCP messages to a minimum. Delay-sensitive BFCP messages includ Section 4.e of the Trust Legal Provisions and are provided without
e FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expecte warranty as described in the Simplified BSD License.
d that future extensions to these messages will not increase the size of these m </t>
essages in a significant way.</t> </section>
<t>The remainder of this document is organized as follows: <xref target="sec </boilerplate>
:terminology"/> defines the terminology used throughout this document, <xref tar <toc>
get="sec:scope"/> discusses the scope of BFCP (i.e., which tasks fall within the <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
scope of BFCP and which ones are performed using different mechanisms), <xref t n="section-toc.1">
arget="sec:overview"/> provides a non-normative overview of BFCP operation, and <name slugifiedName="name-table-of-contents">Table of Contents</name>
subsequent sections provide the normative specification of BFCP.</t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
</section> c.1-1">
<li pn="section-toc.1-1.1">
<section title="Terminology" anchor="sec:terminology"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
LD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in th derivedContent="" format="title" sectionFormat="of" target="name-introduction">
is document are to be interpreted as described in BCP 14, <xref target="RFC2119" Introduction</xref></t>
>RFC 2119</xref> and indicate requirement levels for compliant implementations.< </li>
/t> <li pn="section-toc.1-1.2">
<t>Media Participant: An entity that has access to the media resources of a <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
conference (e.g., it can receive a media stream). In floor-controlled conference ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
s, a given media participant is typically colocated with a floor participant, bu derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
t it does not need to be. Third-party floor requests consist of having a floor p erminology</xref></t>
articipant request a floor for a media participant when they are not colocated. </li>
The protocol between a floor participant and a media participant (that are not c <li pn="section-toc.1-1.3">
olocated) is outside the scope of this document.</t> <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
<t>Client: A floor participant or a floor chair that communicates with a flo at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
or control server using BFCP.</t> ormat="title" sectionFormat="of" target="name-scope">Scope</xref></t>
<t>Floor: A temporary permission to access or manipulate a specific shared r <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
esource or set of resources.</t> n-toc.1-1.3.2">
<t>Floor Chair: A logical entity that manages one floor (grants, denies, or <li pn="section-toc.1-1.3.2.1">
revokes a floor). An entity that assumes the logical role of a floor chair for a <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><
given transaction may assume a different role (e.g., floor participant) for a d xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.
ifferent transaction. The roles of floor chair and floor participant are defined 1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fl
on a transaction-by-transaction basis. BFCP transactions are defined in <xref t oor-creation">Floor Creation</xref></t>
arget="sec:transactions"/>.</t> </li>
<t>Floor Control: A mechanism that enables applications or users to gain saf <li pn="section-toc.1-1.3.2.2">
e and mutually exclusive or non-exclusive input access to the shared object or r <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
esource.</t> "3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
<t>Floor Control Server: A logical entity that maintains the state of the fl Content="" format="title" sectionFormat="of" target="name-obtaining-information-
oor(s), including which floors exists, who the floor chairs are, who holds a flo to-co">Obtaining Information to Contact a Floor Control Server</xref></t>
or, etc. Requests to manipulate a floor are directed at the floor control serve </li>
r. The floor control server of a conference may perform other logical roles (e.g <li pn="section-toc.1-1.3.2.3">
., floor participant) in another conference.</t> <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent=
<t>Floor Participant: A logical entity that requests floors, and possibly in "3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derived
formation about them, from a floor control server. An entity that assumes the lo Content="" format="title" sectionFormat="of" target="name-obtaining-floor-resour
gical role of a floor participant for a given transaction may assume a different ce-as">Obtaining Floor-Resource Associations</xref></t>
role (e.g., a floor chair) for a different transaction. The roles of floor part </li>
icipant and floor chair are defined on a transaction-by-transaction basis. BFCP <li pn="section-toc.1-1.3.2.4">
transactions are defined in <xref target="sec:transactions"/>. In floor-controll <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent=
ed conferences, a given floor participant is typically colocated with a media pa "3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derived
rticipant, but it does not need to be. Third-party floor requests consist of hav Content="" format="title" sectionFormat="of" target="name-privileges-of-floor-co
ing a floor participant request a floor for a media participant when they are no ntrol">Privileges of Floor Control</xref></t>
t colocated.</t> </li>
<t>Participant: An entity that acts as a floor participant, as a media parti </ul>
cipant, or as both.</t> </li>
<t>BFCP Connection: A transport association between BFCP entities, used to e <li pn="section-toc.1-1.4">
xchange BFCP messages.</t> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
<t>Transaction Failure Window: When communicating over an unreliable transpo at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
rt, this is some period of time less than or equal to T1*2^4 (see <xref target=" ormat="title" sectionFormat="of" target="name-overview-of-operation">Overview of
timers"/>). For reliable transports, this period of time is unbounded.</t> Operation</xref></t>
</section> <ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<section title="Scope" anchor="sec:scope"> <li pn="section-toc.1-1.4.2.1">
<t>As stated earlier, BFCP is a protocol to coordinate access to shared reso <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
urces in a conference following the requirements defined in <xref target="RFC437 "4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
6"/>. Floor control complements other functions defined in the XCON conferencin Content="" format="title" sectionFormat="of" target="name-floor-participant-to-f
g framework <xref target="RFC5239"/>. The floor control protocol BFCP defined in loor-">Floor Participant to Floor Control Server Interface</xref></t>
this document only specifies a means to arbitrate access to floors. The rules </li>
and constraints for floor arbitration and the results of floor assignments are o <li pn="section-toc.1-1.4.2.2">
utside the scope of this document and are defined by other protocols <xref targe <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
t="RFC5239"/>.</t> "4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
<t><xref target="fig:arch"/> shows the tasks that BFCP can perform.</t> Content="" format="title" sectionFormat="of" target="name-floor-chair-to-floor-c
<t><figure anchor="fig:arch" title="Functionality provided by BFCP"> ontro">Floor Chair to Floor Control Server Interface</xref></t>
<artwork><![CDATA[ </li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-packet-format">Packet Format</xref
></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-common-header-format">
COMMON-HEADER Format</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-attribute-format">Attr
ibute Format</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.2.2">
<li pn="section-toc.1-1.5.2.2.2.1">
<t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derived
Content="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-beneficiar
y-id">BENEFICIARY-ID</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derived
Content="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-floor-id">
FLOOR-ID</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.3">
<t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derived
Content="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-floor-requ
est-id">FLOOR-REQUEST-ID</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.4">
<t indent="0" pn="section-toc.1-1.5.2.2.2.4.1"><xref derived
Content="5.2.4" format="counter" sectionFormat="of" target="section-5.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-priority">
PRIORITY</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.5">
<t indent="0" pn="section-toc.1-1.5.2.2.2.5.1"><xref derived
Content="5.2.5" format="counter" sectionFormat="of" target="section-5.2.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-request-st
atus">REQUEST-STATUS</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.6">
<t indent="0" pn="section-toc.1-1.5.2.2.2.6.1"><xref derived
Content="5.2.6" format="counter" sectionFormat="of" target="section-5.2.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-error-code
">ERROR-CODE</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.5.2.2.2.6.2">
<li pn="section-toc.1-1.5.2.2.2.6.2.1">
<t indent="0" pn="section-toc.1-1.5.2.2.2.6.2.1.1"><xref
derivedContent="5.2.6.1" format="counter" sectionFormat="of" target="section-5.
2.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="nam
e-error-specific-details-for-">Error Specific Details for Error Code 4</xref></t
>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.2.2.7">
<t indent="0" pn="section-toc.1-1.5.2.2.2.7.1"><xref derived
Content="5.2.7" format="counter" sectionFormat="of" target="section-5.2.7"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-error-info
">ERROR-INFO</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.8">
<t indent="0" pn="section-toc.1-1.5.2.2.2.8.1"><xref derived
Content="5.2.8" format="counter" sectionFormat="of" target="section-5.2.8"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-participan
t-provided-info">PARTICIPANT-PROVIDED-INFO</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.9">
<t indent="0" pn="section-toc.1-1.5.2.2.2.9.1"><xref derived
Content="5.2.9" format="counter" sectionFormat="of" target="section-5.2.9"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-status-inf
o">STATUS-INFO</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.10">
<t indent="0" pn="section-toc.1-1.5.2.2.2.10.1"><xref derive
dContent="5.2.10" format="counter" sectionFormat="of" target="section-5.2.10"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-supporte
d-attributes">SUPPORTED-ATTRIBUTES</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.11">
<t indent="0" pn="section-toc.1-1.5.2.2.2.11.1"><xref derive
dContent="5.2.11" format="counter" sectionFormat="of" target="section-5.2.11"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-supporte
d-primitives">SUPPORTED-PRIMITIVES</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.12">
<t indent="0" pn="section-toc.1-1.5.2.2.2.12.1"><xref derive
dContent="5.2.12" format="counter" sectionFormat="of" target="section-5.2.12"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-user-dis
play-name">USER-DISPLAY-NAME</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.13">
<t indent="0" pn="section-toc.1-1.5.2.2.2.13.1"><xref derive
dContent="5.2.13" format="counter" sectionFormat="of" target="section-5.2.13"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-user-uri
">USER-URI</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.14">
<t indent="0" pn="section-toc.1-1.5.2.2.2.14.1"><xref derive
dContent="5.2.14" format="counter" sectionFormat="of" target="section-5.2.14"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-benefici
ary-information">BENEFICIARY-INFORMATION</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.15">
<t indent="0" pn="section-toc.1-1.5.2.2.2.15.1"><xref derive
dContent="5.2.15" format="counter" sectionFormat="of" target="section-5.2.15"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-re
quest-information">FLOOR-REQUEST-INFORMATION</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.16">
<t indent="0" pn="section-toc.1-1.5.2.2.2.16.1"><xref derive
dContent="5.2.16" format="counter" sectionFormat="of" target="section-5.2.16"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-requeste
d-by-information">REQUESTED-BY-INFORMATION</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.17">
<t indent="0" pn="section-toc.1-1.5.2.2.2.17.1"><xref derive
dContent="5.2.17" format="counter" sectionFormat="of" target="section-5.2.17"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-re
quest-status">FLOOR-REQUEST-STATUS</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2.2.18">
<t indent="0" pn="section-toc.1-1.5.2.2.2.18.1"><xref derive
dContent="5.2.18" format="counter" sectionFormat="of" target="section-5.2.18"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-overall-
request-status">OVERALL-REQUEST-STATUS</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-message-format">Messag
e Format</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.5.2.3.2">
<li pn="section-toc.1-1.5.2.3.2.1">
<t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derived
Content="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-floorreque
st">FloorRequest</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.2">
<t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derived
Content="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-floorrelea
se">FloorRelease</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derived
Content="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-floorreque
stquery">FloorRequestQuery</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.4">
<t indent="0" pn="section-toc.1-1.5.2.3.2.4.1"><xref derived
Content="5.3.4" format="counter" sectionFormat="of" target="section-5.3.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-floorreque
ststatus">FloorRequestStatus</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.5">
<t indent="0" pn="section-toc.1-1.5.2.3.2.5.1"><xref derived
Content="5.3.5" format="counter" sectionFormat="of" target="section-5.3.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-userquery"
>UserQuery</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.6">
<t indent="0" pn="section-toc.1-1.5.2.3.2.6.1"><xref derived
Content="5.3.6" format="counter" sectionFormat="of" target="section-5.3.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-userstatus
">UserStatus</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.7">
<t indent="0" pn="section-toc.1-1.5.2.3.2.7.1"><xref derived
Content="5.3.7" format="counter" sectionFormat="of" target="section-5.3.7"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-floorquery
">FloorQuery</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.8">
<t indent="0" pn="section-toc.1-1.5.2.3.2.8.1"><xref derived
Content="5.3.8" format="counter" sectionFormat="of" target="section-5.3.8"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-floorstatu
s">FloorStatus</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.9">
<t indent="0" pn="section-toc.1-1.5.2.3.2.9.1"><xref derived
Content="5.3.9" format="counter" sectionFormat="of" target="section-5.3.9"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-chairactio
n">ChairAction</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.10">
<t indent="0" pn="section-toc.1-1.5.2.3.2.10.1"><xref derive
dContent="5.3.10" format="counter" sectionFormat="of" target="section-5.3.10"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-chairact
ionack">ChairActionAck</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.11">
<t indent="0" pn="section-toc.1-1.5.2.3.2.11.1"><xref derive
dContent="5.3.11" format="counter" sectionFormat="of" target="section-5.3.11"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-hello">H
ello</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.12">
<t indent="0" pn="section-toc.1-1.5.2.3.2.12.1"><xref derive
dContent="5.3.12" format="counter" sectionFormat="of" target="section-5.3.12"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-helloack
">HelloAck</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.13">
<t indent="0" pn="section-toc.1-1.5.2.3.2.13.1"><xref derive
dContent="5.3.13" format="counter" sectionFormat="of" target="section-5.3.13"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-error">E
rror</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.14">
<t indent="0" pn="section-toc.1-1.5.2.3.2.14.1"><xref derive
dContent="5.3.14" format="counter" sectionFormat="of" target="section-5.3.14"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-floorreq
ueststatusack">FloorRequestStatusAck</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.15">
<t indent="0" pn="section-toc.1-1.5.2.3.2.15.1"><xref derive
dContent="5.3.15" format="counter" sectionFormat="of" target="section-5.3.15"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-floorsta
tusack">FloorStatusAck</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.16">
<t indent="0" pn="section-toc.1-1.5.2.3.2.16.1"><xref derive
dContent="5.3.16" format="counter" sectionFormat="of" target="section-5.3.16"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-goodbye"
>Goodbye</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3.2.17">
<t indent="0" pn="section-toc.1-1.5.2.3.2.17.1"><xref derive
dContent="5.3.17" format="counter" sectionFormat="of" target="section-5.3.17"/>.
 <xref derivedContent="" format="title" sectionFormat="of" target="name-goodbyea
ck">GoodbyeAck</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-transport">Transport</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-reliable-transport">Re
liable Transport</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-unreliable-transport">
Unreliable Transport</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.6.2.2.2">
<li pn="section-toc.1-1.6.2.2.2.1">
<t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derived
Content="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-congestion
-control">Congestion Control</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.2.2.1"><xref derived
Content="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-icmp-error
-handling">ICMP Error Handling</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.3">
<t indent="0" pn="section-toc.1-1.6.2.2.2.3.1"><xref derived
Content="6.2.3" format="counter" sectionFormat="of" target="section-6.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-fragmentat
ion-handling">Fragmentation Handling</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2.2.4">
<t indent="0" pn="section-toc.1-1.6.2.2.2.4.1"><xref derived
Content="6.2.4" format="counter" sectionFormat="of" target="section-6.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-nat-traver
sal">NAT Traversal</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-lower-layer-security">Lower-Layer
Security</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-protocol-transactions">Protocol Tr
ansactions</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-client-behavior">Clien
t Behavior</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-server-behavior">Serve
r Behavior</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent=
"8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-timers">Timers</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.8.2.3.2">
<li pn="section-toc.1-1.8.2.3.2.1">
<t indent="0" pn="section-toc.1-1.8.2.3.2.1.1"><xref derived
Content="8.3.1" format="counter" sectionFormat="of" target="section-8.3.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-request-re
transmission-time">Request Retransmission Timer, T1</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3.2.2">
<t indent="0" pn="section-toc.1-1.8.2.3.2.2.1"><xref derived
Content="8.3.2" format="counter" sectionFormat="of" target="section-8.3.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-response-r
etransmission-tim">Response Retransmission Timer, T2</xref></t>
</li>
<li pn="section-toc.1-1.8.2.3.2.3">
<t indent="0" pn="section-toc.1-1.8.2.3.2.3.1"><xref derived
Content="8.3.3" format="counter" sectionFormat="of" target="section-8.3.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-timer-valu
es">Timer Values</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-authentication-and-authoriz">Authe
ntication and Authorization</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-tls-dtls-based-mutual-
authe">TLS/DTLS Based Mutual Authentication</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-floor-participant-operation">Flo
or Participant Operations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.10.2">
<li pn="section-toc.1-1.10.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent
="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-requesting-a-floor"
>Requesting a Floor</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.10.2.1.2">
<li pn="section-toc.1-1.10.2.1.2.1">
<t indent="0" pn="section-toc.1-1.10.2.1.2.1.1"><xref derive
dContent="10.1.1" format="counter" sectionFormat="of" target="section-10.1.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending
-a-floorrequest-mess">Sending a FloorRequest Message</xref></t>
</li>
<li pn="section-toc.1-1.10.2.1.2.2">
<t indent="0" pn="section-toc.1-1.10.2.1.2.2.1"><xref derive
dContent="10.1.2" format="counter" sectionFormat="of" target="section-10.1.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-receivi
ng-a-response">Receiving a Response</xref></t>
</li>
<li pn="section-toc.1-1.10.2.1.2.3">
<t indent="0" pn="section-toc.1-1.10.2.1.2.3.1"><xref derive
dContent="10.1.3" format="counter" sectionFormat="of" target="section-10.1.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-recepti
on-of-a-subsequent-f">Reception of a Subsequent FloorRequestStatus Message</xref
></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent
="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-cancelling-a-floor-
request-">Cancelling a Floor Request and Releasing a Floor</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.10.2.2.2">
<li pn="section-toc.1-1.10.2.2.2.1">
<t indent="0" pn="section-toc.1-1.10.2.2.2.1.1"><xref derive
dContent="10.2.1" format="counter" sectionFormat="of" target="section-10.2.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending
-a-floorrelease-mess">Sending a FloorRelease Message</xref></t>
</li>
<li pn="section-toc.1-1.10.2.2.2.2">
<t indent="0" pn="section-toc.1-1.10.2.2.2.2.1"><xref derive
dContent="10.2.2" format="counter" sectionFormat="of" target="section-10.2.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-receivi
ng-a-response-2">Receiving a Response</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-chair-operations">Chair Operatio
ns</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.11.2">
<li pn="section-toc.1-1.11.2.1">
<t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent
="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-sending-a-chairacti
on-messa">Sending a ChairAction Message</xref></t>
</li>
<li pn="section-toc.1-1.11.2.2">
<t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent
="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-receiving-a-respons
e-3">Receiving a Response</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-general-client-operations">Gener
al Client Operations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.12.2">
<li pn="section-toc.1-1.12.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent
="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-requesting-informat
ion-abou">Requesting Information about Floors</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.2.1.2">
<li pn="section-toc.1-1.12.2.1.2.1">
<t indent="0" pn="section-toc.1-1.12.2.1.2.1.1"><xref derive
dContent="12.1.1" format="counter" sectionFormat="of" target="section-12.1.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending
-a-floorquery-messag">Sending a FloorQuery Message</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.2">
<t indent="0" pn="section-toc.1-1.12.2.1.2.2.1"><xref derive
dContent="12.1.2" format="counter" sectionFormat="of" target="section-12.1.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-receivi
ng-a-response-4">Receiving a Response</xref></t>
</li>
<li pn="section-toc.1-1.12.2.1.2.3">
<t indent="0" pn="section-toc.1-1.12.2.1.2.3.1"><xref derive
dContent="12.1.3" format="counter" sectionFormat="of" target="section-12.1.3"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-recepti
on-of-a-subsequent-fl">Reception of a Subsequent FloorStatus Message</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent
="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-requesting-informat
ion-about">Requesting Information about Floor Requests</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.2.2.2">
<li pn="section-toc.1-1.12.2.2.2.1">
<t indent="0" pn="section-toc.1-1.12.2.2.2.1.1"><xref derive
dContent="12.2.1" format="counter" sectionFormat="of" target="section-12.2.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending
-a-floorrequestquery">Sending a FloorRequestQuery Message</xref></t>
</li>
<li pn="section-toc.1-1.12.2.2.2.2">
<t indent="0" pn="section-toc.1-1.12.2.2.2.2.1"><xref derive
dContent="12.2.2" format="counter" sectionFormat="of" target="section-12.2.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-receivi
ng-a-response-5">Receiving a Response</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12.2.3">
<t indent="0" pn="section-toc.1-1.12.2.3.1"><xref derivedContent
="12.3" format="counter" sectionFormat="of" target="section-12.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-requesting-informat
ion-about-">Requesting Information about a User</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.2.3.2">
<li pn="section-toc.1-1.12.2.3.2.1">
<t indent="0" pn="section-toc.1-1.12.2.3.2.1.1"><xref derive
dContent="12.3.1" format="counter" sectionFormat="of" target="section-12.3.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending
-a-userquery-message">Sending a UserQuery Message</xref></t>
</li>
<li pn="section-toc.1-1.12.2.3.2.2">
<t indent="0" pn="section-toc.1-1.12.2.3.2.2.1"><xref derive
dContent="12.3.2" format="counter" sectionFormat="of" target="section-12.3.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-receivi
ng-a-response-6">Receiving a Response</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.12.2.4">
<t indent="0" pn="section-toc.1-1.12.2.4.1"><xref derivedContent
="12.4" format="counter" sectionFormat="of" target="section-12.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-obtaining-the-capab
ilities-">Obtaining the Capabilities of a Floor Control Server</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.12.2.4.2">
<li pn="section-toc.1-1.12.2.4.2.1">
<t indent="0" pn="section-toc.1-1.12.2.4.2.1.1"><xref derive
dContent="12.4.1" format="counter" sectionFormat="of" target="section-12.4.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-sending
-a-hello-message">Sending a Hello Message</xref></t>
</li>
<li pn="section-toc.1-1.12.2.4.2.2">
<t indent="0" pn="section-toc.1-1.12.2.4.2.2.1"><xref derive
dContent="12.4.2" format="counter" sectionFormat="of" target="section-12.4.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-receivi
ng-responses">Receiving Responses</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-floor-control-server-operat">Flo
or Control Server Operations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.13.2">
<li pn="section-toc.1-1.13.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent
="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-reception-of-a-floo
rrequest">Reception of a FloorRequest Message</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.13.2.1.2">
<li pn="section-toc.1-1.13.2.1.2.1">
<t indent="0" pn="section-toc.1-1.13.2.1.2.1.1"><xref derive
dContent="13.1.1" format="counter" sectionFormat="of" target="section-13.1.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-generat
ing-the-first-floorr">Generating the First FloorRequestStatus Message</xref></t>
</li>
<li pn="section-toc.1-1.13.2.1.2.2">
<t indent="0" pn="section-toc.1-1.13.2.1.2.2.1"><xref derive
dContent="13.1.2" format="counter" sectionFormat="of" target="section-13.1.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-generat
ion-of-subsequent-fl">Generation of Subsequent FloorRequestStatus Messages</xref
></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13.2.2">
<t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent
="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-reception-of-a-floo
rrequestq">Reception of a FloorRequestQuery Message</xref></t>
</li>
<li pn="section-toc.1-1.13.2.3">
<t indent="0" pn="section-toc.1-1.13.2.3.1"><xref derivedContent
="13.3" format="counter" sectionFormat="of" target="section-13.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-reception-of-a-user
query-me">Reception of a UserQuery Message</xref></t>
</li>
<li pn="section-toc.1-1.13.2.4">
<t indent="0" pn="section-toc.1-1.13.2.4.1"><xref derivedContent
="13.4" format="counter" sectionFormat="of" target="section-13.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-reception-of-a-floo
rrelease">Reception of a FloorRelease Message</xref></t>
</li>
<li pn="section-toc.1-1.13.2.5">
<t indent="0" pn="section-toc.1-1.13.2.5.1"><xref derivedContent
="13.5" format="counter" sectionFormat="of" target="section-13.5"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-reception-of-a-floo
rquery-m">Reception of a FloorQuery Message</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.13.2.5.2">
<li pn="section-toc.1-1.13.2.5.2.1">
<t indent="0" pn="section-toc.1-1.13.2.5.2.1.1"><xref derive
dContent="13.5.1" format="counter" sectionFormat="of" target="section-13.5.1"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-generat
ion-of-the-first-flo">Generation of the First FloorStatus Message</xref></t>
</li>
<li pn="section-toc.1-1.13.2.5.2.2">
<t indent="0" pn="section-toc.1-1.13.2.5.2.2.1"><xref derive
dContent="13.5.2" format="counter" sectionFormat="of" target="section-13.5.2"/>.
  <xref derivedContent="" format="title" sectionFormat="of" target="name-generat
ion-of-subsequent-flo">Generation of Subsequent FloorStatus Messages</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.13.2.6">
<t indent="0" pn="section-toc.1-1.13.2.6.1"><xref derivedContent
="13.6" format="counter" sectionFormat="of" target="section-13.6"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-reception-of-a-chai
raction-">Reception of a ChairAction Message</xref></t>
</li>
<li pn="section-toc.1-1.13.2.7">
<t indent="0" pn="section-toc.1-1.13.2.7.1"><xref derivedContent
="13.7" format="counter" sectionFormat="of" target="section-13.7"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-reception-of-a-hell
o-messag">Reception of a Hello Message</xref></t>
</li>
<li pn="section-toc.1-1.13.2.8">
<t indent="0" pn="section-toc.1-1.13.2.8.1"><xref derivedContent
="13.8" format="counter" sectionFormat="of" target="section-13.8"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-error-message-gener
ation">Error Message Generation</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-security-considerations">Securit
y Considerations</xref></t>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
erations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.15.2">
<li pn="section-toc.1-1.15.2.1">
<t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent
="15.1" format="counter" sectionFormat="of" target="section-15.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-attributes-subregis
try">Attributes Subregistry</xref></t>
</li>
<li pn="section-toc.1-1.15.2.2">
<t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent
="15.2" format="counter" sectionFormat="of" target="section-15.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-primitives-subregis
try">Primitives Subregistry</xref></t>
</li>
<li pn="section-toc.1-1.15.2.3">
<t indent="0" pn="section-toc.1-1.15.2.3.1"><xref derivedContent
="15.3" format="counter" sectionFormat="of" target="section-15.3"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-request-statuses-su
bregistr">Request Statuses Subregistry</xref></t>
</li>
<li pn="section-toc.1-1.15.2.4">
<t indent="0" pn="section-toc.1-1.15.2.4.1"><xref derivedContent
="15.4" format="counter" sectionFormat="of" target="section-15.4"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-error-codes-subregi
stry">Error Codes Subregistry</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="16" fo
rmat="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-changes-from-rfc-4582">Changes f
rom RFC 4582</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.16.2">
<li pn="section-toc.1-1.16.2.1">
<t indent="0" pn="section-toc.1-1.16.2.1.1"><xref derivedContent
="16.1" format="counter" sectionFormat="of" target="section-16.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-extensions-for-an-u
nreliabl">Extensions for an Unreliable Transport</xref></t>
</li>
<li pn="section-toc.1-1.16.2.2">
<t indent="0" pn="section-toc.1-1.16.2.2.1"><xref derivedContent
="16.2" format="counter" sectionFormat="of" target="section-16.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-other-changes">Othe
r Changes</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.17">
<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="17" fo
rmat="counter" sectionFormat="of" target="section-17"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.17.2">
<li pn="section-toc.1-1.17.2.1">
<t indent="0" pn="section-toc.1-1.17.2.1.1"><xref derivedContent
="17.1" format="counter" sectionFormat="of" target="section-17.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.17.2.2">
<t indent="0" pn="section-toc.1-1.17.2.2.1"><xref derivedContent
="17.2" format="counter" sectionFormat="of" target="section-17.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.18">
<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-example-call-fl
ows-for-bfcp">Example Call Flows for BFCP over an Unreliable Transport</xref></t
>
</li>
<li pn="section-toc.1-1.19">
<t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="Append
ix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-motivation-for-
supporting-a">Motivation for Supporting an Unreliable Transport</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.19.2">
<li pn="section-toc.1-1.19.2.1">
<t indent="0" pn="section-toc.1-1.19.2.1.1"><xref derivedContent
="B.1" format="counter" sectionFormat="of" target="section-b.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-motivation">Motivatio
n</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.19.2.1.2">
<li pn="section-toc.1-1.19.2.1.2.1">
<t indent="0" pn="section-toc.1-1.19.2.1.2.1.1"><xref derive
dContent="B.1.1" format="counter" sectionFormat="of" target="section-b.1.1"/>.  
<xref derivedContent="" format="title" sectionFormat="of" target="name-alternati
ves-considered">Alternatives Considered</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn
="section-toc.1-1.19.2.1.2.1.2">
<li pn="section-toc.1-1.19.2.1.2.1.2.1">
<t indent="0" pn="section-toc.1-1.19.2.1.2.1.2.1.1"><xre
f derivedContent="B.1.1.1" format="counter" sectionFormat="of" target="section-b
.1.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="na
me-ice-tcp">ICE TCP</xref></t>
</li>
<li pn="section-toc.1-1.19.2.1.2.1.2.2">
<t indent="0" pn="section-toc.1-1.19.2.1.2.1.2.2.1"><xre
f derivedContent="B.1.1.2" format="counter" sectionFormat="of" target="section-b
.1.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="na
me-teredo">Teredo</xref></t>
</li>
<li pn="section-toc.1-1.19.2.1.2.1.2.3">
<t indent="0" pn="section-toc.1-1.19.2.1.2.1.2.3.1"><xre
f derivedContent="B.1.1.3" format="counter" sectionFormat="of" target="section-b
.1.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="na
me-gut">GUT</xref></t>
</li>
<li pn="section-toc.1-1.19.2.1.2.1.2.4">
<t indent="0" pn="section-toc.1-1.19.2.1.2.1.2.4.1"><xre
f derivedContent="B.1.1.4" format="counter" sectionFormat="of" target="section-b
.1.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="na
me-upnp-igd">UPnP IGD</xref></t>
</li>
<li pn="section-toc.1-1.19.2.1.2.1.2.5">
<t indent="0" pn="section-toc.1-1.19.2.1.2.1.2.5.1"><xre
f derivedContent="B.1.1.5" format="counter" sectionFormat="of" target="section-b
.1.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="na
me-nat-pmp">NAT PMP</xref></t>
</li>
<li pn="section-toc.1-1.19.2.1.2.1.2.6">
<t indent="0" pn="section-toc.1-1.19.2.1.2.1.2.6.1"><xre
f derivedContent="B.1.1.6" format="counter" sectionFormat="of" target="section-b
.1.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="na
me-sctp">SCTP</xref></t>
</li>
<li pn="section-toc.1-1.19.2.1.2.1.2.7">
<t indent="0" pn="section-toc.1-1.19.2.1.2.1.2.7.1"><xre
f derivedContent="B.1.1.7" format="counter" sectionFormat="of" target="section-b
.1.1.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="na
me-bfcp-over-udp-transport">BFCP over UDP Transport</xref></t>
</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.20">
<t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgeme
nts</xref></t>
</li>
<li pn="section-toc.1-1.21">
<t indent="0" pn="section-toc.1-1.21.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="sec_intro" numbered="true" toc="include" removeInRFC="false
" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">Within a conference, some applications need
to manage the access to a set of shared resources, such as the right to send me
dia to a particular media session. Floor control enables such applications to pr
ovide users with coordinated (shared or exclusive) access to these resources.</t
>
<t indent="0" pn="section-1-2">The Requirements for Floor Control Protocol
<xref target="RFC4376" format="default" sectionFormat="of" derivedContent="18"/
> list a set of requirements that need to be met by floor control protocols. The
Binary Floor Control Protocol (BFCP), which is specified in this document, meet
s these requirements.</t>
<t indent="0" pn="section-1-3">In addition, BFCP has been designed so that
it can be used in low-bandwidth environments. The binary encoding used by BFCP
achieves a small message size (when message signatures are not used) that keeps
the time it takes to transmit delay-sensitive BFCP messages to a minimum. Delay-
sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus,
and ChairAction. It is expected that future extensions to these messages will no
t increase the size of these messages in a significant way.</t>
<t indent="0" pn="section-1-4">The remainder of this document is organized
as follows: <xref target="sec_terminology" format="default" sectionFormat="of"
derivedContent="Section 2"/> defines the terminology used
throughout this document, <xref target="sec_scope" format="default" sectio
nFormat="of" derivedContent="Section 3"/>
discusses the scope of BFCP (i.e., which tasks fall within the scope of
BFCP and which ones are performed using different mechanisms), <xref targe
t="sec_overview" format="default" sectionFormat="of" derivedContent="Section 4"/
> provides a non-normative
overview of BFCP operation. The subsequent sections provide the
normative specification of BFCP. <xref target="sec_changes" format="defaul
t" sectionFormat="of" derivedContent="Section 16"/>
summarizes changes from <xref target="RFC4582" format="default" sectionFor
mat="of" derivedContent="3"> RFC 4582</xref>.</t>
</section>
<section anchor="sec_terminology" numbered="true" toc="include" removeInRFC=
"false" pn="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<t indent="0" pn="section-2-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="1"/> <xref target="RFC8174" format="default" sectionFormat="o
f" derivedContent="10"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<dl indent="3" newline="false" spacing="normal" pn="section-2-2">
<dt pn="section-2-2.1">Media Participant:</dt>
<dd pn="section-2-2.2">An entity that has access to the media resources
of a conference (e.g., it can receive a media stream). In floor-controlled confe
rences, a given media participant is typically co-located with a floor participa
nt, but it does not need to be. Third-party floor requests consist of having a f
loor participant request a floor for a media participant when they are not co-lo
cated. The protocol between a floor participant and a media participant (that ar
e not co-located) is outside the scope of this document.</dd>
<dt pn="section-2-2.3">Client:</dt>
<dd pn="section-2-2.4">A floor participant or a floor chair that communi
cates with a floor control server using BFCP.</dd>
<dt pn="section-2-2.5">Floor:</dt>
<dd pn="section-2-2.6">A temporary permission to access or manipulate a
specific shared resource or set of resources.</dd>
<dt pn="section-2-2.7">Floor Chair:</dt>
<dd pn="section-2-2.8">A logical entity that manages one floor (grants,
denies, or revokes a floor). An entity that assumes the logical role of a floor
chair for a given transaction may assume a different role (e.g., floor participa
nt) for a different transaction. The roles of floor chair and floor participant
are defined on a transaction-by-transaction basis. BFCP transactions are defined
in <xref target="sec_transactions" format="default" sectionFormat="of" derivedC
ontent="Section 8"/>.</dd>
<dt pn="section-2-2.9">Floor Control:</dt>
<dd pn="section-2-2.10">A mechanism that enables applications or users t
o gain safe and mutually exclusive or non-exclusive input access to the shared o
bject or resource.</dd>
<dt pn="section-2-2.11">Floor Control Server:</dt>
<dd pn="section-2-2.12">A logical entity that maintains the state of the
floor(s), including which floors exists, who the floor chairs are, who holds a
floor, etc. Requests to manipulate a floor are directed at the floor control se
rver. The floor control server of a conference may perform other logical roles (
e.g., floor participant) in another conference.</dd>
<dt pn="section-2-2.13">Floor Participant:</dt>
<dd pn="section-2-2.14">A logical entity that requests floors, and possi
bly information about them, from a floor control server. An entity that assumes
the logical role of a floor participant for a given transaction may assume a dif
ferent role (e.g., a floor chair) for a different transaction. The roles of floo
r participant and floor chair are defined on a transaction-by-transaction basis.
BFCP transactions are defined in <xref target="sec_transactions" format="defaul
t" sectionFormat="of" derivedContent="Section 8"/>. In floor-controlled conferen
ces, a given floor participant is typically co-located with a media participant,
but it does not need to be. Third-party floor requests consist of having a floo
r participant request a floor for a media participant when they are not co-locat
ed.</dd>
<dt pn="section-2-2.15">Participant:</dt>
<dd pn="section-2-2.16">An entity that acts as a floor participant, as a
media participant, or as both.</dd>
<dt pn="section-2-2.17">BFCP Connection:</dt>
<dd pn="section-2-2.18">A transport association between BFCP entities, u
sed to exchange BFCP messages.</dd>
<dt pn="section-2-2.19">Transaction Failure Window:</dt>
<dd pn="section-2-2.20">When communicating over an
unreliable transport, this is some period of time less than or equal to
T1*2<sup>4</sup> (see <xref target="timers" format="default" sectionFormat
="of" derivedContent="Section 8.3"/>). For
reliable transports, this period of time is unbounded.</dd>
</dl>
</section>
<section anchor="sec_scope" numbered="true" toc="include" removeInRFC="false
" pn="section-3">
<name slugifiedName="name-scope">Scope</name>
<t indent="0" pn="section-3-1">As stated earlier, BFCP is a protocol to co
ordinate access to shared resources in a conference following the requirements d
efined in <xref target="RFC4376" format="default" sectionFormat="of" derivedCont
ent="18"/>. Floor control complements other functions defined in the Centralize
d Conferencing (XCON) Framework <xref target="RFC5239" format="default" sectionF
ormat="of" derivedContent="19"/>. The floor control protocol BFCP defined in thi
s document only specifies a means to arbitrate access to floors. The rules and
constraints for floor arbitration and the results of floor assignments are outsi
de the scope of this document and are defined by other protocols <xref target="R
FC5239" format="default" sectionFormat="of" derivedContent="19"/>.</t>
<t indent="0" pn="section-3-2"><xref target="fig_arch" format="default" se
ctionFormat="of" derivedContent="Figure 1"/> shows the tasks that BFCP can perfo
rm.</t>
<figure anchor="fig_arch" align="left" suppress-title="false" pn="figure-1
">
<name slugifiedName="name-functionality-provided-by-b">Functionality pro
vided by BFCP</name>
<artwork name="" type="" align="left" alt="" pn="section-3-3.1">
+---------+ +---------+
| Floor | | Floor |
| Chair | | Chair |
| | | |
+---------+ +---------+
^ | ^ |
| | | |
Notification | | Decision Notification | | Decision
| | | |
| | | |
Floor | v Floor | v
+-------------+ Request +---------+ +-------------+ +-------------+ Request +---------+ +-------------+
| Floor |----------->| Floor | Notification | Floor | | Floor |-----------&gt;| Floor | Notification | Floor |
| Participant | | Control |------------->| Participant | | Participant | | Control |-------------&gt;| Participant |
| |<-----------| Server | | | | |&lt;-----------| Server | | |
+-------------+ Granted or +---------+ +-------------+ +-------------+ Granted or +---------+ +-------------+
Denied ]]></artwork> Denied </artwork>
</figure></t> </figure>
<t>BFCP provides a means:</t> <t indent="0" pn="section-3-4">BFCP provides a means:</t>
<t><list style="symbols"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-5
<t>for floor participants to send floor requests to floor control server ">
s.</t> <li pn="section-3-5.1">for floor participants to send floor requests to
<t>for floor control servers to grant or deny requests to access a given floor control servers.</li>
resource from floor participants.</t> <li pn="section-3-5.2">for floor control servers to grant or deny reques
<t>for floor chairs to send floor control servers decisions regarding fl ts to access a given resource from floor participants.</li>
oor requests.</t> <li pn="section-3-5.3">for floor chairs to send floor control servers de
<t>for floor control servers to keep floor participants and floor chairs cisions regarding floor requests.</li>
informed about the status of a given floor or a given floor request.</t> <li pn="section-3-5.4">for floor control servers to keep floor participa
</list></t> nts and floor chairs informed about the status of a given floor or a given floor
<t>Even though tasks that do not belong to the previous list are outside the request.</li>
scope of BFCP, some of these out-of-scope tasks relate to floor control and are </ul>
essential for creating floors and establishing BFCP connections between differe <t indent="0" pn="section-3-6">Even though tasks that do not belong to the
nt entities. In the following subsections, we discuss some of these tasks and me previous list are outside the scope of BFCP, some of these out-of-scope tasks r
chanisms to perform them.</t> elate to floor control and are essential for creating floors and establishing BF
CP connections between different entities. In the following subsections, we disc
<section title="Floor Creation" anchor="sec:scope:creation"> uss some of these tasks and mechanisms to perform them.</t>
<t>The association of a given floor with a resource or a set of resources <section anchor="sec_scope_creation" numbered="true" toc="include" removeI
(e.g., media streams) is out of the scope of BFCP as described in <xref target=" nRFC="false" pn="section-3.1">
RFC5239"/>. Floor creation and termination are also outside the scope of BFCP; t <name slugifiedName="name-floor-creation">Floor Creation</name>
hese aspects are handled using the conference control protocol for manipulating <t indent="0" pn="section-3.1-1">The association of a given floor with a
the conference object. Consequently, the floor control server needs to stay up t resource or a set of resources (e.g., media streams) is out of the scope of BFC
o date on changes to the conference object (e.g., when a new floor is created).< P as described in <xref target="RFC5239" format="default" sectionFormat="of" der
/t> ivedContent="19"/>. Floor creation and termination are also outside the scope of
<t>Conference control clients using CCMP <xref target="RFC6503"/> can spec BFCP; these aspects are handled using the conference control protocol for manip
ify such floor-related settings in the &lt;floor-information&gt; element <xref t ulating the conference object. Consequently, the floor control server needs to s
arget="RFC6501"/> of the to-be created conference object provided in the body of tay up to date on changes to the conference object (e.g., when a new floor is cr
a CCMP confRequest/create message issued to the conference control server.</t> eated).</t>
</section> <t indent="0" pn="section-3.1-2">Conference control clients using Centra
lized Conferencing Manipulation Protocol (CCMP) <xref target="RFC6503" format="d
<section title="Obtaining Information to Contact a Floor Control Server" anc efault" sectionFormat="of" derivedContent="23"/> can specify such floor-related
hor="sec:scope:info"> settings in the &lt;floor-information&gt; element <xref target="RFC6501" format=
<t>A client needs a set of data in order to establish a BFCP connection to "default" sectionFormat="of" derivedContent="22"/> of the to-be created conferen
a floor control server. This data includes the transport address of the server, ce object provided in the body of a CCMP confRequest/create message issued to th
the conference identifier, and a user identifier.</t> e conference control server.</t>
<t>Clients can obtain this information in different ways. One is to use an </section>
SDP offer/answer <xref target="RFC3264"/> exchange, which is described in <xref <section anchor="sec_scope_info" numbered="true" toc="include" removeInRFC
target="I-D.ietf-bfcpbis-rfc4583bis"/>. How to establish a connection to a BFCP ="false" pn="section-3.2">
floor control server outside the context of an offer/answer exchange when using <name slugifiedName="name-obtaining-information-to-co">Obtaining Informa
a reliable transport is described in <xref target="RFC5018"/>. Other mechanisms tion to Contact a Floor Control Server</name>
are described in the XCON framework <xref target="RFC5239"/> (and other related <t indent="0" pn="section-3.2-1">A client needs a set of data in order t
documents). For unreliable transports, the use of an SDP offer/answer exchange o establish a BFCP connection to a floor control server. These data include the
is the only specified mechanism.</t> transport address of the server, the conference identifier, and a user identifie
</section> r.</t>
<t indent="0" pn="section-3.2-2">Clients can obtain this information in
<section title="Obtaining Floor-Resource Associations" anchor="sec:scope:ass different ways. One is to use a Session Description Protocol (SDP) offer/answer
ociations"> <xref target="RFC3264" format="default" sectionFormat="of" derivedContent="17"/>
<t>Floors are associated with resources. For example, a floor that control exchange, which is described in <xref target="RFC8856" format="default" section
s who talks at a given time has a particular audio session as its associated res Format="of" derivedContent="12"/>. How to establish a connection to a BFCP floor
ource. Associations between floors and resources are part of the conference obje control server is outside the context of an offer/answer exchange when using a
ct.</t> reliable transport is described in <xref target="RFC5018" format="default" secti
<t>Floor participants and floor chairs need to know which resources are as onFormat="of" derivedContent="4"/>. Other mechanisms are described in the XCON F
sociated with which floors. They can obtain this information by using different ramework <xref target="RFC5239" format="default" sectionFormat="of" derivedConte
mechanisms, such as an SDP offer/answer <xref target="RFC3264"/> exchange. How t nt="19"/> (and other related documents). For unreliable transports, the use of a
o use an SDP offer/answer exchange to obtain these associations is described in n SDP offer/answer exchange is the only specified mechanism.</t>
<xref target="I-D.ietf-bfcpbis-rfc4583bis"/>.</t> </section>
<t><list style="hanging"> <section anchor="sec_scope_associations" numbered="true" toc="include" rem
<t>Note that floor participants perform SDP offer/answer exchanges wit oveInRFC="false" pn="section-3.3">
h the conference focus of the conference. So, the conference focus needs to obta <name slugifiedName="name-obtaining-floor-resource-as">Obtaining Floor-R
in information about associations between floors and resources in order to be ab esource Associations</name>
le to provide this information to a floor participant in an SDP offer/answer exc <t indent="0" pn="section-3.3-1">Floors are associated with resources. F
hange.</t> or example, a floor that controls who talks at a given time has a particular aud
</list></t> io session as its associated resource. Associations between floors and resources
<t>Other mechanisms for obtaining this information, including discussion o are part of the conference object.</t>
f how the information is made available to a (SIP) Focus, are described in the X <t indent="0" pn="section-3.3-2">Floor participants and floor chairs nee
CON framework <xref target="RFC5239"/> (and other related documents). According d to know which resources are associated with which floors. They can obtain this
to the conferencing system policies, conference control clients using CCMP <xref information by using different mechanisms, such as an SDP offer/answer <xref ta
target="RFC6503"/> can modify the floor settings of a conference by issuing CCM rget="RFC3264" format="default" sectionFormat="of" derivedContent="17"/> exchang
P confRequest/update messages providing the specific updates to the &lt;floor-in e. How to use an SDP offer/answer exchange to obtain these associations is descr
formation&gt; element of the target conference object. More information about CC ibed in <xref target="RFC8856" format="default" sectionFormat="of" derivedConten
MP and BFCP interaction can be found in <xref target="RFC6504"/>.</t> t="12"/>.</t>
</section> <aside pn="section-3.3-3">
<t indent="0" pn="section-3.3-3.1">Note that floor participants perfor
<section title="Privileges of Floor Control" anchor="sec:scope:policy"> m SDP offer/answer exchanges with the conference focus of the conference. So, th
<t>A participant whose floor request is granted has the right to use the r e conference focus needs to obtain information about associations between floors
esource or resources associated with the floor that was requested. For example, and resources in order to be able to provide this information to a floor partic
the participant may have the right to send media over a particular audio stream. ipant in an SDP offer/answer exchange.</t>
</t> </aside>
<t>Nevertheless, holding a floor does not imply that others will not be ab <t indent="0" pn="section-3.3-4">Other mechanisms for obtaining this inf
le to use its associated resources at the same time, even if they do not have th ormation, including discussion of how the information is made available to a (SI
e right to do so. Determination of which media participants can actually use the P) focus, are described in the XCON Framework <xref target="RFC5239" format="def
resources in the conference is discussed in the XCON Framework <xref target="RF ault" sectionFormat="of" derivedContent="19"/> (and other related documents). Ac
C5239"/>.</t> cording to the conferencing system policies, conference control clients using CC
MP <xref target="RFC6503" format="default" sectionFormat="of" derivedContent="23
"/> can modify the floor settings of a conference by issuing CCMP confRequest/up
date messages providing the specific updates to the &lt;floor-information&gt; el
ement of the target conference object. More information about CCMP and BFCP inte
raction can be found in <xref target="RFC6504" format="default" sectionFormat="o
f" derivedContent="24"/>.</t>
</section>
<section anchor="sec_scope_policy" numbered="true" toc="include" removeInR
FC="false" pn="section-3.4">
<name slugifiedName="name-privileges-of-floor-control">Privileges of Flo
or Control</name>
<t indent="0" pn="section-3.4-1">A participant whose floor request is gr
anted has the right to use the resource or resources associated with the floor t
hat was requested. For example, the participant may have the right to send media
over a particular audio stream.</t>
<t indent="0" pn="section-3.4-2">Nevertheless, holding a floor does not
imply that others will not be able to use its associated resources at the same t
ime, even if they do not have the right to do so. Determination of which media p
articipants can actually use the resources in the conference is discussed in the
XCON Framework <xref target="RFC5239" format="default" sectionFormat="of" deriv
edContent="19"/>.</t>
</section>
</section> </section>
</section> <section anchor="sec_overview" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-4">
<section title="Overview of Operation" anchor="sec:overview"> <name slugifiedName="name-overview-of-operation">Overview of Operation</na
<t>This section provides a non-normative description of BFCP operations. <xr me>
ef target="sec:overview:user"/> describes the interface between floor participan <t indent="0" pn="section-4-1">This section provides a non-normative descr
ts and floor control servers, and <xref target="sec:overview:chair"/> describes iption of BFCP operations. <xref target="sec_overview_user" format="default" sec
the interface between floor chairs and floor control servers.</t> tionFormat="of" derivedContent="Section 4.1"/> describes the interface between f
<t>BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consi loor participants and floor control servers, and <xref target="sec_overview_chai
st of a common header followed by a set of attributes. The common header contain r" format="default" sectionFormat="of" derivedContent="Section 4.2"/> describes
s, among other information, a 32-bit conference identifier. Floor participants, the interface between floor chairs and floor control servers.</t>
media participants, and floor chairs are identified by 16-bit user identifiers.< <t indent="0" pn="section-4-2">BFCP messages, which use a TLV (Type-Length
/t> -Value) binary encoding, consist of a COMMON-HEADER followed by a set of attribu
<t>BFCP supports nested attributes (i.e., attributes that contain attributes tes. The COMMON-HEADER contains, among other information, a 32-bit conference id
). These are referred to as grouped attributes.</t> entifier. Floor participants, media participants, and floor chairs are identifie
<t>There are two types of transactions in BFCP: client-initiated transaction d by 16-bit user identifiers.</t>
s and server-initiated transactions. <xref target="sec:transactions"/> describes <t indent="0" pn="section-4-3">BFCP supports nested attributes (i.e., attr
both types of transactions in detail.</t> ibutes that contain attributes). These are referred to as grouped attributes.</t
>
<section title="Floor Participant to Floor Control Server Interface" anchor= <t indent="0" pn="section-4-4">There are two types of transactions in BFCP
"sec:overview:user"> : client-initiated transactions and server-initiated transactions. <xref target=
<t>Floor participants request a floor by sending a FloorRequest message to "sec_transactions" format="default" sectionFormat="of" derivedContent="Section 8
the floor control server. BFCP supports third-party floor requests. That is, th "/> describes both types of transactions in detail.</t>
e floor participant sending the floor request need not be colocated with the med <section anchor="sec_overview_user" numbered="true" toc="include" removeIn
ia participant that will get the floor once the floor request is granted. FloorR RFC="false" pn="section-4.1">
equest messages carry the identity of the requester in the User ID field of the <name slugifiedName="name-floor-participant-to-floor-">Floor Participant
common header, and the identity of the beneficiary of the floor (in third-party to Floor Control Server Interface</name>
floor requests) in a BENEFICIARY-ID attribute.</t> <t indent="0" pn="section-4.1-1">Floor participants request a floor by s
<t><list style="hanging"> ending a FloorRequest message to the floor control server. BFCP supports third-p
<t>Third-party floor requests can be sent, for example, by floor parti arty floor requests. That is, the floor participant sending the floor request ne
cipants that have a BFCP connection to the floor control server but that are not ed not be co-located with the media participant that will get the floor once the
media participants (i.e., they do not handle any media).</t> floor request is granted. FloorRequest messages carry the identity of the reque
</list></t> ster in the User ID field of the COMMON-HEADER, and the identity of the benefici
<t>FloorRequest messages identify the floor or floors being requested by c ary of the floor (in third-party floor requests) in a BENEFICIARY-ID attribute.<
arrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest /t>
message carries more than one floor identifier, the floor control server treats <aside pn="section-4.1-2">
all the floor requests as an atomic package. That is, the floor control server <t indent="0" pn="section-4.1-2.1">Third-party floor requests can be s
either grants or denies all the floors in the FloorRequest message.</t> ent, for example, by floor participants that have a BFCP connection to the floor
<t>Floor control servers respond to FloorRequest messages with FloorReques control server but that are not media participants (i.e., they do not handle an
tStatus messages, which provide information about the status of the floor reques y media).</t>
t. The first FloorRequestStatus message is the response to the FloorRequest mess </aside>
age from the client, and therefore has the same Transaction ID as the FloorReque <t indent="0" pn="section-4.1-3">FloorRequest messages identify the floo
st.</t> r or floors being requested by carrying their 16-bit floor identifiers in FLOOR-
<t>Additionally, the first FloorRequestStatus message carries the Floor Re ID attributes. If a FloorRequest message carries more than one floor identifier,
quest ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus the floor control server treats all the floor requests as an atomic package. Th
messages related to the same floor request will carry the same Floor Request ID at is, the floor control server either grants or denies all the floors in the Fl
. This way, the floor participant can associate them with the appropriate floor oorRequest message.</t>
request.</t> <t indent="0" pn="section-4.1-4">Floor control servers respond to FloorR
<t>Messages from the floor participant related to a particular floor reque equest messages with FloorRequestStatus messages, which provide information abou
st also use the same Floor Request ID as the first FloorRequestStatus Message fr t the status of the floor request. The first FloorRequestStatus message is the r
om the floor control server.</t> esponse to the FloorRequest message from the client, and therefore has the same
<t>Figures 2 and 3 below show examples of call flows where BFCP is used ov Transaction ID as the FloorRequest.</t>
er a reliable transport. <xref target="app:unrelcallflow"/> shows the same call <t indent="0" pn="section-4.1-5">Additionally, the first FloorRequestSta
flow examples using an unreliable transport.</t> tus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribut
<t><xref target="fig:flow1"/> shows how a floor participant requests a flo e. Subsequent FloorRequestStatus messages related to the same floor request will
or, obtains it, and, at a later time, releases it. This figure illustrates the u carry the same Floor Request ID. This way, the floor participant can associate
se, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute them with the appropriate floor request.</t>
.</t> <t indent="0" pn="section-4.1-6">Messages from the floor participant rel
<t><figure anchor="fig:flow1" title="Requesting and releasing a floor"> ated to a particular floor request also use the same Floor Request ID as the fir
<artwork> st FloorRequestStatus message from the floor control server.</t>
<![CDATA[ <t indent="0" pn="section-4.1-7"><xref target="fig_flow1" format="defaul
t" sectionFormat="of" derivedContent="Figure 2"/> and <xref target="fig_flow2" f
ormat="default" sectionFormat="of" derivedContent="Figure 3"/> show examples of
call flows where BFCP is used over a reliable transport. <xref target="app_unrel
callflow" format="default" sectionFormat="of" derivedContent="Appendix A"/> show
s the same call flow examples using an unreliable transport.</t>
<t indent="0" pn="section-4.1-8"><xref target="fig_flow1" format="defaul
t" sectionFormat="of" derivedContent="Figure 2"/> shows how a floor participant
requests a floor, obtains it, and, at a later time, releases it. This figure ill
ustrates the use, among other things, of the Transaction ID and the FLOOR-REQUES
T-ID attribute.</t>
<figure anchor="fig_flow1" align="left" suppress-title="false" pn="figur
e-2">
<name slugifiedName="name-requesting-and-releasing-a-">Requesting and
releasing a floor</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1-9.1">
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 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(2) FloorRequestStatus | |(2) FloorRequestStatus |
|Transaction ID: 123 | |Transaction ID: 123 |
|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: Pending | | Request Status: Pending |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(3) FloorRequestStatus | |(3) FloorRequestStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|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: Accepted | | Request Status: Accepted |
| Queue Position: 1st | | Queue Position: 1st |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(4) FloorRequestStatus | |(4) FloorRequestStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|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: Granted | | Request Status: Granted |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(5) FloorRelease | |(5) FloorRelease |
|Transaction ID: 154 | |Transaction ID: 154 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(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 |
|<----------------------------------------------| ]]> |&lt;----------------------------------------------|</artwork>
</artwork> </figure>
</figure></t> <t indent="0" pn="section-4.1-10"><xref target="fig_flow2" format="defau
<t><xref target="fig:flow2"/> shows how a floor participant requests to be lt" sectionFormat="of" derivedContent="Figure 3"/> shows how a floor participant
informed on the status of a floor. The first FloorStatus message from the floor requests to be informed on the status of a floor. The first FloorStatus message
control server is the response to the FloorQuery message and, as such, has the from the floor control server is the response to the FloorQuery message and, as
same Transaction ID as the FloorQuery message.</t> such, has the same Transaction ID as the FloorQuery message.</t>
<t>Subsequent FloorStatus messages consist of server-initiated transaction <t indent="0" pn="section-4.1-11">Subsequent FloorStatus messages consis
s, and therefore their Transaction ID is 0 given this example uses a reliable tr t of server-initiated transactions, and therefore their Transaction ID is 0 give
ansport. FloorStatus message (2) indicates that there are currently two floor re n this example uses a reliable transport. FloorStatus message (2) indicates that
quests for the floor whose Floor ID is 543. FloorStatus message (3) indicates th there are currently two floor requests for the floor whose Floor ID is 543. Flo
at the floor requests with Floor Request ID 764 has been granted, and the floor orStatus message (3) indicates that the floor requests with Floor Request ID 764
request with Floor Request ID 635 is the first in the queue. FloorStatus message has been granted, and the floor request with Floor Request ID 635 is the first
(4) indicates that the floor request with Floor Request ID 635 has been granted in the queue. FloorStatus message (4) indicates that the floor request with Floo
.</t> r Request ID 635 has been granted.</t>
<t><figure anchor="fig:flow2" title="Obtaining status information about a <figure anchor="fig_flow2" align="left" suppress-title="false" pn="figur
floor"> e-3">
<artwork> <name slugifiedName="name-obtaining-status-informatio">Obtaining statu
<![CDATA[ s information about a floor</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1-12.1">
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 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(2) FloorStatus | |(2) FloorStatus |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 | | Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 1st | | Queue Position: 1st |
skipping to change at line 304 skipping to change at line 798
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 2nd | | Queue Position: 2nd |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(3) FloorStatus | |(3) FloorStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 | | Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Granted | | Request Status: Granted |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
skipping to change at line 327 skipping to change at line 821
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 1st | | Queue Position: 1st |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(4) FloorStatus | |(4) FloorStatus |
|Transaction ID: 0 | |Transaction ID: 0 |
|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 |
|<----------------------------------------------| ]]> |&lt;----------------------------------------------|</artwork>
</artwork> </figure>
</figure></t> <t indent="0" pn="section-4.1-13">FloorStatus messages contain informati
<t>FloorStatus messages contain information about the floor requests they on about the floor requests
carry. For example, FloorStatus message (4) indicates that the floor request wit they carry. For example, FloorStatus message (4) indicates that the
h Floor Request ID 635 has as the beneficiary (i.e., the participant that holds floor request with Floor Request ID 635 has as the beneficiary (i.e.,
the floor when a particular floor request is granted) the participant whose User the participant that holds the floor when a particular floor request is
ID is 154. The floor request applies only to the floor whose Floor ID is 543. T granted) the participant whose User ID is 154. The floor request applies
hat is, this is not a multi-floor floor request.</t> only to the floor whose Floor ID is 543. That is, this is not a
<t><list style="hanging"> multi-floor floor request.</t>
<t>A multi-floor floor request applies to more than one floor (e.g., a <aside pn="section-4.1-14">
participant wants to be able to speak and write on the whiteboard at the same t <t indent="0" pn="section-4.1-14.1">A multi-floor floor request applie
ime). The floor control server treats a multi-floor floor request as an atomic p s to more than one floor (e.g., a participant wants to be able to speak and writ
ackage. That is, the floor control server either grants the request for all floo e on the whiteboard at the same time). The floor control server treats a multi-f
rs or denies the request for all floors.</t> loor floor request as an atomic package. That is, the floor control server eithe
</list></t> r grants the request for all floors or denies the request for all floors.</t>
</section> </aside>
</section>
<section title="Floor Chair to Floor Control Server Interface" anchor="sec:o <section anchor="sec_overview_chair" numbered="true" toc="include" removeI
verview:chair"> nRFC="false" pn="section-4.2">
<t><xref target="fig:flow3"/> shows a floor chair instructing a floor cont <name slugifiedName="name-floor-chair-to-floor-contro">Floor Chair to Fl
rol server to grant a floor.</t> oor Control Server Interface</name>
<t><list style="empty"> <t indent="0" pn="section-4.2-1"><xref target="fig_flow3" format="defaul
<t>Note, however, that although the floor control server needs to take t" sectionFormat="of" derivedContent="Figure 4"/> shows a floor chair instructin
into consideration the instructions received in ChairAction messages (e.g., gra g a floor control server to grant a floor.</t>
nting a floor), it does not necessarily need to perform them exactly as requeste <aside pn="section-4.2-2">
d by the floor chair. The operation that the floor control server performs depen <t indent="0" pn="section-4.2-2.1">Note, however, that although the fl
ds on the ChairAction message and on the internal state of the floor control ser oor control server needs to take into consideration the instructions received in
ver.</t> ChairAction messages (e.g., granting a floor), it does not necessarily need to
</list></t> perform them exactly as requested by the floor chair. The operation that the flo
<t>For example, a floor chair may send a ChairAction message granting a fl or control server performs depends on the ChairAction message and on the interna
oor that was requested as part of an atomic floor request operation that involve l state of the floor control server.</t>
d several floors. Even if the chair responsible for one of the floors instructs </aside>
the floor control server to grant the floor, the floor control server will not g <t indent="0" pn="section-4.2-3">For example, a floor chair may send a C
rant it until the chairs responsible for the other floors agree to grant them as hairAction message granting a floor that was requested as part of an atomic floo
well. In another example, a floor chair may instruct the floor control server t r request operation that involved several floors. Even if the chair responsible
o grant a floor to a participant. The floor control server needs to revoke the f for one of the floors instructs the floor control server to grant the floor, the
loor from its current holder before granting it to the new participant.</t> floor control server will not grant it until the chairs responsible for the oth
<t>So, the floor control server is ultimately responsible for keeping a co er floors agree to grant them as well. In another example, a floor chair may ins
herent floor state using instructions from floor chairs as input to this state.< truct the floor control server to grant a floor to a participant. The floor cont
/t> rol server needs to revoke the floor from its current holder before granting it
<t><figure anchor="fig:flow3" title="Chair instructing the floor control s to the new participant.</t>
erver"> <t indent="0" pn="section-4.2-4">So, the floor control server is ultimat
<artwork> ely responsible for keeping a coherent floor state using instructions from floor
<![CDATA[ chairs as input to this state.</t>
<figure anchor="fig_flow3" align="left" suppress-title="false" pn="figur
e-4">
<name slugifiedName="name-chair-instructing-the-floor">Chair instructi
ng the floor control server</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-5.1">
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 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(2) ChairActionAck | |(2) ChairActionAck |
|Transaction ID: 769 | |Transaction ID: 769 |
|User ID: 357 | |User ID: 357 |
|<----------------------------------------------| ]]> |&lt;----------------------------------------------|</artwork>
</artwork> </figure>
</figure></t> </section>
</section> </section>
</section> <section anchor="sec_format" numbered="true" toc="include" removeInRFC="fals
e" pn="section-5">
<section title="Packet Format" anchor="sec:format"> <name slugifiedName="name-packet-format">Packet Format</name>
<t>BFCP packets consist of a 12-octet common header followed by attributes. <t indent="0" pn="section-5-1">BFCP packets consist of a 12-octet COMMON-H
All the protocol values MUST be sent in network byte order.</t> EADER followed by attributes. All the protocol values <bcp14>MUST</bcp14> be sen
t in network byte order.</t>
<section title="COMMON-HEADER Format" anchor="sec:format:common"> <section anchor="sec_format_common" numbered="true" toc="include" removeIn
<t>The following is the format of the common header.</t> RFC="false" pn="section-5.1">
<t><figure title="COMMON-HEADER format" anchor="fig:common"> <name slugifiedName="name-common-header-format">COMMON-HEADER Format</na
<artwork><![CDATA[ me>
<t indent="0" pn="section-5.1-1">The following is the format of the COMM
ON-HEADER.</t>
<figure anchor="fig_common" align="left" suppress-title="false" pn="figu
re-5">
<name slugifiedName="name-common-header-format-2">COMMON-HEADER format
</name>
<artwork name="" type="" align="left" alt="" pn="section-5.1-2.1">
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 |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Fragment Offset (if F is set) | Fragment Length (if F is set) | | | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +&gt; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+---- 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 indent="3" newline="false" spacing="normal" pn="section-5.1-3">
<t>Ver: This 3-bit field defines the version of BFCP that this message adh <dt pn="section-5.1-3.1">Ver:</dt>
eres to. This specification defines two versions: 1 and 2. The version field MUS <dd pn="section-5.1-3.2">This 3-bit field defines the version of BFCP
T be set to 1 when using BFCP over a reliable transport. The version field MUST to which this message adheres. This specification defines two versions: 1 and 2.
be set to 2 when using BFCP over an unreliable transport. If a floor control se The version field <bcp14>MUST</bcp14> be set to 1 when using BFCP over a reliab
rver receives a message with an unsupported version field value or a message wit le transport. The version field <bcp14>MUST</bcp14> be set to 2 when using BFCP
h a version number that is not permitted with the transport over which it was re over an unreliable transport. If a floor control server receives a message with
ceived, the server MUST indicate it does not support the protocol version by sen an unsupported version field value or a message with a version number that is n
ding an Error message with parameter value 12 (Unsupported Version). Note that ot permitted with the transport over which it was received, the server <bcp14>MU
BFCP entities supporting only the <xref target="RFC4582"/> subset will not suppo ST</bcp14> indicate it does not support the protocol version by sending an Error
rt this parameter value.</t> message with parameter value 12 (Unsupported Version). Note that BFCP entities
<t>R: The Transaction Responder (R) flag-bit has relevance only for use of supporting only the <xref target="RFC4582" format="default" sectionFormat="of"
BFCP over an unreliable transport. When cleared, it indicates that this message derivedContent="3"/> subset will not support this parameter value.</dd>
is a request initiating a new transaction, and the Transaction ID that follows <dt pn="section-5.1-3.3">R:</dt>
has been generated for this transaction. When set, it indicates that this messag <dd pn="section-5.1-3.4">The Transaction Responder (R) flag bit has re
e is a response to a previous request, and the Transaction ID that follows is th levance only for use of BFCP over an unreliable transport. When cleared, it indi
e one associated with that request. When BFCP is used over a reliable transport, cates that this message is a request initiating a new transaction, and the Trans
the flag has no significance and MUST be cleared by the sender and MUST be igno action ID that follows has been generated for this transaction. When set, it ind
red by the receiver.</t> icates that this message is a response to a previous request, and the Transactio
<t>F: The Fragmentation (F) flag-bit has relevance only for use of BFCP ov n ID that follows is the one associated with that request. When BFCP is used ove
er an unreliable transport. When cleared, the message is not fragmented. When se r a reliable transport, the flag has no significance and <bcp14>MUST</bcp14> be
t, it indicates that the message is a fragment of a large fragmented BFCP messag cleared by the sender and <bcp14>MUST</bcp14> be ignored by the receiver.</dd>
e. (The optional fields Fragment Offset and Fragment Length described below are <dt pn="section-5.1-3.5">F:</dt>
present only if the F flag is set). When BFCP is used over a reliable transport, <dd pn="section-5.1-3.6">The Fragmentation (F) flag bit has relevance
the flag has no significance and MUST be cleared by the sender and the flag MUS only for use of BFCP over an unreliable transport. When cleared, the message is
T be ignored by the receiver. In the latter case, the receiver should also proce not fragmented. When set, it indicates that the message is a fragment of a large
ss the COMMON-HEADER as not having the Fragment Offset and Fragment Length field , fragmented BFCP message. (The optional fields Fragment Offset and Fragment Len
s present.</t> gth described below are present only if the F flag is set). When BFCP is used o
<t>Res: The 3 bits in the reserved field MUST be set to zero by the sender ver a reliable transport, the flag has no significance and <bcp14>MUST</bcp14> b
of the message and MUST be ignored by the receiver.</t> e cleared by the sender, and the flag <bcp14>MUST</bcp14> be ignored by the rece
<t>Primitive: This 8-bit field identifies the main purpose of the message. iver. In the latter case, the receiver should also ignore the Fragment Offset an
The following primitive values are defined:</t> d Fragment Length fields when processing the COMMON-HEADER.
<texttable title="BFCP primitives" anchor="tab:primitives"> </dd>
<ttcol align="center">Value</ttcol> <dt pn="section-5.1-3.7">Res:</dt>
<ttcol>Primitive</ttcol> <dd pn="section-5.1-3.8">The 3 bits in the reserved field <bcp14>MUST<
<ttcol>Direction</ttcol> /bcp14> be set to zero by the sender of the message and <bcp14>MUST</bcp14> be i
<c>1</c> <c>FloorRequest</c> <c><![CDATA[P -> S]]></c> gnored by the receiver.</dd>
<c>2</c> <c>FloorRelease</c> <c><![CDATA[P -> S]]></c> <dt pn="section-5.1-3.9">Primitive:</dt>
<c>3</c> <c>FloorRequestQuery</c> <c><![CDATA[P -> S ; Ch -> S <dd pn="section-5.1-3.10">This 8-bit field identifies the main purpose
]]></c> of the
<c>4</c> <c>FloorRequestStatus</c> <c><![CDATA[P <- S ; Ch <- S message. The following primitive values are defined:</dd>
]]></c> </dl>
<c>5</c> <c>UserQuery</c> <c><![CDATA[P -> S ; Ch -> S <table anchor="tab_primitives" align="center" pn="table-1">
]]></c> <name slugifiedName="name-bfcp-primitives">BFCP primitives</name>
<c>6</c> <c>UserStatus</c> <c><![CDATA[P <- S ; Ch <- S <thead>
]]></c> <tr>
<c>7</c> <c>FloorQuery</c> <c><![CDATA[P -> S ; Ch -> S <th align="center" colspan="1" rowspan="1">Value</th>
]]></c> <th align="left" colspan="1" rowspan="1">Primitive</th>
<c>8</c> <c>FloorStatus</c> <c><![CDATA[P <- S ; Ch <- S <th align="left" colspan="1" rowspan="1">Direction</th>
]]></c> </tr>
<c>9</c> <c>ChairAction</c> <c><![CDATA[ Ch -> S </thead>
]]></c> <tbody>
<c>10</c> <c>ChairActionAck</c> <c><![CDATA[ Ch <- S <tr>
]]></c> <td align="center" colspan="1" rowspan="1">1</td>
<c>11</c> <c>Hello</c> <c><![CDATA[P -> S ; Ch -> S <td align="left" colspan="1" rowspan="1">FloorRequest</td>
]]></c> <td align="left" colspan="1" rowspan="1">P -&gt; S</td>
<c>12</c> <c>HelloAck</c> <c><![CDATA[P <- S ; Ch <- S </tr>
]]></c> <tr>
<c>13</c> <c>Error</c> <c><![CDATA[P <- S ; Ch <- S <td align="center" colspan="1" rowspan="1">2</td>
]]></c> <td align="left" colspan="1" rowspan="1">FloorRelease</td>
<c>14</c> <c>FloorRequestStatusAck</c> <c><![CDATA[P -> S ; Ch -> S <td align="left" colspan="1" rowspan="1">P -&gt; S</td>
]]></c> </tr>
<c>15</c> <c>FloorStatusAck</c> <c><![CDATA[P -> S ; Ch -> S] <tr>
]></c> <td align="center" colspan="1" rowspan="1">3</td>
<c>16</c> <c>Goodbye</c> <c><![CDATA[P -> S ; Ch -> S <td align="left" colspan="1" rowspan="1">FloorRequestQuery</td>
; ]]></c> <td align="left" colspan="1" rowspan="1">P -&gt; S ; Ch -&gt;
<c> </c> <c></c> <c><![CDATA[P <- S ; Ch <- S S</td>
]]></c> </tr>
<c>17</c> <c>GoodbyeAck</c> <c><![CDATA[P -> S ; Ch -> S <tr>
; ]]></c> <td align="center" colspan="1" rowspan="1">4</td>
<c> </c> <c></c> <c><![CDATA[P <- S ; Ch <- S <td align="left" colspan="1" rowspan="1">FloorRequestStatus</td>
]]></c> <td align="left" colspan="1" rowspan="1">P &lt;- S ; Ch &lt;-
<postamble> S</td>
S: Floor Control Server / P: Floor Participant / Ch: Floor Chair </tr>
</postamble> <tr>
</texttable> <td align="center" colspan="1" rowspan="1">5</td>
<t>Payload Length: This 16-bit field contains the length of the message in <td align="left" colspan="1" rowspan="1">UserQuery</td>
4-octet units, excluding the common header. If a Floor Control Server receives <td align="left" colspan="1" rowspan="1">P -&gt; S ; Ch -&gt;
a message with an incorrect Payload Length field value, the receiving server MUS S</td>
T send an Error message with parameter value 13 (Incorrect Message Length) to in </tr>
dicate this and then discard the message. Other entities that receive a message <tr>
with an incorrect length MUST discard the message.</t> <td align="center" colspan="1" rowspan="1">6</td>
<t><list style="hanging"> <td align="left" colspan="1" rowspan="1">UserStatus</td>
<t>Note: BFCP is designed to achieve small message size, as explained <td align="left" colspan="1" rowspan="1">P &lt;- S ; Ch &lt;-
in <xref target="sec:intro"/>, and BFCP entities are required to keep the BFCP m S</td>
essage size smaller than the size limited by the 16-bit Payload Length field. To </tr>
convey information not strictly related to floor control, other protocols shoul <tr>
d be used such as the XCON framework (cf. <xref target="sec:scope"/>).</t> <td align="center" colspan="1" rowspan="1">7</td>
</list></t> <td align="left" colspan="1" rowspan="1">FloorQuery</td>
<t>Conference ID: This 32-bit unsigned integer field identifies the confer <td align="left" colspan="1" rowspan="1">P -&gt; S ; Ch -&gt;
ence to which the message belongs. It is RECOMMENDED that the conference identi S</td>
fier be randomly chosen. (Note that the use of predictable conference identifie </tr>
rs in conjunction with a non-secure transport protocol makes BFCP susceptible to <tr>
off-path data injection attacks, where an attacker can forge a request or respo <td align="center" colspan="1" rowspan="1">8</td>
nse message.)</t> <td align="left" colspan="1" rowspan="1">FloorStatus</td>
<t>Transaction ID: This field contains a 16-bit value that allows users to <td align="left" colspan="1" rowspan="1">P &lt;- S ; Ch &lt;-
match a given message with its response (see <xref target="sec:transactions"/>) S</td>
.</t> </tr>
<t>User ID: This field contains a 16-bit unsigned integer that uniquely id <tr>
entifies a participant within a conference.</t> <td align="center" colspan="1" rowspan="1">9</td>
<t><list style="hanging"> <td align="left" colspan="1" rowspan="1">ChairAction</td>
<t>The identity used by a participant in BFCP, which is carried in the <td align="left" colspan="1" rowspan="1"> Ch -&gt; S<
User ID field, is generally mapped to the identity used by the same participant /td>
in the session establishment protocol (e.g., in SIP). The way this mapping is p </tr>
erformed is outside the scope of this specification.</t> <tr>
</list></t> <td align="center" colspan="1" rowspan="1">10</td>
<t>Fragment Offset: This optional field is present only if the F flag is s <td align="left" colspan="1" rowspan="1">ChairActionAck</td>
et and contains a 16-bit value that specifies the number of 4-octet units contai <td align="left" colspan="1" rowspan="1"> Ch &lt;- S<
ned in previous fragments, excluding the common header.</t> /td>
<t>Fragment Length: This optional field is present only if the F flag is s </tr>
et and contains a 16-bit value that specifies the number of 4-octet units contai <tr>
ned in this fragment, excluding the common header. BFCP entities that receive m <td align="center" colspan="1" rowspan="1">11</td>
essage fragments that, individually or collectively, exceed the Payload Length v <td align="left" colspan="1" rowspan="1">Hello</td>
alue MUST discard the message. Additionally, if the receiver is a Floor Control <td align="left" colspan="1" rowspan="1">P -&gt; S ; Ch -&gt;
Server, it must also send an Error message with parameter value 13 (Incorrect M S</td>
essage Length)</t> </tr>
</section> <tr>
<td align="center" colspan="1" rowspan="1">12</td>
<section title="Attribute Format" anchor="sec:format:attributes"> <td align="left" colspan="1" rowspan="1">HelloAck</td>
<t>BFCP attributes are encoded in TLV (Type-Length-Value) format. Attribut <td align="left" colspan="1" rowspan="1">P &lt;- S ; Ch &lt;-
es are 32-bit aligned.</t> S</td>
<t><figure title="Attribute format" anchor="sec:format:tlv"> </tr>
<artwork> <tr>
<td align="center" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">Error</td>
<td align="left" colspan="1" rowspan="1">P &lt;- S ; Ch &lt;-
S</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">FloorRequestStatusAck</td
>
<td align="left" colspan="1" rowspan="1">P -&gt; S ; Ch -&gt;
S</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">FloorStatusAck</td>
<td align="left" colspan="1" rowspan="1">P -&gt; S ; Ch -&gt;
S</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">16</td>
<td align="left" colspan="1" rowspan="1">Goodbye</td>
<td align="left" colspan="1" rowspan="1">P -&gt; S ; Ch -&gt;
S ; P &lt;- S ; Ch &lt;- S</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">17</td>
<td align="left" colspan="1" rowspan="1">GoodbyeAck</td>
<td align="left" colspan="1" rowspan="1">P -&gt; S ; Ch -&gt;
S ; P &lt;- S ; Ch &lt;- S</td>
</tr>
</tbody>
<tfoot>
<tr>
<td align="left" colspan="3" rowspan="1">
<t indent="0" pn="section-5.1-4.3.1.1.1">S: Floor Control Server
<br/>P: Floor Participant<br/>Ch: Floor Chair</t>
</td>
</tr>
</tfoot>
</table>
<t indent="0" pn="section-5.1-5">
</t>
<dl indent="3" newline="false" spacing="normal" pn="section-5.1-6">
<dt pn="section-5.1-6.1">Payload Length:</dt>
<dd pn="section-5.1-6.2">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 pn="section-5.1-7">
<t indent="0" pn="section-5.1-7.1">Note: BFCP is designed to achieve s
mall message size, as explained in <xref target="sec_intro" format="default" sec
tionFormat="of" derivedContent="Section 1"/>, and BFCP entities are <bcp14>REQUI
RED</bcp14> to keep the BFCP message size smaller than the size limited by the 1
6-bit Payload Length field. To convey information not strictly related to floor
control, other protocols should be used, such as the XCON Framework (cf. <xref t
arget="sec_scope" format="default" sectionFormat="of" derivedContent="Section 3"
/>).</t>
</aside>
<dl indent="3" newline="false" spacing="normal" pn="section-5.1-8">
<dt pn="section-5.1-8.1">Conference ID:</dt>
<dd pn="section-5.1-8.2">This 32-bit unsigned integer field identifies
the conference to which the message belongs. It is <bcp14>RECOMMENDED</bcp14>
that the conference identifier be randomly chosen. (Note that the use of predic
table conference identifiers in conjunction with a nonsecure transport protocol
makes BFCP susceptible to off-path data injection attacks, where an attacker can
forge a request or response message.)</dd>
<dt pn="section-5.1-8.3">Transaction ID:</dt>
<dd pn="section-5.1-8.4">This field contains a 16-bit value that allow
s users to match a given message with its response (see <xref target="sec_transa
ctions" format="default" sectionFormat="of" derivedContent="Section 8"/>).</dd>
<dt pn="section-5.1-8.5">User ID:</dt>
<dd pn="section-5.1-8.6">This field contains a 16-bit unsigned integer
that uniquely identifies a participant within a conference.</dd>
</dl>
<aside pn="section-5.1-9">
<t indent="0" pn="section-5.1-9.1">The identity used by a participant
in BFCP, which is carried in the User ID field, is generally mapped to the ident
ity used by the same participant in the session establishment protocol (e.g., in
SIP). The way this mapping is performed is outside the scope of this specificat
ion.</t>
</aside>
<dl indent="3" newline="false" spacing="normal" pn="section-5.1-10">
<dt pn="section-5.1-10.1">Fragment Offset:</dt>
<dd pn="section-5.1-10.2">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 un
its contained in previous fragments, excluding the COMMON-HEADER.</dd>
<dt pn="section-5.1-10.3">Fragment Length:</dt>
<dd pn="section-5.1-10.4">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 <bcp14>MUST</bcp14> also send an E
rror message
with parameter value 13 (Incorrect Message Length)</dd>
</dl>
</section>
<section anchor="sec_format_attributes" numbered="true" toc="include" remo
veInRFC="false" pn="section-5.2">
<name slugifiedName="name-attribute-format">Attribute Format</name>
<t indent="0" pn="section-5.2-1">BFCP attributes are encoded in TLV (Typ
e-Length-Value) format. Attributes are 32-bit aligned.</t>
<figure anchor="sec_format_tlv" align="left" suppress-title="false" pn="
figure-6">
<name slugifiedName="name-attribute-format-2">Attribute format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2-2.1">
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> <dl indent="3" newline="false" spacing="normal" pn="section-5.2-3">
<t>Type: This 7-bit field contains the type of the attribute. Each attribu <dt pn="section-5.2-3.1">Type:</dt>
te, identified by its type, has a particular format. The attribute formats defin <dd pn="section-5.2-3.2">
ed are:</t> <t indent="0" pn="section-5.2-3.2.1">This 7-bit field contains the t
<t><list style="hanging"> ype of the attribute. Each attribute, identified by its type, has a particular f
<t>Unsigned16: The contents of the attribute consist of a 16-bit unsig ormat. The attribute formats defined are:</t>
ned integer.</t> <dl indent="3" newline="false" spacing="normal" pn="section-5.2-3.2.
<t>OctetString16: The contents of the attribute consist of 16 bits of 2">
arbitrary data.</t> <dt pn="section-5.2-3.2.2.1">Unsigned16:</dt>
<t>OctetString: The contents of the attribute consist of arbitrary dat <dd pn="section-5.2-3.2.2.2">The contents of the attribute consist
a of variable length.</t> of a 16-bit unsigned integer.</dd>
<t>Grouped: The contents of the attribute consist of a sequence of att <dt pn="section-5.2-3.2.2.3">OctetString16:</dt>
ributes.</t> <dd pn="section-5.2-3.2.2.4">The contents of the attribute consist
<t>Note that extension attributes defined in the future may define new of 16 bits of arbitrary data.</dd>
attribute formats.</t> <dt pn="section-5.2-3.2.2.5">OctetString:</dt>
</list></t> <dd pn="section-5.2-3.2.2.6">The contents of the attribute consist
<t>The following attribute types are defined:</t> of arbitrary data of variable length.</dd>
<texttable title="BFCP attributes" anchor="tab:attributes"> <dt pn="section-5.2-3.2.2.7">Grouped:</dt>
<ttcol align="center">Type</ttcol> <dd pn="section-5.2-3.2.2.8">The contents of the attribute consist
<ttcol>Attribute</ttcol> of a sequence of attributes.</dd>
<ttcol>Format</ttcol> </dl>
<c>1</c> <c>BENEFICIARY-ID</c> <c>Unsigned16</c> </dd>
<c>2</c> <c>FLOOR-ID</c> <c>Unsigned16</c> </dl>
<c>3</c> <c>FLOOR-REQUEST-ID</c> <c>Unsigned16</c> <aside pn="section-5.2-4">
<c>4</c> <c>PRIORITY</c> <c>OctetString16</c> <t indent="0" pn="section-5.2-4.1">Note that extension attributes defi
<c>5</c> <c>REQUEST-STATUS</c> <c>OctetString16</c> ned in the future may define new attribute formats.</t>
<c>6</c> <c>ERROR-CODE</c> <c>OctetString</c> </aside>
<c>7</c> <c>ERROR-INFO</c> <c>OctetString</c> <t indent="0" pn="section-5.2-5">The following attribute types are defin
<c>8</c> <c>PARTICIPANT-PROVIDED-INFO</c> <c>OctetString</c> ed:</t>
<c>9</c> <c>STATUS-INFO</c> <c>OctetString</c> <table anchor="tab_attributes" align="center" pn="table-2">
<c>10</c> <c>SUPPORTED-ATTRIBUTES</c> <c>OctetString</c> <name slugifiedName="name-bfcp-attributes">BFCP attributes</name>
<c>11</c> <c>SUPPORTED-PRIMITIVES</c> <c>OctetString</c> <thead>
<c>12</c> <c>USER-DISPLAY-NAME</c> <c>OctetString</c> <tr>
<c>13</c> <c>USER-URI</c> <c>OctetString</c> <th align="center" colspan="1" rowspan="1">Type</th>
<c>14</c> <c>BENEFICIARY-INFORMATION</c> <c>Grouped</c> <th align="left" colspan="1" rowspan="1">Attribute</th>
<c>15</c> <c>FLOOR-REQUEST-INFORMATION</c> <c>Grouped</c> <th align="left" colspan="1" rowspan="1">Format</th>
<c>16</c> <c>REQUESTED-BY-INFORMATION</c> <c>Grouped</c> </tr>
<c>17</c> <c>FLOOR-REQUEST-STATUS</c> <c>Grouped</c> </thead>
<c>18</c> <c>OVERALL-REQUEST-STATUS</c> <c>Grouped</c> <tbody>
</texttable> <tr>
<t>M: The 'M' bit, known as the Mandatory bit, indicates whether support o <td align="center" colspan="1" rowspan="1">1</td>
f the attribute is required. If a Floor Control Server receives an unrecognized <td align="left" colspan="1" rowspan="1">BENEFICIARY-ID</td>
attribute with the 'M' bit set the server MUST send an Error message with param <td align="left" colspan="1" rowspan="1">Unsigned16</td>
eter value 4 (Unknown Mandatory Attribute) to indicate this. The 'M' bit is sign </tr>
ificant for extension attributes defined in other documents only. All attributes <tr>
specified in this document MUST be understood by the receiver so that the setti <td align="center" colspan="1" rowspan="1">2</td>
ng of the 'M' bit is irrelevant for these. Unrecognized attributes, such as tho <td align="left" colspan="1" rowspan="1">FLOOR-ID</td>
se that might be specified in future extensions, that do not have the "M" bit se <td align="left" colspan="1" rowspan="1">Unsigned16</td>
t are ignored, but the message is processed.</t> </tr>
<t>Length: This 8-bit field contains the length of the attribute in octets <tr>
, excluding any padding defined for specific attributes. The length of attribut <td align="center" colspan="1" rowspan="1">3</td>
es that are not grouped includes the Type, 'M' bit, and Length fields. The Lengt <td align="left" colspan="1" rowspan="1">FLOOR-REQUEST-ID</td>
h in grouped attributes is the length of the grouped attribute itself (including <td align="left" colspan="1" rowspan="1">Unsigned16</td>
Type, 'M' bit, and Length fields) plus the total length (including padding) of </tr>
all the included attributes.</t> <tr>
<t>Attribute Contents: The contents of the different attributes are define <td align="center" colspan="1" rowspan="1">4</td>
d in the following sections.</t> <td align="left" colspan="1" rowspan="1">PRIORITY</td>
<td align="left" colspan="1" rowspan="1">OctetString16</td>
<section title="BENEFICIARY-ID" anchor="sec:format:attributes:beneficiaryi </tr>
d"> <tr>
<t>The following is the format of the BENEFICIARY-ID attribute.</t> <td align="center" colspan="1" rowspan="1">5</td>
<t><figure title="BENEFICIARY-ID format" anchor="sec:format:beneficiary- <td align="left" colspan="1" rowspan="1">REQUEST-STATUS</td>
id"> <td align="left" colspan="1" rowspan="1">OctetString16</td>
<artwork> </tr>
<tr>
<td align="center" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">ERROR-CODE</td>
<td align="left" colspan="1" rowspan="1">OctetString</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">ERROR-INFO</td>
<td align="left" colspan="1" rowspan="1">OctetString</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">PARTICIPANT-PROVIDED-INFO
</td>
<td align="left" colspan="1" rowspan="1">OctetString</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">STATUS-INFO</td>
<td align="left" colspan="1" rowspan="1">OctetString</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">SUPPORTED-ATTRIBUTES</td>
<td align="left" colspan="1" rowspan="1">OctetString</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">11</td>
<td align="left" colspan="1" rowspan="1">SUPPORTED-PRIMITIVES</td>
<td align="left" colspan="1" rowspan="1">OctetString</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">12</td>
<td align="left" colspan="1" rowspan="1">USER-DISPLAY-NAME</td>
<td align="left" colspan="1" rowspan="1">OctetString</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">USER-URI</td>
<td align="left" colspan="1" rowspan="1">OctetString</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">BENEFICIARY-INFORMATION</
td>
<td align="left" colspan="1" rowspan="1">Grouped</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">FLOOR-REQUEST-INFORMATION
</td>
<td align="left" colspan="1" rowspan="1">Grouped</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">16</td>
<td align="left" colspan="1" rowspan="1">REQUESTED-BY-INFORMATION<
/td>
<td align="left" colspan="1" rowspan="1">Grouped</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">17</td>
<td align="left" colspan="1" rowspan="1">FLOOR-REQUEST-STATUS</td>
<td align="left" colspan="1" rowspan="1">Grouped</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">18</td>
<td align="left" colspan="1" rowspan="1">OVERALL-REQUEST-STATUS</t
d>
<td align="left" colspan="1" rowspan="1">Grouped</td>
</tr>
</tbody>
</table>
<dl indent="3" newline="false" spacing="normal" pn="section-5.2-7">
<dt pn="section-5.2-7.1">M:</dt>
<dd pn="section-5.2-7.2">The 'M' bit, known as the Mandatory bit, indi
cates whether support of the attribute is <bcp14>REQUIRED</bcp14>. If a floor c
ontrol server receives an unrecognized attribute with the 'M' bit set, the serve
r <bcp14>MUST</bcp14> send an Error message with parameter value 4 (Unknown Mand
atory Attribute) to indicate this. The 'M' bit is significant for extension attr
ibutes defined in other documents only. All attributes specified in this documen
t <bcp14>MUST</bcp14> be understood by the receiver so that the setting of the '
M' bit is irrelevant for these. Unrecognized attributes, such as those that mig
ht be specified in future extensions, that do not have the 'M' bit set are ignor
ed, but the message is processed.</dd>
<dt pn="section-5.2-7.3">Length:</dt>
<dd pn="section-5.2-7.4">This 8-bit field contains the length of the a
ttribute in octets, excluding any padding defined for specific attributes. The
length of attributes that are not grouped includes the Type, 'M' bit, and Length
fields. The Length in grouped attributes is the length of the grouped attribute
itself (including Type, 'M' bit, and Length fields) plus the total length (incl
uding padding) of all the included attributes.</dd>
<dt pn="section-5.2-7.5">Attribute Contents:</dt>
<dd pn="section-5.2-7.6">The contents of the different
attributes are defined in the following sections.</dd>
</dl>
<section anchor="sec_format_attributes_beneficiaryid" numbered="true" to
c="include" removeInRFC="false" pn="section-5.2.1">
<name slugifiedName="name-beneficiary-id">BENEFICIARY-ID</name>
<t indent="0" pn="section-5.2.1-1">The following is the format of the
BENEFICIARY-ID attribute.</t>
<figure anchor="sec_format_beneficiary-id" align="left" suppress-title
="false" pn="figure-7">
<name slugifiedName="name-beneficiary-id-format">BENEFICIARY-ID form
at</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.1-2.1">
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 indent="3" newline="false" spacing="normal" pn="section-5.2.1-3">
<t>Beneficiary ID: This field contains a 16-bit value that uniquely iden <dt pn="section-5.2.1-3.1">Beneficiary ID:</dt>
tifies a user within a conference.</t> <dd pn="section-5.2.1-3.2">This field contains a 16-bit value that
<t><list style="empty"> uniquely identifies a user within a conference.</dd>
<t>Note that although the formats of the Beneficiary ID and of the U </dl>
ser ID field in the common header are similar, their semantics are different. Th <aside pn="section-5.2.1-4">
e Beneficiary ID is used in third-party floor requests and to request informatio <t indent="0" pn="section-5.2.1-4.1">Note that although the formats
n about a particular participant.</t> of the Beneficiary ID and of the User ID field in the COMMON-HEADER are similar,
</list></t> their semantics are different. The Beneficiary ID is used in third-party floor
</section> requests and to request information about a particular participant.</t>
</aside>
<section title="FLOOR-ID" anchor="sec:format:attributes:floorid"> </section>
<t>The following is the format of the FLOOR-ID attribute.</t> <section anchor="sec_format_attributes_floorid" numbered="true" toc="inc
<t><figure title="FLOOR-ID format" anchor="sec:format:floor-id"> lude" removeInRFC="false" pn="section-5.2.2">
<artwork> <name slugifiedName="name-floor-id">FLOOR-ID</name>
<t indent="0" pn="section-5.2.2-1">The following is the format of the
FLOOR-ID attribute.</t>
<figure anchor="sec_format_floor-id" align="left" suppress-title="fals
e" pn="figure-8">
<name slugifiedName="name-floor-id-format">FLOOR-ID format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.2-2.1">
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 indent="3" newline="false" spacing="normal" pn="section-5.2.2-3">
<t>Floor ID: This field contains a 16-bit value that uniquely identifies <dt pn="section-5.2.2-3.1">Floor ID:</dt>
a floor within a conference.</t> <dd pn="section-5.2.2-3.2">This field contains a 16-bit value that
</section> uniquely identifies a floor within a conference.</dd>
</dl>
<section title="FLOOR-REQUEST-ID" anchor="sec:format:attributes:floorreque </section>
stid"> <section anchor="sec_format_attributes_floorrequestid" numbered="true" t
<t>The following is the format of the FLOOR-REQUEST-ID attribute.</t> oc="include" removeInRFC="false" pn="section-5.2.3">
<t><figure title="FLOOR-REQUEST-ID format" anchor="sec:format:floor-requ <name slugifiedName="name-floor-request-id">FLOOR-REQUEST-ID</name>
est-id"> <t indent="0" pn="section-5.2.3-1">The following is the format of the
<artwork> FLOOR-REQUEST-ID attribute.</t>
<figure anchor="sec_format_floor-request-id" align="left" suppress-tit
le="false" pn="figure-9">
<name slugifiedName="name-floor-request-id-format">FLOOR-REQUEST-ID
format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.3-2.1">
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 indent="3" newline="false" spacing="normal" pn="section-5.2.3-3">
<t>Floor Request ID: This field contains a 16-bit value that identifies <dt pn="section-5.2.3-3.1">Floor Request ID:</dt>
a floor request at the floor control server.</t> <dd pn="section-5.2.3-3.2">This field contains a 16-bit value
</section> that identifies a floor request at the floor control server.</dd>
</dl>
<section title="PRIORITY" anchor="sec:format:attributes:priority"> </section>
<t>The following is the format of the PRIORITY attribute.</t> <section anchor="sec_format_attributes_priority" numbered="true" toc="in
<t><figure title="PRIORITY format" anchor="sec:format:priority"> clude" removeInRFC="false" pn="section-5.2.4">
<artwork> <name slugifiedName="name-priority">PRIORITY</name>
<t indent="0" pn="section-5.2.4-1">The following is the format of the
PRIORITY attribute.</t>
<figure anchor="sec_format_priority" align="left" suppress-title="fals
e" pn="figure-10">
<name slugifiedName="name-priority-format">PRIORITY format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.4-2.1">
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 indent="3" newline="false" spacing="normal" pn="section-5.2.4-3">
<t>Prio: This field contains a 3-bit priority value, as shown in <xref t <dt pn="section-5.2.4-3.1">Prio:</dt>
arget="tab:priority"/>. Senders SHOULD NOT use values higher than 4 in this fiel <dd pn="section-5.2.4-3.2">This field contains a 3-bit Priority valu
d. Receivers MUST treat values higher than 4 as if the value received were 4 (Hi e, as
ghest). The default priority value when the PRIORITY attribute is missing is 2 ( shown in <xref target="tab_priority" format="default" sectionFormat="of
Normal).</t> " derivedContent="Table 3"/>. Senders
<texttable title="Priority values" anchor="tab:priority"> <bcp14>SHOULD NOT</bcp14> use values higher than 4 in this
<ttcol align="center">Value</ttcol> field. Receivers <bcp14>MUST</bcp14> treat values higher than 4 as
<ttcol>Priority</ttcol> if the value received were 4 (Highest). The default Priority value
<c>0</c> <c>Lowest</c> when the PRIORITY attribute is missing is 2 (Normal).</dd>
<c>1</c> <c>Low</c> </dl>
<c>2</c> <c>Normal</c> <table anchor="tab_priority" align="center" pn="table-3">
<c>3</c> <c>High</c> <name slugifiedName="name-priority-values">Priority values</name>
<c>4</c> <c>Highest</c> <thead>
</texttable> <tr>
<t>Reserved: The 13 bits in the reserved field MUST be set to zero by th <th align="center" colspan="1" rowspan="1">Value</th>
e sender of the message and MUST be ignored by the receiver.</t> <th align="left" colspan="1" rowspan="1">Priority</th>
</section> </tr>
</thead>
<section title="REQUEST-STATUS" anchor="sec:format:attributes:req-status"> <tbody>
<t>The following is the format of the REQUEST-STATUS attribute.</t> <tr>
<t><figure title="REQUEST-STATUS format" anchor="sec:format:request-stat <td align="center" colspan="1" rowspan="1">0</td>
us"> <td align="left" colspan="1" rowspan="1">Lowest</td>
<artwork> </tr>
<tr>
<td align="center" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">Low</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">Normal</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">High</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">Highest</td>
</tr>
</tbody>
</table>
<dl indent="3" newline="false" spacing="normal" pn="section-5.2.4-5">
<dt pn="section-5.2.4-5.1">Reserved:</dt>
<dd pn="section-5.2.4-5.2">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 ignored by the receiver.</dd>
</dl>
</section>
<section anchor="sec_format_attributes_req-status" numbered="true" toc="
include" removeInRFC="false" pn="section-5.2.5">
<name slugifiedName="name-request-status">REQUEST-STATUS</name>
<t indent="0" pn="section-5.2.5-1">The following is the format of the
REQUEST-STATUS attribute.</t>
<figure anchor="sec_format_request-status" align="left" suppress-title
="false" pn="figure-11">
<name slugifiedName="name-request-status-format">REQUEST-STATUS form
at</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.5-2.1">
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 indent="3" newline="false" spacing="normal" pn="section-5.2.5-3">
<t>Request Status: This 8-bit field contains the status of the request, <dt pn="section-5.2.5-3.1">Request Status:</dt>
as described in the following table.</t> <dd pn="section-5.2.5-3.2">This 8-bit field contains the status of t
<texttable title="Request Status values" anchor="tab:requeststatusvalues he request, as described in the following table.</dd>
"> </dl>
<ttcol align="center">Value</ttcol> <table anchor="tab_requeststatusvalues" align="center" pn="table-4">
<ttcol>Status</ttcol> <name slugifiedName="name-request-status-values">Request Status valu
<c>1</c> <c>Pending</c> es</name>
<c>2</c> <c>Accepted</c> <thead>
<c>3</c> <c>Granted</c> <tr>
<c>4</c> <c>Denied</c> <th align="center" colspan="1" rowspan="1">Value</th>
<c>5</c> <c>Cancelled</c> <th align="left" colspan="1" rowspan="1">Status</th>
<c>6</c> <c>Released</c> </tr>
<c>7</c> <c>Revoked</c> </thead>
</texttable> <tbody>
<t>Queue Position: This 8-bit field contains, when applicable, the posit <tr>
ion of the floor request in the floor request queue at the server. If the Reques <td align="center" colspan="1" rowspan="1">1</td>
t Status value is different from Accepted, if the floor control server does not <td align="left" colspan="1" rowspan="1">Pending</td>
implement a floor request queue, or if the floor control server does not want to </tr>
provide the client with this information, all the bits of this field SHOULD be <tr>
set to zero.</t> <td align="center" colspan="1" rowspan="1">2</td>
<t>A floor request is in Pending state if the floor control server needs <td align="left" colspan="1" rowspan="1">Accepted</td>
to contact a floor chair in order to accept the floor request, but has not done </tr>
it yet. Once the floor control chair accepts the floor request, the floor reque <tr>
st is moved to the Accepted state.</t> <td align="center" colspan="1" rowspan="1">3</td>
</section> <td align="left" colspan="1" rowspan="1">Granted</td>
</tr>
<section title="ERROR-CODE" anchor="sec:format:attributes:error-code"> <tr>
<t>The following is the format of the ERROR-CODE attribute.</t> <td align="center" colspan="1" rowspan="1">4</td>
<t><figure title="ERROR-CODE format" anchor="sec:format:error"> <td align="left" colspan="1" rowspan="1">Denied</td>
<artwork> </tr>
<tr>
<td align="center" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">Cancelled</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">Released</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">Revoked</td>
</tr>
</tbody>
</table>
<dl indent="3" newline="false" spacing="normal" pn="section-5.2.5-5">
<dt pn="section-5.2.5-5.1">Queue Position:</dt>
<dd pn="section-5.2.5-5.2">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 indent="0" pn="section-5.2.5-6">A floor request is in Pending state
if the floor control server needs to contact a floor chair in order to accept t
he floor request, but has not done it yet. Once the floor control chair accepts
the floor request, the floor request is moved to the Accepted state.</t>
</section>
<section anchor="sec_format_attributes_error-code" numbered="true" toc="
include" removeInRFC="false" pn="section-5.2.6">
<name slugifiedName="name-error-code">ERROR-CODE</name>
<t indent="0" pn="section-5.2.6-1">The following is the format of the
ERROR-CODE attribute.</t>
<figure anchor="sec_format_error" align="left" suppress-title="false"
pn="figure-12">
<name slugifiedName="name-error-code-format">ERROR-CODE format</name
>
<artwork name="" type="" align="left" alt="" pn="section-5.2.6-2.1">
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 indent="3" newline="false" spacing="normal" pn="section-5.2.6-3">
<t>Error Code: This 8-bit field contains an error code from the followin <dt pn="section-5.2.6-3.1">Error Code:</dt>
g table. If an error code is not recognized by the receiver, then the receiver M <dd pn="section-5.2.6-3.2">This 8-bit field contains an error code
UST assume that an error exists, and therefore that the original message that tr from the following table. If an error code is not recognized by the
iggered the Error message to be sent is processed, but the nature of the error i receiver, then the receiver <bcp14>MUST</bcp14> assume that an error
s unclear.</t> exists, and therefore that the original message that triggered the
<texttable title="Error Code meaning" anchor="tab:errorcode"> Error message to be sent is processed, but the nature of the error
<ttcol align="center">Value</ttcol> is unclear.</dd>
<ttcol>Meaning</ttcol> </dl>
<c>1</c> <c>Conference does not Exist</c> <table anchor="tab_errorcode" align="center" pn="table-5">
<c>2</c> <c>User does not Exist</c> <name slugifiedName="name-error-code-meaning">Error Code meaning</na
<c>3</c> <c>Unknown Primitive</c> me>
<c>4</c> <c>Unknown Mandatory Attribute</c> <thead>
<c>5</c> <c>Unauthorized Operation</c> <tr>
<c>6</c> <c>Invalid Floor ID</c> <th align="center" colspan="1" rowspan="1">Value</th>
<c>7</c> <c>Floor Request ID Does Not Exist</c> <th align="left" colspan="1" rowspan="1">Meaning</th>
<c>8</c> <c>You have Already Reached the Maximum Number of Ongoing Fl </tr>
oor Requests for this Floor</c> </thead>
<c>9</c> <c>Use TLS</c> <tbody>
<c>10</c> <c>Unable to Parse Message</c> <tr>
<c>11</c> <c>Use DTLS</c> <td align="center" colspan="1" rowspan="1">1</td>
<c>12</c> <c>Unsupported Version</c> <td align="left" colspan="1" rowspan="1">Conference Does Not Exi
<c>13</c> <c>Incorrect Message Length</c> st</td>
<c>14</c> <c>Generic Error</c> </tr>
</texttable> <tr>
<t><list style="empty"> <td align="center" colspan="1" rowspan="1">2</td>
<t>Note: The Generic Error error code is intended to be used when an <td align="left" colspan="1" rowspan="1">User Does Not Exist</td
error occurs and the other specific error codes do not apply.</t> >
</list></t> </tr>
<t>Error Specific Details: Present only for certain Error Codes. In this <tr>
document, only for Error Code 4 (Unknown Mandatory Attribute). See <xref target <td align="center" colspan="1" rowspan="1">3</td>
="sec:format:attributes:error-code:specific-4"/> for its definition.</t> <td align="left" colspan="1" rowspan="1">Unknown Primitive</td>
<t>Padding: One, two, or three octets of padding added so that the conte </tr>
nts of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 3 <tr>
2-bit aligned, no padding is needed.</t> <td align="center" colspan="1" rowspan="1">4</td>
<t>The Padding bits MUST be set to zero by the sender and MUST be ignore <td align="left" colspan="1" rowspan="1">Unknown Mandatory Attri
d by the receiver.</t> bute</td>
</tr>
<section title="Error-Specific Details for Error Code 4" anchor="sec:for <tr>
mat:attributes:error-code:specific-4"> <td align="center" colspan="1" rowspan="1">5</td>
<t>The following is the format of the Error-Specific Details field for <td align="left" colspan="1" rowspan="1">Unauthorized Operation<
Error Code 4.</t> /td>
<t><figure title="Unknown attributes format" anchor="sec:format:unknow </tr>
n-tlvs"> <tr>
<artwork> <td align="center" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">Invalid Floor ID</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">Floor Request ID Does N
ot Exist</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">You have Already Reache
d the Maximum Number of Ongoing Floor Requests for This Floor</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">Use TLS</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">Unable to Parse Message
</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">11</td>
<td align="left" colspan="1" rowspan="1">Use DTLS</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">12</td>
<td align="left" colspan="1" rowspan="1">Unsupported Version</td
>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">Incorrect Message Lengt
h</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">Generic Error</td>
</tr>
</tbody>
</table>
<aside pn="section-5.2.6-5">
<t indent="0" pn="section-5.2.6-5.1">Note: The Generic Error error c
ode is intended to be used when an error occurs and the other specific error cod
es do not apply.</t>
</aside>
<dl indent="3" newline="false" spacing="normal" pn="section-5.2.6-6">
<dt pn="section-5.2.6-6.1">Error Specific Details:</dt>
<dd pn="section-5.2.6-6.2">Present only for certain error codes. In
this document, this field is present only for Error Code 4 (Unknown Mandatory At
tribute). See <xref target="sec_format_attributes_error-code_specific-4" format=
"default" sectionFormat="of" derivedContent="Section 5.2.6.1"/> for its definiti
on.</dd>
<dt pn="section-5.2.6-6.3">Padding:</dt>
<dd pn="section-5.2.6-6.4">
<t indent="0" pn="section-5.2.6-6.4.1">One, two, or three octets o
f padding added so that the contents of the ERROR-CODE attribute is 32-bit align
ed. If the attribute is already 32-bit aligned, no padding is needed.</t>
<t indent="0" pn="section-5.2.6-6.4.2">The Padding bits <bcp14>MUS
T</bcp14> be set to zero by the sender and <bcp14>MUST</bcp14> be ignored by the
receiver.</t>
</dd>
</dl>
<section anchor="sec_format_attributes_error-code_specific-4" numbered
="true" toc="include" removeInRFC="false" pn="section-5.2.6.1">
<name slugifiedName="name-error-specific-details-for-">Error Specifi
c Details for Error Code 4</name>
<t indent="0" pn="section-5.2.6.1-1">The following is the format of
the Error Specific Details field for Error Code 4.</t>
<figure anchor="sec_format_unknown-tlvs" align="left" suppress-title
="false" pn="figure-13">
<name slugifiedName="name-unknown-attributes-format">Unknown attri
butes format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.6.1-2
.1">
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> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.6.1-
<t>Unknown Type: These 7-bit fields contain the Types of the attribute 3">
s (which were present in the message that triggered the Error message) that were <dt pn="section-5.2.6.1-3.1">Unknown Type:</dt>
unknown to the receiver.</t> <dd pn="section-5.2.6.1-3.2">These 7-bit fields contain the Types
<t>R: This bit is reserved. It MUST be set to zero by the sender of th of the attributes (which were present in the message that triggered the Error me
e message and MUST be ignored by the receiver.</t> ssage) that were unknown to the receiver.</dd>
<dt pn="section-5.2.6.1-3.3">Reserved (R):</dt>
<dd pn="section-5.2.6.1-3.4">This bit is reserved. It <bcp14>MUST<
/bcp14> be
set to zero by the sender of the message and <bcp14>MUST</bcp14>
be ignored by the receiver.</dd>
</dl>
</section>
</section> </section>
</section> <section anchor="sec_format_attributes_error-info" numbered="true" toc="
include" removeInRFC="false" pn="section-5.2.7">
<section title="ERROR-INFO" anchor="sec:format:attributes:error-info"> <name slugifiedName="name-error-info">ERROR-INFO</name>
<t>The following is the format of the ERROR-INFO attribute.</t> <t indent="0" pn="section-5.2.7-1">The following is the format of the
<t><figure title="ERROR-INFO format" anchor="sec:format:error-info"> ERROR-INFO attribute.</t>
<artwork> <figure anchor="sec_format_error-info" align="left" suppress-title="fa
lse" pn="figure-14">
<name slugifiedName="name-error-info-format">ERROR-INFO format</name
>
<artwork name="" type="" align="left" alt="" pn="section-5.2.7-2.1">
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 indent="3" newline="false" spacing="normal" pn="section-5.2.7-3">
<t>Text: This field contains UTF-8 <xref target="RFC3629"/> encoded text <dt pn="section-5.2.7-3.1">Text:</dt>
.</t> <dd pn="section-5.2.7-3.2">
<t>In some situations, the contents of the Text field may be generated b <t indent="0" pn="section-5.2.7-3.2.1">This field contains UTF-8 e
y an automaton. If this automaton has information about the preferred language o ncoded text <xref target="RFC3629" format="default" sectionFormat="of" derivedCo
f the receiver of a particular ERROR-INFO attribute, it MAY use this language to ntent="9"/>.</t>
generate the Text field.</t> <t indent="0" pn="section-5.2.7-3.2.2">In some situations, the con
<t>Padding: One, two, or three octets of padding added so that the conte tents of the Text field may be generated by an automaton. If this automaton has
nts of the ERROR-INFO attribute is 32-bit aligned. The Padding bits MUST be set information about the preferred language of the receiver of a particular ERROR-I
to zero by the sender and MUST be ignored by the receiver. If the attribute is a NFO attribute, it <bcp14>MAY</bcp14> use this language to generate the Text fiel
lready 32-bit aligned, no padding is needed.</t> d.</t>
</section> </dd>
<dt pn="section-5.2.7-3.3">Padding:</dt>
<section title="PARTICIPANT-PROVIDED-INFO" anchor="sec:format:attributes:h <dd pn="section-5.2.7-3.4">One, two, or three octets of padding adde
uman-read-info"> d so
<t>The following is the format of the PARTICIPANT-PROVIDED-INFO attribut that the contents of the ERROR-INFO attribute is 32-bit aligned. The
e.</t> Padding bits <bcp14>MUST</bcp14> be set to zero by the sender and
<t><figure title="PARTICIPANT-PROVIDED-INFO format" anchor="sec:format:h <bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is
uman"> already 32-bit aligned, no padding is needed.</dd>
<artwork> </dl>
</section>
<section anchor="sec_format_attributes_human-read-info" numbered="true"
toc="include" removeInRFC="false" pn="section-5.2.8">
<name slugifiedName="name-participant-provided-info">PARTICIPANT-PROVI
DED-INFO</name>
<t indent="0" pn="section-5.2.8-1">The following is the format of the
PARTICIPANT-PROVIDED-INFO attribute.</t>
<figure anchor="sec_format_human" align="left" suppress-title="false"
pn="figure-15">
<name slugifiedName="name-participant-provided-info-f">PARTICIPANT-P
ROVIDED-INFO format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.8-2.1">
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> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.8-3">
<t>Text: This field contains UTF-8 <xref target="RFC3629"/> encoded text <dt pn="section-5.2.8-3.1">Text:</dt>
.</t> <dd pn="section-5.2.8-3.2">This field contains UTF-8 encoded text <x
<t>Padding: One, two, or three octets of padding added so that the conte ref target="RFC3629" format="default" sectionFormat="of" derivedContent="9"/>.</
nts of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bi dd>
ts MUST be set to zero by the sender and MUST be ignored by the receiver. If the <dt pn="section-5.2.8-3.3">Padding:</dt>
attribute is already 32-bit aligned, no padding is needed.</t> <dd pn="section-5.2.8-3.4">One, two, or three octets of padding adde
</section> d so
that the contents of the PARTICIPANT-PROVIDED-INFO attribute is
<section title="STATUS-INFO" anchor="sec:format:attributes:status-info"> 32-bit aligned. The Padding bits <bcp14>MUST</bcp14> be set to zero
<t>The following is the format of the STATUS-INFO attribute.</t> by the sender and <bcp14>MUST</bcp14> be ignored by the receiver. If
<t><figure title="STATUS-INFO format" anchor="sec:format:status"> the attribute is already 32-bit aligned, no padding is needed.</dd>
<artwork> </dl>
</section>
<section anchor="sec_format_attributes_status-info" numbered="true" toc=
"include" removeInRFC="false" pn="section-5.2.9">
<name slugifiedName="name-status-info">STATUS-INFO</name>
<t indent="0" pn="section-5.2.9-1">The following is the format of the
STATUS-INFO attribute.</t>
<figure anchor="sec_format_status" align="left" suppress-title="false"
pn="figure-16">
<name slugifiedName="name-status-info-format">STATUS-INFO format</na
me>
<artwork name="" type="" align="left" alt="" pn="section-5.2.9-2.1">
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 indent="3" newline="false" spacing="normal" pn="section-5.2.9-3">
<t>Text: This field contains UTF-8 <xref target="RFC3629"/> encoded text <dt pn="section-5.2.9-3.1">Text:</dt>
.</t> <dd pn="section-5.2.9-3.2">
<t>In some situations, the contents of the Text field may be generated b <t indent="0" pn="section-5.2.9-3.2.1">This field contains UTF-8 e
y an automaton. If this automaton has information about the preferred language o ncoded text <xref target="RFC3629" format="default" sectionFormat="of" derivedCo
f the receiver of a particular STATUS-INFO attribute, it MAY use this language t ntent="9"/>.</t>
o generate the Text field.</t> <t indent="0" pn="section-5.2.9-3.2.2">In some situations, the con
<t>Padding: One, two, or three octets of padding added so that the conte tents of the Text field may be generated by an automaton. If this automaton has
nts of the STATUS-INFO attribute is 32-bit aligned. The Padding bits MUST be set information about the preferred language of the receiver of a particular STATUS-
to zero by the sender and MUST be ignored by the receiver. If the attribute is INFO attribute, it <bcp14>MAY</bcp14> use this language to generate the Text fie
already 32-bit aligned, no padding is needed.</t> ld.</t>
</section> </dd>
<dt pn="section-5.2.9-3.3">Padding:</dt>
<section title="SUPPORTED-ATTRIBUTES" anchor="sec:format:attributes:suppor <dd pn="section-5.2.9-3.4">One, two, or three octets of padding adde
ted-tlvs"> d so
<t>The following is the format of the SUPPORTED-ATTRIBUTES attribute.</t that the contents of the STATUS-INFO attribute is 32-bit
> aligned. The Padding bits <bcp14>MUST</bcp14> be set to zero by the
<t><figure title="SUPPORTED-ATTRIBUTES format" anchor="fig:format:suppor sender and <bcp14>MUST</bcp14> be ignored by the receiver. If the
ted-tlvs"> attribute is already 32-bit aligned, no padding is needed.</dd>
<artwork> </dl>
</section>
<section anchor="sec_format_attributes_supported-tlvs" numbered="true" t
oc="include" removeInRFC="false" pn="section-5.2.10">
<name slugifiedName="name-supported-attributes">SUPPORTED-ATTRIBUTES</
name>
<t indent="0" pn="section-5.2.10-1">The following is the format of the
SUPPORTED-ATTRIBUTES attribute.</t>
<figure anchor="fig_format_supported-tlvs" align="left" suppress-title
="false" pn="figure-17">
<name slugifiedName="name-supported-attributes-format">SUPPORTED-ATT
RIBUTES format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.10-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.10-3">
<t>Supp. Attr.: These fields contain the Types of the attributes that ar <dt pn="section-5.2.10-3.1">Supp. Attr.:</dt>
e supported by the floor control server in the following format:</t> <dd pn="section-5.2.10-3.2">These fields contain the
<t>R: Reserved: This bit MUST be set to zero upon transmission and MUST BFCP attribute types that are supported by the floor control server.
be ignored upon reception.</t> See <xref target="tab_attributes" format="default" sectionFormat="of" derivedCon
<t>Padding: One, two, or three octets of padding added so that the conte tent="Table 2"/> for the list
nts of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is of BFCP attributes.</dd>
already 32-bit aligned, no padding is needed.</t> <dt pn="section-5.2.10-3.3">Reserved (R):</dt>
<t>The Padding bits MUST be set to zero by the sender and MUST be ignore <dd pn="section-5.2.10-3.4">This bit <bcp14>MUST</bcp14> be set to z
d by the receiver.</t> ero upon transmission and <bcp14>MUST</bcp14> be ignored upon reception.</dd>
</section> <dt pn="section-5.2.10-3.5">Padding:</dt>
<dd pn="section-5.2.10-3.6">
<section title="SUPPORTED-PRIMITIVES" anchor="sec:format:attributes:suppor <t indent="0" pn="section-5.2.10-3.6.1">One, two, or three octets
ted-reqs"> of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 3
<t>The following is the format of the SUPPORTED-PRIMITIVES attribute.</t 2-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
> </t>
<t><figure title="SUPPORTED-PRIMITIVES format" anchor="fig:format:suppor <t indent="0" pn="section-5.2.10-3.6.2">The Padding bits <bcp14>MU
ted-reqs"> ST</bcp14> be set to zero by the sender
<artwork> and <bcp14>MUST</bcp14> be ignored by the receiver.</t>
</dd>
</dl>
</section>
<section anchor="sec_format_attributes_supported-reqs" numbered="true" t
oc="include" removeInRFC="false" pn="section-5.2.11">
<name slugifiedName="name-supported-primitives">SUPPORTED-PRIMITIVES</
name>
<t indent="0" pn="section-5.2.11-1">The following is the format of the
SUPPORTED-PRIMITIVES attribute.</t>
<figure anchor="fig_format_supported-reqs" align="left" suppress-title
="false" pn="figure-18">
<name slugifiedName="name-supported-primitives-format">SUPPORTED-PRI
MITIVES format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.11-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.11-3">
<t>Primitive: These fields contain the types of the BFCP messages that a <dt pn="section-5.2.11-3.1">Primitive:</dt>
re supported by the floor control server. See <xref target="tab:primitives"/> fo <dd pn="section-5.2.11-3.2">These fields contain the types of the BF
r the list of BFCP primitives.</t> CP messages that are supported by the floor control server. See <xref target="ta
<t>Padding: One, two, or three octets of padding added so that the conte b_primitives" format="default" sectionFormat="of" derivedContent="Table 1"/> for
nts of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is the list of BFCP primitives.</dd>
already 32-bit aligned, no padding is needed.</t> <dt pn="section-5.2.11-3.3">Padding:</dt>
<t>The Padding bits MUST be set to zero by the sender and MUST be ignore <dd pn="section-5.2.11-3.4">
d by the receiver.</t> <t indent="0" pn="section-5.2.11-3.4.1">One, two, or three octets
</section> of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 3
2-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.
<section title="USER-DISPLAY-NAME" anchor="sec:format:attributes:user-disp </t>
lay-name"> <t indent="0" pn="section-5.2.11-3.4.2">The Padding bits <bcp14>MU
<t>The following is the format of the USER-DISPLAY-NAME attribute.</t> ST</bcp14> be set to zero by the sender
<t><figure title="USER-DISPLAY-NAME format" anchor="sec:format:user-disp and <bcp14>MUST</bcp14> be ignored by the receiver.</t>
lay"> </dd>
<artwork> </dl>
</section>
<section anchor="sec_format_attributes_user-display-name" numbered="true
" toc="include" removeInRFC="false" pn="section-5.2.12">
<name slugifiedName="name-user-display-name">USER-DISPLAY-NAME</name>
<t indent="0" pn="section-5.2.12-1">The following is the format of the
USER-DISPLAY-NAME attribute.</t>
<figure anchor="sec_format_user-display" align="left" suppress-title="
false" pn="figure-19">
<name slugifiedName="name-user-display-name-format">USER-DISPLAY-NAM
E format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.12-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.12-3">
<t>Text: This field contains the UTF-8 encoded name of the user.</t> <dt pn="section-5.2.12-3.1">Text:</dt>
<t>Padding: One, two, or three octets of padding added so that the conte <dd pn="section-5.2.12-3.2">This field contains the UTF-8 encoded na
nts of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bits MUST me of the user.</dd>
be set to zero by the sender and MUST be ignored by the receiver. If the attribu <dt pn="section-5.2.12-3.3">Padding:</dt>
te is already 32-bit aligned, no padding is needed.</t> <dd pn="section-5.2.12-3.4">One, two, or three octets of padding add
</section> ed so
that the contents of the USER-DISPLAY-NAME attribute is 32-bit
<section title="USER-URI" anchor="sec:format:attributes:user-uri"> aligned. The Padding bits <bcp14>MUST</bcp14> be set to zero by the
<t>The following is the format of the USER-URI attribute.</t> sender and <bcp14>MUST</bcp14> be ignored by the receiver. If the
<t><figure title="USER-URI format" anchor="sec:format:user-uri"> attribute is already 32-bit aligned, no padding is needed.</dd>
<artwork> </dl>
</section>
<section anchor="sec_format_attributes_user-uri" numbered="true" toc="in
clude" removeInRFC="false" pn="section-5.2.13">
<name slugifiedName="name-user-uri">USER-URI</name>
<t indent="0" pn="section-5.2.13-1">The following is the format of the
USER-URI attribute.</t>
<figure anchor="sec_format_user-uri" align="left" suppress-title="fals
e" pn="figure-20">
<name slugifiedName="name-user-uri-format">USER-URI format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.13-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.13-3">
<t>Text: This field contains the UTF-8 encoded user's contact URI, that <dt pn="section-5.2.13-3.1">Text:</dt>
is, the URI used by the user to set up the resources (e.g., media streams) that <dd pn="section-5.2.13-3.2">This field contains the UTF-8 encoded us
are controlled by BFCP. For example, in the context of a conference set up by SI er's contact URI, that is, the URI used by the user to set up the resources (e.g
P, the USER-URI attribute would carry the SIP URI of the user.</t> ., media streams) that are controlled by BFCP. For example, in the context of a
<t><list style="hanging"> conference set up by SIP, the USER-URI attribute would carry the SIP URI of the
<t>Messages containing a user's URI in a USER-URI attribute also con user.</dd>
tain the user's User ID. This way, a client receiving such a message can correla </dl>
te the user's URI (e.g., the SIP URI the user used to join a conference) with th <aside pn="section-5.2.13-4">
e user's User ID.</t> <t indent="0" pn="section-5.2.13-4.1">Messages containing a user's U
</list></t> RI in a USER-URI attribute also contain the user's User ID. This way, a client r
<t>Padding: One, two, or three octets of padding added so that the conte eceiving such a message can correlate the user's URI (e.g., the SIP URI the user
nts of the USER-URI attribute is 32-bit aligned. The Padding bits MUST be set to used to join a conference) with the user's User ID.</t>
zero by the sender and MUST be ignored by the receiver. If the attribute is alr </aside>
eady 32-bit aligned, no padding is needed.</t> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.13-5">
</section> <dt pn="section-5.2.13-5.1">Padding:</dt>
<dd pn="section-5.2.13-5.2">One, two, or three octets of padding add
<section title="BENEFICIARY-INFORMATION" anchor="sec:format:attributes:ben ed so
-info"> that the contents of the USER-URI attribute is 32-bit aligned. The
<t>The BENEFICIARY-INFORMATION attribute is a grouped attribute that con Padding bits <bcp14>MUST</bcp14> be set to zero by the sender and
sists of a header, which is referred to as BENEFICIARY-INFORMATION-HEADER, follo <bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is
wed by a sequence of attributes. The following is the format of the BENEFICIARY- already 32-bit aligned, no padding is needed.</dd>
INFORMATION-HEADER:</t> </dl>
<t><figure title="BENEFICIARY-INFORMATION-HEADER format" anchor="fig:for </section>
mat:ben-information-header"> <section anchor="sec_format_attributes_ben-info" numbered="true" toc="in
<artwork> clude" removeInRFC="false" pn="section-5.2.14">
<name slugifiedName="name-beneficiary-information">BENEFICIARY-INFORMA
TION</name>
<t indent="0" pn="section-5.2.14-1">The BENEFICIARY-INFORMATION attrib
ute is a grouped attribute that consists of a header, which is referred to as BE
NEFICIARY-INFORMATION-HEADER, followed by a sequence of attributes. The followin
g is the format of the BENEFICIARY-INFORMATION-HEADER:</t>
<figure anchor="fig_format_ben-information-header" align="left" suppre
ss-title="false" pn="figure-21">
<name slugifiedName="name-beneficiary-information-hea">BENEFICIARY-I
NFORMATION-HEADER format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.14-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.14-3">
<t>Beneficiary ID: This field contains a 16-bit value that uniquely iden <dt pn="section-5.2.14-3.1">Beneficiary ID:</dt>
tifies a user within a conference.</t> <dd pn="section-5.2.14-3.2">This field contains a 16-bit value that
<t>The following is the ABNF (Augmented Backus-Naur Form) <xref target=" uniquely identifies a user within a conference.</dd>
RFC5234"/> of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUT </dl>
E refers to extension attributes that may be defined in the future.)</t> <t indent="0" pn="section-5.2.14-4">The following is the ABNF (Augment
<t><figure title="BENEFICIARY-INFORMATION format" anchor="fig:ben-inform ed Backus-Naur Form) <xref target="RFC5234" format="default" sectionFormat="of"
ation"> derivedContent="5"/> of the BENEFICIARY-INFORMATION
<artwork> grouped attribute. (EXTENSION-ATTRIBUTE refers to extension
BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER attributes that may be defined in the future.)</t>
[USER-DISPLAY-NAME] <figure anchor="fig_ben-information" align="left" suppress-title="fals
[USER-URI] e" pn="figure-22">
*EXTENSION-ATTRIBUTE <name slugifiedName="name-beneficiary-information-for">BENEFICIARY-I
</artwork> NFORMATION format</name>
</figure></t> <sourcecode name="" type="abnf" markers="false" pn="section-5.2.14-5
</section> .1">
BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER
<section title="FLOOR-REQUEST-INFORMATION" anchor="sec:format:attributes:f [USER-DISPLAY-NAME]
loor-req-info"> [USER-URI]
<t>The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that c *EXTENSION-ATTRIBUTE</sourcecode>
onsists of a header, which is referred to as FLOOR-REQUEST-INFORMATION-HEADER, f </figure>
ollowed by a sequence of attributes. The following is the format of the FLOOR-RE </section>
QUEST-INFORMATION-HEADER:</t> <section anchor="sec_format_attributes_floor-req-info" numbered="true" t
<t><figure title="FLOOR-REQUEST-INFORMATION-HEADER format" anchor="fig:f oc="include" removeInRFC="false" pn="section-5.2.15">
ormat:request-information-header"> <name slugifiedName="name-floor-request-information">FLOOR-REQUEST-INF
<artwork> ORMATION</name>
<t indent="0" pn="section-5.2.15-1">The FLOOR-REQUEST-INFORMATION attr
ibute 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 foll
owing is the format of the FLOOR-REQUEST-INFORMATION-HEADER:</t>
<figure anchor="fig_format_request-information-header" align="left" su
ppress-title="false" pn="figure-23">
<name slugifiedName="name-floor-request-information-h">FLOOR-REQUEST
-INFORMATION-HEADER format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.15-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.15-3">
<t>Floor Request ID: This field contains a 16-bit value that identifies <dt pn="section-5.2.15-3.1">Floor Request ID:</dt>
a floor request at the floor control server.</t> <dd pn="section-5.2.15-3.2">This field contains a 16-bit value
<t>The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped at that identifies a floor request at the floor control server.</dd>
tribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined </dl>
in the future.)</t> <t indent="0" pn="section-5.2.15-4">The following is the ABNF of the F
<t><figure title="FLOOR-REQUEST-INFORMATION format" anchor="fig:floor-re LOOR-REQUEST-INFORMATION
quest-information"> grouped attribute. (EXTENSION-ATTRIBUTE refers to extension
<artwork> attributes that may be defined in the future.)</t>
<figure anchor="fig_floor-request-information" align="left" suppress-t
itle="false" pn="figure-24">
<name slugifiedName="name-floor-request-information-f">FLOOR-REQUEST
-INFORMATION format</name>
<sourcecode name="" type="abnf" markers="false" pn="section-5.2.15-5
.1">
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=
"include" removeInRFC="false" pn="section-5.2.16">
<section title="REQUESTED-BY-INFORMATION" anchor="sec:format:attributes:re <name slugifiedName="name-requested-by-information">REQUESTED-BY-INFOR
q-by-info"> MATION</name>
<t>The REQUESTED-BY-INFORMATION attribute is a grouped attribute that co <t indent="0" pn="section-5.2.16-1">The REQUESTED-BY-INFORMATION attri
nsists of a header, which is referred to as REQUESTED-BY-INFORMATION-HEADER, fol bute is a grouped attribute that consists of a header, which is referred to as R
lowed by a sequence of attributes. The following is the format of the REQUESTED- EQUESTED-BY-INFORMATION-HEADER, followed by a sequence of attributes. The follow
BY-INFORMATION-HEADER:</t> ing is the format of the REQUESTED-BY-INFORMATION-HEADER:</t>
<t><figure title="REQUESTED-BY-INFORMATION-HEADER format" anchor="fig:fo <figure anchor="fig_format_req-by-information-header" align="left" sup
rmat:req-by-information-header"> press-title="false" pn="figure-25">
<artwork> <name slugifiedName="name-requested-by-information-he">REQUESTED-BY-
INFORMATION-HEADER format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.16-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.16-3">
<t>Requested-by ID: This field contains a 16-bit value that uniquely ide <dt pn="section-5.2.16-3.1">Requested-by ID:</dt>
ntifies a user within a conference.</t> <dd pn="section-5.2.16-3.2">This field contains a 16-bit value
<t>The following is the ABNF of the REQUESTED-BY-INFORMATION grouped att that uniquely identifies a user within a conference.</dd>
ribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined </dl>
in the future.)</t> <t indent="0" pn="section-5.2.16-4">The following is the ABNF of the R
<t><figure title="REQUESTED-BY-INFORMATION format" anchor="fig:reqby-inf EQUESTED-BY-INFORMATION grouped
ormation"> attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that
<artwork> may be defined in the future.)</t>
REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER <figure anchor="fig_reqby-information" align="left" suppress-title="fa
[USER-DISPLAY-NAME] lse" pn="figure-26">
[USER-URI] <name slugifiedName="name-requested-by-information-fo">REQUESTED-BY-
*EXTENSION-ATTRIBUTE INFORMATION format</name>
</artwork> <sourcecode name="" type="abnf" markers="false" pn="section-5.2.16-5
</figure></t> .1">
</section> REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER
[USER-DISPLAY-NAME]
<section title="FLOOR-REQUEST-STATUS" anchor="sec:format:attributes:floor- [USER-URI]
req-status"> *EXTENSION-ATTRIBUTE</sourcecode>
<t>The FLOOR-REQUEST-STATUS attribute is a grouped attribute that consis </figure>
ts of a header, which is referred to as FLOOR-REQUEST-STATUS-HEADER, followed by </section>
a sequence of attributes. The following is the format of the FLOOR-REQUEST-STAT <section anchor="sec_format_attributes_floor-req-status" numbered="true"
US-HEADER:</t> toc="include" removeInRFC="false" pn="section-5.2.17">
<t><figure title="FLOOR-REQUEST-STATUS-HEADER format" anchor="fig:format <name slugifiedName="name-floor-request-status">FLOOR-REQUEST-STATUS</
:floor-req-status-header"> name>
<artwork> <t indent="0" pn="section-5.2.17-1">The FLOOR-REQUEST-STATUS attribute
is a grouped attribute that consists of a header, which is referred to as FLOOR
-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is t
he format of the FLOOR-REQUEST-STATUS-HEADER:</t>
<figure anchor="fig_format_floor-req-status-header" align="left" suppr
ess-title="false" pn="figure-27">
<name slugifiedName="name-floor-request-status-header">FLOOR-REQUEST
-STATUS-HEADER format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.17-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.17-3">
<t>Floor ID: this field contains a 16-bit value that uniquely identifies <dt pn="section-5.2.17-3.1">Floor ID:</dt>
a floor within a conference.</t> <dd pn="section-5.2.17-3.2">this field contains a 16-bit value that
<t>The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribu uniquely identifies a floor within a conference.</dd>
te. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in t </dl>
he future.)</t> <t indent="0" pn="section-5.2.17-4">The following is the ABNF of the F
<t><figure title="FLOOR-REQUEST-STATUS format" anchor="fig:floor-req-sta LOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension
tus"> attributes that may be defined in the future.)</t>
<artwork> <figure anchor="fig_floor-req-status" align="left" suppress-title="fal
FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER se" pn="figure-28">
[REQUEST-STATUS] <name slugifiedName="name-floor-request-status-format">FLOOR-REQUEST
[STATUS-INFO] -STATUS format</name>
*EXTENSION-ATTRIBUTE <sourcecode name="" type="abnf" markers="false" pn="section-5.2.17-5
</artwork> .1">
</figure></t> FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER
</section> [REQUEST-STATUS]
[STATUS-INFO]
<section title="OVERALL-REQUEST-STATUS" anchor="sec:format:attributes:over *EXTENSION-ATTRIBUTE</sourcecode>
all-req-status"> </figure>
<t>The OVERALL-REQUEST-STATUS attribute is a grouped attribute that cons </section>
ists of a header, which is referred to as OVERALL-REQUEST-STATUS-HEADER, followe <section anchor="sec_format_attributes_overall-req-status" numbered="tru
d by a sequence of attributes. The following is the format of the OVERALL-REQUES e" toc="include" removeInRFC="false" pn="section-5.2.18">
T-STATUS-HEADER:</t> <name slugifiedName="name-overall-request-status">OVERALL-REQUEST-STAT
<t><figure title="OVERALL-REQUEST-STATUS-HEADER format" anchor="fig:form US</name>
at:overall-req-status-header"> <t indent="0" pn="section-5.2.18-1">The OVERALL-REQUEST-STATUS attribu
<artwork> te is a grouped attribute that consists of a header, which is referred to as OVE
RALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following
is the format of the OVERALL-REQUEST-STATUS-HEADER:</t>
<figure anchor="fig_format_overall-req-status-header" align="left" sup
press-title="false" pn="figure-29">
<name slugifiedName="name-overall-request-status-head">OVERALL-REQUE
ST-STATUS-HEADER format</name>
<artwork name="" type="" align="left" alt="" pn="section-5.2.18-2.1"
>
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 indent="3" newline="false" spacing="normal" pn="section-5.2.18-3">
<t>Floor Request ID: this field contains a 16-bit value that identifies <dt pn="section-5.2.18-3.1">Floor Request ID:</dt>
a floor request at the floor control server.</t> <dd pn="section-5.2.18-3.2">This field contains a 16-bit value that
<t>The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attri identifies a floor request at the floor control server.</dd>
bute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in </dl>
the future.)</t> <t indent="0" pn="section-5.2.18-4">The following is the ABNF of the O
<t><figure title="OVERALL-REQUEST-STATUS format" anchor="fig:overall-req VERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extensio
-status"> n attributes that may be defined in the future.)</t>
<artwork> <figure anchor="fig_overall-req-status" align="left" suppress-title="f
OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER alse" pn="figure-30">
[REQUEST-STATUS] <name slugifiedName="name-overall-request-status-form">OVERALL-REQUE
[STATUS-INFO] ST-STATUS format</name>
*EXTENSION-ATTRIBUTE <sourcecode name="" type="abnf" markers="false" pn="section-5.2.18-5
</artwork> .1">
</figure></t> OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER
[REQUEST-STATUS]
[STATUS-INFO]
*EXTENSION-ATTRIBUTE</sourcecode>
</figure>
</section>
</section> </section>
</section> <section anchor="sec_msg_format" numbered="true" toc="include" removeInRFC
="false" pn="section-5.3">
<section title="Message Format" anchor="sec:msg_format"> <name slugifiedName="name-message-format">Message Format</name>
<t>This section contains the normative ABNF (Augmented Backus-Naur Form) < <t indent="0" pn="section-5.3-1">This section contains the normative ABN
xref target="RFC5234"/> of the BFCP messages. Extension attributes that may be d F (Augmented Backus-Naur Form) <xref target="RFC5234" format="default" sectionFo
efined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.</t> rmat="of" derivedContent="5"/> of the BFCP messages. Extension attributes that m
ay be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.<
<section title="FloorRequest" anchor="sec:msg_format:FloorRequest"> /t>
<t>Floor participants request a floor by sending a FloorRequest message <section anchor="sec_msg_format_FloorRequest" numbered="true" toc="inclu
to the floor control server. The following is the format of the FloorRequest mes de" removeInRFC="false" pn="section-5.3.1">
sage:</t> <name slugifiedName="name-floorrequest">FloorRequest</name>
<t><figure title="FloorRequest format" anchor="fig:floorequest"> <t indent="0" pn="section-5.3.1-1">Floor participants request a floor
<artwork> by sending a FloorRequest message to the floor control server. The following is
the format of the FloorRequest message:</t>
<figure anchor="fig_floorequest" align="left" suppress-title="false" p
n="figure-31">
<name slugifiedName="name-floorrequest-format">FloorRequest format</
name>
<sourcecode name="" type="abnf" markers="false" pn="section-5.3.1-2.
1">
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="inclu
de" removeInRFC="false" pn="section-5.3.2">
<section title="FloorRelease" anchor="sec:msg_format:FloorRelease"> <name slugifiedName="name-floorrelease">FloorRelease</name>
<t>Floor participants release a floor by sending a FloorRelease message <t indent="0" pn="section-5.3.2-1">Floor participants release a floor
to the floor control server. Floor participants also use the FloorRelease messag by sending a FloorRelease message to the floor control server. Floor participant
e to cancel pending floor requests. The following is the format of the FloorRele s also use the FloorRelease message to cancel pending floor requests. The follow
ase message:</t> ing is the format of the FloorRelease message:</t>
<t><figure title="FloorRelease format" anchor="fig:floorelease"> <figure anchor="fig_floorelease" align="left" suppress-title="false" p
<artwork> n="figure-32">
FloorRelease = COMMON-HEADER <name slugifiedName="name-floorrelease-format">FloorRelease format</
FLOOR-REQUEST-ID name>
*EXTENSION-ATTRIBUTE <sourcecode name="" type="abnf" markers="false" pn="section-5.3.2-2.
</artwork> 1">
</figure></t> FloorRelease = COMMON-HEADER
</section> FLOOR-REQUEST-ID
*EXTENSION-ATTRIBUTE</sourcecode>
<section title="FloorRequestQuery" anchor="sec:msg_format:FloorRequestQuer </figure>
y"> </section>
<t>Floor participants and floor chairs request information about a floor <section anchor="sec_msg_format_FloorRequestQuery" numbered="true" toc="
request by sending a FloorRequestQuery message to the floor control server. The include" removeInRFC="false" pn="section-5.3.3">
following is the format of the FloorRequestQuery message:</t> <name slugifiedName="name-floorrequestquery">FloorRequestQuery</name>
<t><figure title="FloorRequestQuery format" anchor="fig:floorrequestinfo <t indent="0" pn="section-5.3.3-1">Floor participants and floor chairs
"> request information about a floor request by sending a FloorRequestQuery messag
<artwork> e to the floor control server. The following is the format of the FloorRequestQu
FloorRequestQuery = COMMON-HEADER ery message:</t>
FLOOR-REQUEST-ID <figure anchor="fig_floorrequestinfo" align="left" suppress-title="fal
*EXTENSION-ATTRIBUTE se" pn="figure-33">
</artwork> <name slugifiedName="name-floorrequestquery-format">FloorRequestQuer
</figure></t> y format</name>
</section> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.3-2.
1">
<section title="FloorRequestStatus" anchor="sec:msg_format:FloorRequestSta FloorRequestQuery = COMMON-HEADER
tus"> FLOOR-REQUEST-ID
<t>The floor control server informs floor participants and floor chairs *EXTENSION-ATTRIBUTE</sourcecode>
about the status of their floor requests by sending them FloorRequestStatus mess </figure>
ages. The following is the format of the FloorRequestStatus message:</t> </section>
<t><figure title="FloorRequestStatus format" anchor="fig:floorrequeststa <section anchor="sec_msg_format_FloorRequestStatus" numbered="true" toc=
tus"> "include" removeInRFC="false" pn="section-5.3.4">
<artwork> <name slugifiedName="name-floorrequeststatus">FloorRequestStatus</name
FloorRequestStatus = COMMON-HEADER >
FLOOR-REQUEST-INFORMATION <t indent="0" pn="section-5.3.4-1">The floor control server informs fl
*EXTENSION-ATTRIBUTE oor participants and floor chairs about the status of their floor requests by se
</artwork> nding them FloorRequestStatus messages. The following is the format of the Floor
</figure></t> RequestStatus message:</t>
</section> <figure anchor="fig_floorrequeststatus" align="left" suppress-title="f
alse" pn="figure-34">
<section title="UserQuery" anchor="sec:msg_format:UserQuery"> <name slugifiedName="name-floorrequeststatus-format">FloorRequestSta
<t>Floor participants and floor chairs request information about a parti tus format</name>
cipant and the floor requests related to this participant by sending a UserQuery <sourcecode name="" type="abnf" markers="false" pn="section-5.3.4-2.
message to the floor control server. The following is the format of the UserQue 1">
ry message:</t> FloorRequestStatus = COMMON-HEADER
<t><figure title="UserQuery format" anchor="fig:userinfowanted"> FLOOR-REQUEST-INFORMATION
<artwork> *EXTENSION-ATTRIBUTE</sourcecode>
UserQuery = COMMON-HEADER </figure>
[BENEFICIARY-ID] </section>
*EXTENSION-ATTRIBUTE <section anchor="sec_msg_format_UserQuery" numbered="true" toc="include"
</artwork> removeInRFC="false" pn="section-5.3.5">
</figure></t> <name slugifiedName="name-userquery">UserQuery</name>
</section> <t indent="0" pn="section-5.3.5-1">Floor participants and floor chairs
request information about a participant and the floor requests related to this
<section title="UserStatus" anchor="sec:msg_format:UserStatus"> participant by sending a UserQuery message to the floor control server. The foll
<t>The floor control server provides information about participants and owing is the format of the UserQuery message:</t>
their related floor requests to floor participants and floor chairs by sending t <figure anchor="fig_userinfowanted" align="left" suppress-title="false
hem UserStatus messages. The following is the format of the UserStatus message:< " pn="figure-35">
/t> <name slugifiedName="name-userquery-format">UserQuery format</name>
<t><figure title="UserStatus format" anchor="fig:userstatus"> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.5-2.
<artwork> 1">
UserStatus = COMMON-HEADER UserQuery = COMMON-HEADER
[BENEFICIARY-INFORMATION] [BENEFICIARY-ID]
*FLOOR-REQUEST-INFORMATION *EXTENSION-ATTRIBUTE</sourcecode>
*EXTENSION-ATTRIBUTE </figure>
</artwork> </section>
</figure></t> <section anchor="sec_msg_format_UserStatus" numbered="true" toc="include
</section> " removeInRFC="false" pn="section-5.3.6">
<name slugifiedName="name-userstatus">UserStatus</name>
<section title="FloorQuery" anchor="sec:msg_format:FloorQuery"> <t indent="0" pn="section-5.3.6-1">The floor control server provides i
<t>Floor participants and floor chairs request information about a floor nformation about participants and their related floor requests to floor particip
or floors by sending a FloorQuery message to the floor control server. The foll ants and floor chairs by sending them UserStatus messages. The following is the
owing is the format of the FloorQuery message:</t> format of the UserStatus message:</t>
<t><figure title="FloorQuery format" anchor="fig:floorinfo"> <figure anchor="fig_userstatus" align="left" suppress-title="false" pn
<artwork> ="figure-36">
FloorQuery = COMMON-HEADER <name slugifiedName="name-userstatus-format">UserStatus format</name
>
<sourcecode name="" type="abnf" markers="false" pn="section-5.3.6-2.
1">
UserStatus = COMMON-HEADER
[BENEFICIARY-INFORMATION]
*FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE</sourcecode>
</figure>
</section>
<section anchor="sec_msg_format_FloorQuery" numbered="true" toc="include
" removeInRFC="false" pn="section-5.3.7">
<name slugifiedName="name-floorquery">FloorQuery</name>
<t indent="0" pn="section-5.3.7-1">Floor participants and floor chairs
request information about a floor or floors by sending a FloorQuery message to
the floor control server. The following is the format of the FloorQuery message:
</t>
<figure anchor="fig_floorinfo" align="left" suppress-title="false" pn=
"figure-37">
<name slugifiedName="name-floorquery-format">FloorQuery format</name
>
<sourcecode name="" type="abnf" markers="false" pn="section-5.3.7-2.
1">
FloorQuery = COMMON-HEADER
*FLOOR-ID
*EXTENSION-ATTRIBUTE</sourcecode>
</figure>
</section>
<section anchor="sec_msg_format_FloorStatus" numbered="true" toc="includ
e" removeInRFC="false" pn="section-5.3.8">
<name slugifiedName="name-floorstatus">FloorStatus</name>
<t indent="0" pn="section-5.3.8-1">The floor control server informs fl
oor participants and floor chairs about the status (e.g., the current holder) of
a floor by sending them FloorStatus messages. The following is the format of th
e FloorStatus message:</t>
<figure anchor="fig_floorstatus" align="left" suppress-title="false" p
n="figure-38">
<name slugifiedName="name-floorstatus-format">FloorStatus format</na
me>
<sourcecode name="" type="abnf" markers="false" pn="section-5.3.8-2.
1">
FloorStatus = COMMON-HEADER
*FLOOR-ID *FLOOR-ID
*EXTENSION-ATTRIBUTE *FLOOR-REQUEST-INFORMATION
</artwork> *EXTENSION-ATTRIBUTE</sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="sec_msg_format_ChairAction" numbered="true" toc="includ
<section title="FloorStatus" anchor="sec:msg_format:FloorStatus"> e" removeInRFC="false" pn="section-5.3.9">
<t>The floor control server informs floor participants and floor chairs <name slugifiedName="name-chairaction">ChairAction</name>
about the status (e.g., the current holder) of a floor by sending them FloorStat <t indent="0" pn="section-5.3.9-1">Floor chairs send instructions to f
us messages. The following is the format of the FloorStatus message:</t> loor control servers by sending them ChairAction messages. The following is the
<t><figure title="FloorStatus format" anchor="fig:floorstatus"> format of the ChairAction message:</t>
<artwork> <figure anchor="fig_chairaction" align="left" suppress-title="false" p
FloorStatus = COMMON-HEADER n="figure-39">
*FLOOR-ID <name slugifiedName="name-chairaction-format">ChairAction format</na
*FLOOR-REQUEST-INFORMATION me>
*EXTENSION-ATTRIBUTE <sourcecode name="" type="abnf" markers="false" pn="section-5.3.9-2.
</artwork> 1">
</figure></t> ChairAction = COMMON-HEADER
</section> FLOOR-REQUEST-INFORMATION
*EXTENSION-ATTRIBUTE</sourcecode>
<section title="ChairAction" anchor="sec:msg_format:ChairAction"> </figure>
<t>Floor chairs send instructions to floor control servers by sending th </section>
em ChairAction messages. The following is the format of the ChairAction message: <section anchor="sec_msg_format_ChairActionAck" numbered="true" toc="inc
</t> lude" removeInRFC="false" pn="section-5.3.10">
<t><figure title="ChairAction format" anchor="fig:chairaction"> <name slugifiedName="name-chairactionack">ChairActionAck</name>
<artwork> <t indent="0" pn="section-5.3.10-1">Floor control servers confirm that
ChairAction = COMMON-HEADER they have accepted a ChairAction message by sending a ChairActionAck message. T
FLOOR-REQUEST-INFORMATION he following is the format of the ChairActionAck message:</t>
*EXTENSION-ATTRIBUTE <figure anchor="fig_chairactionack" align="left" suppress-title="false
</artwork> " pn="figure-40">
</figure></t> <name slugifiedName="name-chairactionack-format">ChairActionAck form
</section> at</name>
<sourcecode name="" type="abnf" markers="false" pn="section-5.3.10-2
<section title="ChairActionAck" anchor="sec:msg_format:ChairActionAck"> .1">
<t>Floor control servers confirm that they have accepted a ChairAction m ChairActionAck = COMMON-HEADER
essage by sending a ChairActionAck message. The following is the format of the C *EXTENSION-ATTRIBUTE</sourcecode>
hairActionAck message:</t> </figure>
<t><figure title="ChairActionAck format" anchor="fig:chairactionack"> </section>
<artwork> <section anchor="sec_msg_format_Hello" numbered="true" toc="include" rem
ChairActionAck = COMMON-HEADER oveInRFC="false" pn="section-5.3.11">
*EXTENSION-ATTRIBUTE <name slugifiedName="name-hello">Hello</name>
</artwork> <t indent="0" pn="section-5.3.11-1">Floor participants and floor chair
</figure></t> s <bcp14>MAY</bcp14> check the liveness of floor control servers by sending a He
</section> llo message. Additionally, clients communicating with a floor control server ov
er an unreliable transport use the Hello message to initiate communication with
<section title="Hello" anchor="sec:msg_format:Hello"> the server. The following is the format of the Hello message:</t>
<t>Floor participants and floor chairs MAY check the liveliness of floor <figure anchor="fig_hello" align="left" suppress-title="false" pn="fig
control servers by sending a Hello message. Additionally, clients communicatin ure-41">
g with a floor control server over a an unreliable transport use the Hello messa <name slugifiedName="name-hello-format">Hello format</name>
ge to initiate communication with the server. The following is the format of th <sourcecode name="" type="abnf" markers="false" pn="section-5.3.11-2
e Hello message:</t> .1">
<t><figure title="Hello format" anchor="fig:hello"> Hello = COMMON-HEADER
<artwork> *EXTENSION-ATTRIBUTE</sourcecode>
Hello = COMMON-HEADER </figure>
*EXTENSION-ATTRIBUTE </section>
</artwork> <section anchor="sec_msg_format_HelloAck" numbered="true" toc="include"
</figure></t> removeInRFC="false" pn="section-5.3.12">
</section> <name slugifiedName="name-helloack">HelloAck</name>
<t indent="0" pn="section-5.3.12-1">Floor control servers confirm that
<section title="HelloAck" anchor="sec:msg_format:HelloAck"> they are alive on reception of a Hello message by sending a HelloAck message. T
<t>Floor control servers confirm that they are alive on reception of a H he following is the format of the HelloAck message:</t>
ello message by sending a HelloAck message. The following is the format of the H <figure anchor="fig_helloack" align="left" suppress-title="false" pn="
elloAck message:</t> figure-42">
<t><figure title="HelloAck format" anchor="fig:helloack"> <name slugifiedName="name-helloack-format">HelloAck format</name>
<artwork> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.12-2
HelloAck = COMMON-HEADER .1">
SUPPORTED-PRIMITIVES HelloAck = COMMON-HEADER
SUPPORTED-ATTRIBUTES SUPPORTED-PRIMITIVES
*EXTENSION-ATTRIBUTE SUPPORTED-ATTRIBUTES
</artwork> *EXTENSION-ATTRIBUTE</sourcecode>
</figure></t> </figure>
</section> </section>
<section anchor="sec_msg_format_Error" numbered="true" toc="include" rem
<section title="Error" anchor="sec:msg_format:Error"> oveInRFC="false" pn="section-5.3.13">
<t>Floor control servers inform floor participants and floor chairs abou <name slugifiedName="name-error">Error</name>
t errors processing requests by sending them Error messages. The following is th <t indent="0" pn="section-5.3.13-1">Floor control servers inform floor
e format of the Error message:</t> participants and floor chairs about errors processing requests by sending them
<t><figure title="Error format" anchor="fig:error"> Error messages. The following is the format of the Error message:</t>
<artwork> <figure anchor="fig_error" align="left" suppress-title="false" pn="fig
Error = COMMON-HEADER ure-43">
ERROR-CODE <name slugifiedName="name-error-format">Error format</name>
[ERROR-INFO] <sourcecode name="" type="abnf" markers="false" pn="section-5.3.13-2
*EXTENSION-ATTRIBUTE .1">
</artwork> Error = COMMON-HEADER
</figure></t> ERROR-CODE
</section> [ERROR-INFO]
*EXTENSION-ATTRIBUTE</sourcecode>
<section title="FloorRequestStatusAck"> </figure>
<t>When communicating over an unreliable transport, floor participants a </section>
nd chairs acknowledge the receipt of a subsequent FloorRequestStatus message fro <section numbered="true" toc="include" removeInRFC="false" pn="section-5
m the floor control server (cf. <xref target="sec:server:request:subsequent"/>) .3.14">
by sending a FloorRequestStatusAck message. The following is the format of the F <name slugifiedName="name-floorrequeststatusack">FloorRequestStatusAck
loorRequestStatusAck message:</t> </name>
<t><figure align="left" anchor="FloorRequestStatusAck" title="FloorReque <t indent="0" pn="section-5.3.14-1">When communicating over an unrelia
stStatusAck format"> ble transport, floor participants and chairs acknowledge the receipt of a subseq
<artwork align="left"><![CDATA[ uent FloorRequestStatus message from the floor control server (cf. <xref target=
FloorRequestStatusAck = (COMMON-HEADER) "sec_server_request_subsequent" format="default" sectionFormat="of" derivedConte
*EXTENSION-ATTRIBUTE ]]></artwork> nt="Section 13.1.2"/>) by sending a FloorRequestStatusAck message. The following
</figure></t> is the format of the FloorRequestStatusAck message:</t>
</section> <figure anchor="FloorRequestStatusAck" align="left" suppress-title="fa
lse" pn="figure-44">
<section title="FloorStatusAck"> <name slugifiedName="name-floorrequeststatusack-forma">FloorRequestS
<t>When communicating over an unreliable transport, floor participants a tatusAck format</name>
nd chairs acknowledge the receipt of a subsequent FloorStatus message from the f <sourcecode name="" type="abnf" markers="false" pn="section-5.3.14-2
loor control server (cf. <xref target="sec:server:floorinfo:subsequent"/>) by se .1">
nding a FloorStatusAck message. The following is the format of the FloorStatusAc FloorRequestStatusAck = (COMMON-HEADER)
k message:</t> *EXTENSION-ATTRIBUTE</sourcecode>
<t><figure align="left" anchor="FloorStatusAck" title="FloorStatusAck fo </figure>
rmat"> </section>
<artwork align="left"><![CDATA[ <section numbered="true" toc="include" removeInRFC="false" pn="section-5
FloorStatusAck = (COMMON-HEADER) .3.15">
*EXTENSION-ATTRIBUTE ]]></artwork> <name slugifiedName="name-floorstatusack">FloorStatusAck</name>
</figure></t> <t indent="0" pn="section-5.3.15-1">When communicating over an unrelia
</section> ble transport, floor participants and chairs acknowledge the receipt of a subseq
uent FloorStatus message from the floor control server (cf. <xref target="sec_se
<section title="Goodbye"> rver_floorinfo_subsequent" format="default" sectionFormat="of" derivedContent="S
<t>BFCP entities communicating over an unreliable transport that wish to ection 13.5.2"/>) by sending a FloorStatusAck message. The following is the form
dissociate themselves from their remote participant do so through the transmiss at of the FloorStatusAck message:</t>
ion of a Goodbye. The following is the format of the Goodbye message:</t> <figure anchor="FloorStatusAck" align="left" suppress-title="false" pn
<t><figure align="left" anchor="Goodbye" title="Goodbye format"> ="figure-45">
<artwork align="left"><![CDATA[ <name slugifiedName="name-floorstatusack-format">FloorStatusAck form
Goodbye = (COMMON-HEADER) at</name>
*EXTENSION-ATTRIBUTE ]]></artwork> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.15-2
</figure></t> .1">
</section> FloorStatusAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE</sourcecode>
<section title="GoodbyeAck"> </figure>
<t>BFCP entities communicating over an unreliable transport acknowledge </section>
the receipt of a Goodbye message from a peer. The following is the format of the <section numbered="true" toc="include" removeInRFC="false" pn="section-5
GoodbyeAck message:</t> .3.16">
<t><figure align="left" anchor="GoodbyeAck" title="GoodbyeAck format"> <name slugifiedName="name-goodbye">Goodbye</name>
<artwork align="left"><![CDATA[ <t indent="0" pn="section-5.3.16-1">BFCP entities communicating over a
GoodbyeAck = (COMMON-HEADER) n unreliable transport that wish to dissociate themselves from their remote part
*EXTENSION-ATTRIBUTE ]]></artwork> icipant do so through the transmission of a Goodbye. The following is the format
</figure></t> of the Goodbye message:</t>
<figure anchor="Goodbye" align="left" suppress-title="false" pn="figur
e-46">
<name slugifiedName="name-goodbye-format">Goodbye format</name>
<sourcecode name="" type="abnf" markers="false" pn="section-5.3.16-2
.1">
Goodbye = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE</sourcecode>
</figure>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5
.3.17">
<name slugifiedName="name-goodbyeack">GoodbyeAck</name>
<t indent="0" pn="section-5.3.17-1">BFCP entities communicating over a
n unreliable transport acknowledge the receipt of a Goodbye message from a peer.
The following is the format of the GoodbyeAck message:</t>
<figure anchor="GoodbyeAck" align="left" suppress-title="false" pn="fi
gure-47">
<name slugifiedName="name-goodbyeack-format">GoodbyeAck format</name
>
<sourcecode name="" type="abnf" markers="false" pn="section-5.3.17-2
.1">
GoodbyeAck = (COMMON-HEADER)
*EXTENSION-ATTRIBUTE</sourcecode>
</figure>
</section>
</section> </section>
</section> </section>
</section> <section anchor="sec_transport" numbered="true" toc="include" removeInRFC="f
alse" pn="section-6">
<section title="Transport" anchor="sec:transport"> <name slugifiedName="name-transport">Transport</name>
<t>The transport over which BFCP entities exchange messages depends on the i <t indent="0" pn="section-6-1">The transport over which BFCP entities exch
nformation the clients obtain for how to to contact the floor control server, as ange messages depends on the information the clients obtain for contacting the f
described in <xref target="sec:scope:info"/>. Two transports are supported: TCP loor control server, as described in <xref target="sec_scope_info" format="defau
, appropriate where connectivity is not impeded by network elements such as NAT lt" sectionFormat="of" derivedContent="Section 3.2"/>. Two transports are suppor
devices or media relays; and UDP for those deployments where TCP may not be appl ted: TCP, which is appropriate where connectivity is not impeded by network elem
icable or appropriate.</t> ents such as NAT devices or media relays; and UDP for those deployments where TC
P may not be applicable or appropriate.</t>
<t><list style="empty"> <aside pn="section-6-2">
<t>Informational note: In practice, products are configured to try one t <t indent="0" pn="section-6-2.1">Note: In practice, products are configu
ransport first and use the other transport as a fallback. Whether TCP or UDP is red to try one transport first and then use the other transport as a fallback. W
chosen as underlying transport depends on the type of product and the deployment hether TCP or UDP is chosen as underlying transport depends on the type of produ
environment. See <xref target="app:motivation"/> for additional considerations. ct and the deployment environment. See <xref target="app_motivation" format="def
</t> ault" sectionFormat="of" derivedContent="Appendix B"/> for additional considerat
</list></t> ions.</t>
</aside>
<section anchor="tcp_transport" title="Reliable Transport"> <section anchor="tcp_transport" numbered="true" toc="include" removeInRFC=
<t>BFCP entities may elect to exchange BFCP messages using TCP connections "false" pn="section-6.1">
. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, <name slugifiedName="name-reliable-transport">Reliable Transport</name>
message framing needs to be implemented in the application layer. BFCP implemen <t indent="0" pn="section-6.1-1">BFCP entities may elect to exchange BFC
ts application-layer framing using TLV-encoded attributes.</t> P messages using TCP connections. TCP provides an in-order reliable delivery of
<t>A client MUST NOT use more than one TCP connection to communicate with a stream of bytes. Consequently, message framing needs to be implemented in the
a given floor control server within a conference. Nevertheless, if the same phys application layer. BFCP implements application-layer framing using TLV-encoded a
ical box handles different clients (e.g., a floor chair and a floor participant) ttributes.</t>
, which are identified by different User IDs, a separate connection per client i <t indent="0" pn="section-6.1-2">A client <bcp14>MUST NOT</bcp14> use mo
s allowed.</t> re than one TCP connection to communicate with a given floor control server with
<t>If a BFCP entity (a client or a floor control server) receives data tha in a conference. Nevertheless, if the same physical box handles different client
t cannot be parsed, the entity MUST close the TCP connection, and the connection s (e.g., a floor chair and a floor participant), which are identified by differe
SHOULD be reestablished. Similarly, if a TCP connection cannot deliver a BFCP m nt User IDs, a separate connection per client is allowed.</t>
essage and times out or receives an ICMP port unreachable message mid-connection <t indent="0" pn="section-6.1-3">If a BFCP entity (a client or a floor c
, the TCP connection SHOULD be reestablished.</t> ontrol server) receives data that cannot be parsed, the entity <bcp14>MUST</bcp1
<t>The way connection reestablishment is handled depends on how the client 4> close the TCP connection, and the connection <bcp14>SHOULD</bcp14> be reestab
obtains information to contact the floor control server. Once the TCP connectio lished. Similarly, if a TCP connection cannot deliver a BFCP message and times o
n is reestablished, the client MAY resend those messages for which it did not ge ut or receives an ICMP port unreachable message mid-connection, the TCP connecti
t a response from the floor control server.</t> on <bcp14>SHOULD</bcp14> be reestablished.</t>
<t>If a floor control server detects that the TCP connection towards one o <t indent="0" pn="section-6.1-4">The way connection reestablishment is h
f the floor participants is lost, it is up to the local policy of the floor cont andled depends on how the client obtains information to contact the floor contro
rol server what to do with the pending floor requests of the floor participant. l server. Once the TCP connection is reestablished, the client <bcp14>MAY</bcp14
In any case, it is RECOMMENDED that the floor control server keep the floor requ > resend those messages for which it did not get a response from the floor contr
ests (i.e., that it does not cancel them) while the TCP connection is reestablis ol server.</t>
hed.</t> <t indent="0" pn="section-6.1-5">If a floor control server detects that
<t>If a client wishes to end its BFCP connection with a floor control serv the TCP connection towards one of the floor participants is lost, it is up to th
er, the client closes (i.e., a graceful close) the TCP connection towards the fl e local policy of the floor control server what to do with the pending floor req
oor control server. If a floor control server wishes to end its BFCP connection uests of the floor participant. In any case, it is <bcp14>RECOMMENDED</bcp14> th
with a client (e.g., the Focus of the conference informs the floor control serv at the floor control server keep the floor requests (i.e., that it does not canc
er that the client has been kicked out from the conference), the floor control s el them) while the TCP connection is reestablished.</t>
erver closes (i.e., a graceful close) the TCP connection towards the client.</t> <t indent="0" pn="section-6.1-6">If a client wishes to end its BFCP conn
<t>In cases where a BFCP entity reestablishes a connection due to protocol ection with a floor control server, the client closes (i.e., a graceful close) t
errors as described above, the entity SHOULD NOT repeatedly reestablish the con he TCP connection towards the floor control server. If a floor control server w
nection. Rather, if the same protocol errors persist, the entity MUST cease att ishes to end its BFCP connection with a client (e.g., the focus of the conferenc
empts and SHOULD report the error to the human user and/or log the event. This e informs the floor control server that the client has been kicked out of the co
does not preclude the entity from reestablishing a connection when facing a diff nference), the floor control server closes (i.e., a graceful close) the TCP conn
erent set of errors. That said, entities MUST avoid overloading the server with ection towards the client.</t>
reestablishment requests. A connection MUST NOT be reestablished too frequentl <t indent="0" pn="section-6.1-7">In cases where a BFCP entity reestablis
y. The frequency is a matter of implementation, but SHOULD NOT be attempted mor hes a connection due to protocol errors as described above, the entity <bcp14>SH
e than once in a 30 second period of time.</t> OULD NOT</bcp14> repeatedly reestablish the connection. Rather, if the same pro
</section> tocol errors persist, the entity <bcp14>MUST</bcp14> cease attempts and <bcp14>S
HOULD</bcp14> report the error to the human user and/or log the event. This doe
<section anchor="udp_transport" title="Unreliable Transport"> s not preclude the entity from reestablishing a connection when facing a differe
<t>BFCP entities may elect to exchange BFCP messages using UDP datagrams. nt set of errors. That said, entities <bcp14>MUST</bcp14> avoid overloading the
UDP is an unreliable transport where neither delivery nor ordering is assured. E server with reestablishment requests. A connection <bcp14>MUST NOT</bcp14> be
ach BFCP UDP datagram MUST contain exactly one BFCP message or message fragment. reestablished too frequently. The frequency is a matter of implementation, but
To keep large BFCP messages from being fragmented at the IP layer, the fragment <bcp14>SHOULD NOT</bcp14> be attempted more than once in a 30 second period of t
ation of BFCP messages that exceed the path MTU size is performed at the BFCP le ime.</t>
vel. Considerations related to fragmentation are covered in <xref target="fragme
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 anchor="icmp" title="ICMP Error Handling">
<t>ICMP is not usable when BFCP is running over an unreliable transport
due to risks associated with off-path attacks. Any ICMP messages associated wit
h BFCP running over an unreliable transport MUST be ignored.</t>
</section>
<section anchor="fragmentation_handling" title="Fragmentation Handling">
<t>When using UDP, a single BFCP message could be fragmented at the IP l
ayer if its overall size exceeds the path MTU of the network. To avoid this happ
ening 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 binary
encoding as described in <xref target="sec:intro"/>. The fragmentation scheme is
therefore deliberately kept simple and straightforward, since the probability o
f fragmentation of BFCP messages being required is small. By design, the fragmen
tation scheme does not acknowledge individual BFCP message fragments. The whole
BFCP message is acknowledged if received completely.</t>
<t>BFCP entities SHOULD consider the path MTU size available between the
sender and the receiver and MAY run MTU discovery, such as <xref target="RFC119
1"/><xref target="RFC1981"/><xref target="RFC4821"/>, for this purpose.</t>
<t>When transmitting a BFCP message with size greater than the path MTU,
the sender MUST fragment the message into a series of N contiguous data ranges.
The size of each of these N messages MUST be smaller than the path MTU to help
prevent fragmentation overlap attacks. The value for N is defined as ceil((mess
age size - COMMON-HEADER size) / (path MTU size - COMMON-HEADER size)), where ce
il is the integer ceiling function and the COMMON-HEADER size includes the Fragm
ent 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 eac
h of these N messages, with the COMMON-HEADER included, MUST be smaller than the
path MTU. The F flag in the COMMON-HEADER in all the fragments is set to indica
te fragmentation of the BFCP message.</t>
<t>For each of these fragments the Fragment Offset and Fragment Length f
ields are included in the COMMON-HEADER. The Fragment Offset field denotes the n
umber of 4-octet units contained in the previous fragments, excluding the common
header. The Fragment Length contains the length of the fragment itself, also ex
cluding the common header. Note that the Payload Length field contains the lengt
h of the entire, unfragmented message.</t>
<t>When a BFCP implementation receives a BFCP message fragment, it MUST
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
e BFCP message only after all the fragments for the message have been received.<
/t>
<t>If a fragment of a BFCP message is lost, the sender will not receive
an acknowledgement for the message. Therefore the sender will retransmit the mes
sage with same transaction ID as specified in <xref target="timers"/>. If the ac
knowledgement message sent by the receiver is lost, then the entire message will
be resent by the sender. The receiver MUST then retransmit the acknowledgement.
The receiver MAY discard an incomplete buffer utilizing the Response Retransmis
sion Timer, starting the timer after the receipt of the first fragment.</t>
<t><list style="empty">
<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 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="udp_transport" numbered="true" toc="include" removeInRFC=
<section anchor="nat_traversal" title="NAT Traversal"> "false" pn="section-6.2">
<t>One of the key benefits when using UDP for BFCP communication is the <name slugifiedName="name-unreliable-transport">Unreliable Transport</na
ability to leverage the existing NAT traversal infrastructure and strategies dep me>
loyed to facilitate transport of the media associated with the video conferencin <t indent="0" pn="section-6.2-1">BFCP entities may elect to exchange BFC
g sessions. Depending on the given deployment, this infrastructure typically inc P messages using UDP datagrams. UDP is an unreliable transport where neither del
ludes some subset of ICE <xref target="RFC5245"/>.</t> ivery nor ordering is assured. Each BFCP UDP datagram <bcp14>MUST</bcp14> contai
<t>In order to facilitate the initial establishment of NAT bindings, and n exactly one BFCP message or message fragment. To keep large BFCP messages from
to maintain those bindings once established, BFCP entities using an unreliable being fragmented at the IP layer, the fragmentation of BFCP messages that excee
transport are RECOMMENDED to use STUN <xref target="RFC5389"/> Binding Indicatio d the path MTU size is performed at the BFCP level. Considerations related to fr
n for keep-alives, as described for ICE <xref target="RFC5245"/>. Section 6.7 of agmentation are covered in <xref target="fragmentation_handling" format="default
<xref target="RFC5763"/> provides useful recommendations for middlebox interact " sectionFormat="of" derivedContent="Section 6.2.3"/>. The message format for BF
ion when DTLS is used.</t> CP messages is the same regardless of whether the messages are sent in UDP datag
<t><list style="empty"> rams or over a TCP stream.</t>
<t>Informational note: Since the version number is set to 2 when BFC <t indent="0" pn="section-6.2-2">Clients <bcp14>MUST</bcp14> announce th
P is used over an unreliable transport, cf. the Ver field in <xref target="sec:f eir presence to the floor control server by sending a Hello message. The floor c
ormat:common"/>, it is straight forward to distinguish between STUN and BFCP pac ontrol server responds to the Hello message with a HelloAck message. The client
kets even without checking the STUN magic cookie <xref target="RFC5389"/>.</t> considers the floor control server as present and available only upon receiving
</list></t> the HelloAck message. The behavior when timers fire, including the determination
<t>In order to facilitate traversal of BFCP packets through NATs, BFCP e that a connection is broken, is described in <xref target="timers" format="defa
ntities using an unreliable transport are RECOMMENDED to use symmetric ports for ult" sectionFormat="of" derivedContent="Section 8.3"/>.</t>
sending and receiving BFCP packets, as recommended for RTP/RTCP <xref target="R <t indent="0" pn="section-6.2-3">As described in <xref target="sec_trans
FC4961"/>.</t> actions" format="default" sectionFormat="of" derivedContent="Section 8"/>, each
request sent by a floor participant or chair forms a client transaction that exp
ects an acknowledgement message from the floor control server within a transacti
on failure window. Concordantly, messages sent by the floor control server tha
t initiate new transactions (e.g., FloorStatus announcements as part of a FloorQ
uery subscription) require acknowledgement messages from the floor participant a
nd chair entities to which they were sent.</t>
<t indent="0" pn="section-6.2-4">If a floor control server receives data
that cannot be parsed, the receiving server <bcp14>MUST</bcp14> send an Error m
essage with parameter value 10 (Unable to Parse Message) indicating receipt of a
malformed message, given that it is possible to parse the received message to s
uch an extent that an Error message may be built.</t>
<t indent="0" pn="section-6.2-5">Entities <bcp14>MUST</bcp14> have at mo
st one outstanding request transaction per peer at any one time. Implicit subsc
riptions occur for a client-initiated request transaction whose acknowledgement
is implied by the first server-initiated response for that transaction, followed
by zero of more subsequent server-initiated messages corresponding to the same
transaction. An example is a FloorRequest message for which there are potentiall
y multiple responses from the floor control server as it processes intermediate
states until a terminal state (e.g., Granted or Denied) is attained. The subsequ
ent changes in state for the request are new transactions whose Transaction ID i
s determined by the floor control server and whose receipt by the client partici
pant is acknowledged with a FloorRequestStatusAck message.</t>
<t indent="0" pn="section-6.2-6">By restricting entities to having at mo
st one pending transaction open in a BFCP connection, both the out-of-order rece
ipt of messages as well as the possibility for congestion are mitigated. Additio
nal details regarding congestion control are provided in <xref target="congestio
n" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>.
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 indent="0" pn="section-6.2-7">If a client wishes to end its BFCP conn
ection with a floor control server, it is <bcp14>REQUIRED</bcp14> that the clien
t send a Goodbye message to dissociate itself from any allocated resources. If a
floor control server wishes to end its BFCP connection with a client (e.g., the
focus of the conference informs the floor control server that the client has be
en kicked out from the conference), it is <bcp14>REQUIRED</bcp14> that the floor
control server send a Goodbye message towards the client.</t>
<section anchor="congestion" numbered="true" toc="include" removeInRFC="
false" pn="section-6.2.1">
<name slugifiedName="name-congestion-control">Congestion Control</name
>
<t indent="0" pn="section-6.2.1-1">BFCP may be characterized as genera
ting "low data-volume" traffic, per the classification in <xref target="RFC8085"
format="default" sectionFormat="of" derivedContent="15"/>. Nevertheless, it is
necessary to ensure that suitable and necessary congestion control mechanisms ar
e used for BFCP over UDP. As described in <xref target="udp_transport" format="d
efault" sectionFormat="of" derivedContent="Section 6.2"/>, within the same BFCP
connection, every entity -- client or server -- is only allowed to send one requ
est at a time, and await the acknowledging response. This way, at most one datag
ram is sent per RTT given the message is not lost during transmission. If the me
ssage is lost, the request retransmission timer T1 specified in <xref target="ti
mers_retrans" format="default" sectionFormat="of" derivedContent="Section 8.3.1"
/> will fire, and the message is retransmitted up to three times, in addition to
the original transmission of the message. The default initial interval <bcp14>M
UST</bcp14> be set to 500 ms, but is adjusted dynamically as described in <xref
target="timers_retrans" format="default" sectionFormat="of" derivedContent="Sect
ion 8.3.1"/>. The interval <bcp14>MUST</bcp14> be doubled after each retransmis
sion attempt. This is similar to the specification of the timer A and its initia
l value T1 in SIP as described in <xref target="RFC3261" section="17.1.1.2" sect
ionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3261#
section-17.1.1.2" derivedContent="20"/>, except that the value of T1 in this pro
tocol is not fixed from one transaction to another.</t>
</section>
<section anchor="icmp" numbered="true" toc="include" removeInRFC="false"
pn="section-6.2.2">
<name slugifiedName="name-icmp-error-handling">ICMP Error Handling</na
me>
<t indent="0" pn="section-6.2.2-1">ICMP is not usable when BFCP is run
ning over an unreliable transport
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="include" r
emoveInRFC="false" pn="section-6.2.3">
<name slugifiedName="name-fragmentation-handling">Fragmentation Handli
ng</name>
<t indent="0" pn="section-6.2.3-1">When using UDP, a single BFCP messa
ge could be fragmented at the IP layer if its overall size exceeds the path MTU
of the network. To avoid this happening at the IP layer, a fragmentation scheme
for BFCP is defined below.</t>
<t indent="0" pn="section-6.2.3-2">BFCP is designed for achieving smal
l message size, due to the binary encoding as described in <xref target="sec_int
ro" format="default" sectionFormat="of" derivedContent="Section 1"/>. The fragme
ntation scheme is therefore deliberately kept simple and straightforward, since
the probability of fragmentation of BFCP messages is small. By design, the fragm
entation scheme does not acknowledge individual BFCP message fragments. The whol
e BFCP message is acknowledged if received completely.</t>
<t indent="0" pn="section-6.2.3-3">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" sectionFormat="of" derivedContent="25"/>, <xref target="RFC8201" format
="default" sectionFormat="of" derivedContent="26"/>, and <xref target="RFC4821"
format="default" sectionFormat="of" derivedContent="27"/>, for this purpose.</t>
<t indent="0" pn="section-6.2.3-4">When transmitting a BFCP message wi
th a size greater than the path MTU, the sender <bcp14>MUST</bcp14> fragment the
message into a series of N contiguous data ranges. The size of each of these N
messages <bcp14>MUST</bcp14> be smaller than the path MTU to help prevent fragm
entation overlap attacks. The value for N is defined as ceil((message size -- CO
MMON-HEADER size) / (path MTU size -- COMMON-HEADER size)), where ceil is the in
teger ceiling function, and the COMMON-HEADER size includes the Fragment Offset
and Fragment Length fields. The sender then creates N BFCP fragment messages (o
ne for each data range) with the same Transaction ID. The size of each of these
N messages, with the COMMON-HEADER included, <bcp14>MUST</bcp14> be smaller than
the path MTU. The F flag in the COMMON-HEADER in all the fragments is set to in
dicate fragmentation of the BFCP message.</t>
<t indent="0" pn="section-6.2.3-5">For each of these fragments, the Fr
agment Offset and Fragment Length fields are included in the COMMON-HEADER. The
Fragment Offset field denotes the number of 4-octet units contained in the previ
ous fragments, excluding the COMMON-HEADER. The Fragment Length contains the len
gth of the fragment itself, also excluding the COMMON-HEADER. Note that the Payl
oad Length field contains the length of the entire, unfragmented message.</t>
<t indent="0" pn="section-6.2.3-6">When a BFCP implementation receives
a BFCP message fragment, it <bcp14>MUST</bcp14> buffer the fragment until eithe
r it has received the entire BFCP message, or until the Response Retransmission
Timer expires. The state machine should handle the BFCP message only after all t
he fragments of the message have been received.</t>
<t indent="0" pn="section-6.2.3-7">If a fragment of a BFCP message is
lost, the sender will not receive an acknowledgement for the message. Therefore
the sender will retransmit the message with same transaction ID as specified in
<xref target="timers" format="default" sectionFormat="of" derivedContent="Sectio
n 8.3"/>. 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 pn="section-6.2.3-8">
<t indent="0" pn="section-6.2.3-8.1">A Denial of Service (DoS) attac
k utilizing the fragmentation scheme described above is mitigated by the fact th
at the Response Retransmission Timer 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 Length fields to verify the message fragments as t
hey arrive. To make DoS attacks with spoofed IP addresses difficult, BFCP entiti
es <bcp14>SHOULD</bcp14> use the cookie exchange mechanism in DTLS <xref target=
"RFC6347" format="default" sectionFormat="of" derivedContent="8"/>.</t>
</aside>
<t indent="0" pn="section-6.2.3-9">When deciding the size of the messa
ge fragment based on path MTU, the BFCP fragmentation handling should take into
account how the DTLS record framing expands the datagram size as described in <x
ref target="RFC6347" section="4.1.1.1" sectionFormat="of" format="default" deriv
edLink="https://rfc-editor.org/rfc/rfc6347#section-4.1.1.1" derivedContent="8"/>
.</t>
</section>
<section anchor="nat_traversal" numbered="true" toc="include" removeInRF
C="false" pn="section-6.2.4">
<name slugifiedName="name-nat-traversal">NAT Traversal</name>
<t indent="0" pn="section-6.2.4-1">One of the key benefits of using UD
P for BFCP communication is the ability to leverage the existing NAT traversal i
nfrastructure and strategies deployed to facilitate transport of the media assoc
iated with the video conferencing sessions. Depending on the given deployment, t
his infrastructure typically includes some subset of Interactive Connectivity Es
tablishment (ICE) <xref target="RFC8445" format="default" sectionFormat="of" der
ivedContent="16"/>.</t>
<t indent="0" pn="section-6.2.4-2">In order to facilitate the initial
establishment of NAT bindings, and to maintain those bindings once established,
BFCP entities using an unreliable transport are <bcp14>RECOMMENDED</bcp14> to us
e STUN <xref target="RFC5389" format="default" sectionFormat="of" derivedContent
="14"/> Binding Indication for keepalives, as described for ICE <xref target="RF
C8445" format="default" sectionFormat="of" derivedContent="16"/>. <xref target="
RFC5763" section="6.7" sectionFormat="of" format="default" derivedLink="https://
rfc-editor.org/rfc/rfc5763#section-6.7" derivedContent="28"/> provides useful re
commendations for middlebox interaction when DTLS is used.</t>
<aside pn="section-6.2.4-3">
<t indent="0" pn="section-6.2.4-3.1">Note: Since the version number
is set to 2 when BFCP is used over an unreliable transport, cf. the Ver field in
<xref target="sec_format_common" format="default" sectionFormat="of" derivedCon
tent="Section 5.1"/>, it is straightforward to distinguish between STUN and BFCP
packets even without checking the STUN magic cookie <xref target="RFC5389" form
at="default" sectionFormat="of" derivedContent="14"/>.</t>
</aside>
<t indent="0" pn="section-6.2.4-4">In order to facilitate traversal of
BFCP packets through NATs, BFCP entities using an unreliable transport are <bcp
14>RECOMMENDED</bcp14> to use symmetric ports for sending and receiving BFCP pac
kets, as recommended for RTP/RTP Control Protocol (RTCP) <xref target="RFC4961"
format="default" sectionFormat="of" derivedContent="13"/>.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="sec_lower-security" numbered="true" toc="include" removeInR
FC="false" pn="section-7">
<section title="Lower-Layer Security" anchor="sec:lower-security"> <name slugifiedName="name-lower-layer-security">Lower-Layer Security</name
<t>BFCP relies on lower-layer security mechanisms to provide replay and inte >
grity protection and confidentiality. BFCP floor control servers and clients (w <t indent="0" pn="section-7-1">BFCP relies on lower-layer security mechani
hich include both floor participants and floor chairs) MUST support TLS for tran sms to provide replay and integrity protection and confidentiality. BFCP floor
sport over TCP <xref target="RFC5246"/> and MUST support DTLS <xref target="RFC6 control servers and clients (which include both floor participants and floor cha
347"/> for transport over UDP. Any BFCP entity MAY support other security mechan irs) <bcp14>MUST</bcp14> support TLS for transport over TCP <xref target="RFC844
isms.</t> 6" format="default" sectionFormat="of" derivedContent="11"/> and <bcp14>MUST</bc
<t>BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SH p14> support DTLS <xref target="RFC6347" format="default" sectionFormat="of" der
A cipher suite <xref target="RFC5246"/> for backwards compatibility with existin ivedContent="8"/> for transport over UDP. Any BFCP entity <bcp14>MAY</bcp14> sup
g implementations of RFC 4582. In accordance with the recommendations and guidel port other security mechanisms.</t>
ines in <xref target="RFC7525"/>, BFCP entities SHOULD support the following cip <t indent="0" pn="section-7-2">BFCP entities <bcp14>MUST</bcp14> support,
her suites:</t> at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite <xref target="RFC524
<t><list style="symbols"> 6" format="default" sectionFormat="of" derivedContent="7"/> for backwards compat
<t>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</t> ibility with existing implementations of RFC 4582. In accordance with the recomm
<t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t> endations and guidelines in <xref target="RFC7525" format="default" sectionForma
<t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</t> t="of" derivedContent="30"/>, BFCP entities <bcp14>SHOULD</bcp14> support the fo
<t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</t> llowing cipher suites:</t>
</list></t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-3
</section> ">
<li pn="section-7-3.1">TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</li>
<section title="Protocol Transactions" anchor="sec:transactions"> <li pn="section-7-3.2">TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li>
<t>In BFCP, there are two types of transactions: client-initiated transactio <li pn="section-7-3.3">TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</li>
ns and server-initiated transactions.</t> <li pn="section-7-3.4">TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</li>
<t>Client-initiated transactions consist of a request from a client to a flo </ul>
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>A client starting a client-initiated transaction MUST set the Conferenc
e ID in the common header of the message to the Conference ID for the conference
that the client obtained previously.</t>
<t>The client MUST set the Transaction ID value in the common header to a
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>A floor control server sending a response within a client-initiated tra
nsaction MUST copy the Conference ID, the Transaction ID, and the User ID from t
he request received from the client into the response.</t>
<t>Server-initiated transactions MUST contain a Transaction ID equal to 0
when BFCP is used over a reliable transport. Over an unreliable transport, the T
ransaction ID shall have the same properties as for client-initiated transaction
s. The server uses the Transaction ID value to match this message with the respo
nse from the floor participant or floor chair.</t>
</section> </section>
<section anchor="sec_transactions" numbered="true" toc="include" removeInRFC
<section anchor="timers" title="Timers"> ="false" pn="section-8">
<t>When BFCP entities are communicating over an unreliable transport, two <name slugifiedName="name-protocol-transactions">Protocol Transactions</na
retransmission timers are employed to help mitigate against loss of datagrams. R me>
etransmission and response caching are not required when BFCP entities communica <t indent="0" pn="section-8-1">In BFCP, there are two types of transaction
te over a reliable transport.</t> s: client-initiated transactions and server-initiated transactions.</t>
<t indent="0" pn="section-8-2">Client-initiated transactions consist of a
<section anchor="timers_retrans" title="Request Retransmission Timer, T1"> request from a client to a floor control server and a response from the floor co
<t>T1 is a timer that schedules retransmission of a request until an app ntrol server to the client.</t>
ropriate response is received or until the maximum number of retransmissions hav <t indent="0" pn="section-8-3">Server-initiated transactions have differen
e occurred. The timer is computed using the smoothed round-trip time algorithm d t requirements and behavior depending on underlying transport:</t>
efind in <xref target="RFC2988"/> with an initial retransmission timeout (RTO) v <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-8-4"
alue of 500ms and clock granularity (G) of 100ms. In contrast to step 2.4 of Se >
ction 2 of <xref target="RFC2988"/>, if the computed value of RTO is less than 5 <li pn="section-8-4.1">When using a reliable transport, server-initiated
00ms, then RTO shall be set to 500ms. Timer T1 MUST be adjusted with the recept transactions consist of a single message from a floor control server to a clien
ion of a response to each request transmitted in order to compute an accurate RT t (notifications). They do not trigger any response.</li>
O value, which is the effective T1 value. The RTT value R is the time in millis <li pn="section-8-4.2">When using an unreliable transport, server-initia
econds from the point when a request is transmitted to the time the initial resp ted transactions consist of a request from a floor control server to a client an
onse to that request is received. Responses to retransmitted packets MUST NOT b d a response from the client to the floor control server.</li>
e used to recompute the RTO value, as one cannot determine if a response is to a </ul>
n initial or retransmitted request. If T1 always expires on the initial transmi <t indent="0" pn="section-8-5">When using BFCP over an unreliable transpor
ssion of a new request, this would suggest the recommended initial T1 (and RTO) t, retransmission timer T1 (see <xref target="timers" format="default" sectionFo
value is too low and SHOULD be increased by doubling the initial values of T1 (a rmat="of" derivedContent="Section 8.3"/>) <bcp14>MUST</bcp14> be used for all re
nd RTO) until T1 does not expire when sending a new request.</t> quests until the transaction is completed. Note that while T1 varies over time,
<t>When retransmitting a request, timer T1 is doubled with each retransm it remains constant for the duration of a given transaction and is only updated
ission, failing after three unacknowledged retransmission attempts.</t> at the completion of a transaction.</t>
<t>If a valid response is not received for a client- or server-initiated <section anchor="sec_transactions_client" numbered="true" toc="include" re
transaction, the implementation MUST consider the BFCP connection as broken. Im moveInRFC="false" pn="section-8.1">
plementations SHOULD follow the reestablishment procedure described in section 6 <name slugifiedName="name-client-behavior">Client Behavior</name>
.</t> <t indent="0" pn="section-8.1-1">A client starting a client-initiated tr
ansaction <bcp14>MUST</bcp14> set the Conference ID in the COMMON-HEADER of the
message to the Conference ID for the conference that the client obtained previou
sly.</t>
<t indent="0" pn="section-8.1-2">The client <bcp14>MUST</bcp14> set the
Transaction ID value in the COMMON-HEADER to a number that is different from 0 a
nd that <bcp14>MUST NOT</bcp14> be reused in another message from the client unt
il a response from the server is received for the transaction. The client uses t
he Transaction ID value to match this message with the response from the floor c
ontrol server. When using BFCP over an unreliable transport, it is important to
choose a Transaction ID value that lets the receiver distinguish the reception o
f the next message in a sequence of BFCP messages from a retransmission of a pre
vious message. Therefore, BFCP entities using an unreliable transport <bcp14>MUS
T</bcp14> use monotonically increasing Transaction ID values (except for wrap-ar
ound).</t>
<t indent="0" pn="section-8.1-3">A client receiving a server-initiated t
ransaction 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="include" re
<section anchor="timers_cache" title="Response Retransmission Timer, T2"> moveInRFC="false" pn="section-8.2">
<t>T2 is a timer that, when fired, signals that the BFCP entity can rele <name slugifiedName="name-server-behavior">Server Behavior</name>
ase knowledge of the transaction against which it is running. It is started upon <t indent="0" pn="section-8.2-1">A floor control server sending a respon
the first transmission of the response to a request and is the only mechanism b se within a client-initiated transaction <bcp14>MUST</bcp14> copy the Conference
y which that response is released by the BFCP entity. Any subsequent retransmiss ID, the Transaction ID, and the User ID from the request received from the clie
ions of the same request can be responded to by replaying the cached response, w nt into the response.</t>
hilst that value is retained until the timer has fired. Refer to <xref target="f <t indent="0" pn="section-8.2-2">Server-initiated transactions <bcp14>MU
ragmentation_handling"/> for the role this timer has in the fragmentation handli ST</bcp14> contain a Transaction ID equal to zero when BFCP is used over a relia
ng scheme.</t> ble transport. Over an unreliable transport, the Transaction ID shall have the s
ame properties as for client-initiated transactions. The server uses the Transac
tion ID value to match this message with the response from the floor participant
or floor chair.</t>
</section> </section>
<section anchor="timers" numbered="true" toc="include" removeInRFC="false"
<section anchor="timers_values" title="Timer Values"> pn="section-8.3">
<t>The table below defines the different timers required when BFCP entit <name slugifiedName="name-timers">Timers</name>
ies communicate over an unreliable transport.</t> <t indent="0" pn="section-8.3-1">When BFCP entities are communicating ov
<texttable anchor="timertable" title="Timers"> er an unreliable transport, two retransmission timers are employed to help mitig
<ttcol align='center'>Timer</ttcol> ate the loss of datagrams. Retransmission and response caching are not required
<ttcol align='left'>Description</ttcol> when BFCP entities communicate over a reliable transport.</t>
<ttcol align='center'>Value/s</ttcol> <section anchor="timers_retrans" numbered="true" toc="include" removeInR
<c>T1</c> <c>Initial request retransmission timer</c> <c>0.5s (initial) FC="false" pn="section-8.3.1">
</c> <name slugifiedName="name-request-retransmission-time">Request Retrans
<c>T2</c> <c>Response retransmission timer</c> <c>(T1*2^4)*1.25< mission Timer, T1</name>
/c> <t indent="0" pn="section-8.3.1-1">T1 is a timer that schedules retran
</texttable> smission of a request until an appropriate response is received or until the max
<t></t> imum number of retransmissions has occurred. The timer is computed using the smo
<t>The initial value for T1 is 500ms, which is an estimate of the RTT fo othed round-trip time algorithm defined in <xref target="RFC6298" format="defaul
r completing the transaction. Computation of this value follows the procedures t" sectionFormat="of" derivedContent="2"/> with an initial retransmission timeou
described in <xref target="timers_retrans"/>, which includes exponential backoff t (RTO) value of 500 ms and clock granularity (G) of 100 ms. In contrast to ste
s on retransmissions.</t> p 2.4 of <xref target="RFC6298" section="2" sectionFormat="of" format="default"
<t>T2 MUST be set such that it encompasses all legal retransmissions per derivedLink="https://rfc-editor.org/rfc/rfc6298#section-2" derivedContent="2"/>,
T1 plus a factor to accommodate network latency between BFCP entities, processi if the computed value of RTO is less than 500 ms, then RTO shall be set to 500
ng delays, etc.</t> ms. Timer T1 <bcp14>MUST</bcp14> be adjusted with the reception of a response t
o each request transmitted in order to compute an accurate RTO value, which is t
he effective T1 value. The RTT value R is the time in milliseconds from the tim
e when a request is transmitted to the time the initial response to that request
is received. Responses to retransmitted packets <bcp14>MUST NOT</bcp14> be use
d to recompute the RTO value, as one cannot determine if a response is to an ini
tial or retransmitted request. If T1 always expires on the initial transmission
of a new request, this would suggest the recommended initial T1 (and RTO) value
is too low and <bcp14>SHOULD</bcp14> be increased by doubling the initial value
s of T1 (and RTO) until T1 does not expire when sending a new request.</t>
<t indent="0" pn="section-8.3.1-2">When retransmitting a request, time
r T1 is doubled with each retransmission, failing after three unacknowledged ret
ransmission attempts.</t>
<t indent="0" pn="section-8.3.1-3">If a valid response is not received
for a client- or server-initiated transaction, the implementation <bcp14>MUST</
bcp14> consider the BFCP connection as broken. Implementations <bcp14>SHOULD</bc
p14> follow the reestablishment procedure described in <xref target="sec_transpo
rt" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t>
</section>
<section anchor="timers_cache" numbered="true" toc="include" removeInRFC
="false" pn="section-8.3.2">
<name slugifiedName="name-response-retransmission-tim">Response Retran
smission Timer, T2</name>
<t indent="0" pn="section-8.3.2-1">T2 is a timer that, when fired, sig
nals that the BFCP entity can release knowledge of the transaction against which
it is running. It is started upon the first transmission of the response to a r
equest and is the only mechanism by which that response is released by the BFCP
entity. Any subsequent retransmissions of the same request can be responded to b
y replaying the cached response, while that value is retained until the timer ha
s fired. Refer to <xref target="fragmentation_handling" format="default" section
Format="of" derivedContent="Section 6.2.3"/> for this timer's role in the fragme
ntation handling scheme.</t>
</section>
<section anchor="timers_values" numbered="true" toc="include" removeInRF
C="false" pn="section-8.3.3">
<name slugifiedName="name-timer-values">Timer Values</name>
<t indent="0" pn="section-8.3.3-1">The table below defines the differe
nt timers required when BFCP entities communicate over an unreliable transport.<
/t>
<table anchor="timertable" align="center" pn="table-6">
<name slugifiedName="name-timers-2">Timers</name>
<thead>
<tr>
<th align="center" colspan="1" rowspan="1">Timer</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<th align="center" colspan="1" rowspan="1">Value/s</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center" colspan="1" rowspan="1">T1</td>
<td align="left" colspan="1" rowspan="1">Initial request retrans
mission timer</td>
<td align="center" colspan="1" rowspan="1">0.5 s (initial)</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">T2</td>
<td align="left" colspan="1" rowspan="1">Response retransmission
timer</td>
<td align="center" colspan="1" rowspan="1">(T1*2<sup>4</sup>)*1.
25</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-8.3.3-3">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 procedures described in <xref target="timers_retrans" fo
rmat="default" sectionFormat="of" derivedContent="Section 8.3.1"/>, which includ
es exponential backoffs on retransmissions.</t>
<t indent="0" pn="section-8.3.3-4">T2 <bcp14>MUST</bcp14> be set such
that it encompasses all legal retransmissions per T1 plus a factor to accommodat
e network latency between BFCP entities, processing delays, etc.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="sec_auth" numbered="true" toc="include" removeInRFC="false"
pn="section-9">
<section title="Authentication and Authorization" anchor="sec:auth"> <name slugifiedName="name-authentication-and-authoriz">Authentication and
<t>BFCP clients SHOULD authenticate the floor control server before sending Authorization</name>
any BFCP message to it or accepting any BFCP message from it. Similarly, floor c <t indent="0" pn="section-9-1">BFCP clients <bcp14>SHOULD</bcp14> authenti
ontrol servers SHOULD authenticate a client before accepting any BFCP message fr cate the floor control server before sending any BFCP message to it or accepting
om it or sending any BFCP message to it.</t> any BFCP message from it. Similarly, floor control servers <bcp14>SHOULD</bcp14
<t>If the signaling or control protocol traffic used to set up the conferenc > authenticate a client before accepting any BFCP message from it or sending any
e is authenticated and confidentiality and integrity protected, and the extensio BFCP message to it.</t>
ns in this document are supported, the BFCP clients MUST authenticate the floor <t indent="0" pn="section-9-2">If the signaling or control protocol traffi
control server and the floor control servers MUST authenticate the client before c used to set up the conference is authenticated and confidentiality and integri
communicating as described above. Note that BFCP entities supporting only the < ty protected, and the extensions in this document are supported, the BFCP client
xref target="RFC4582"/> subset may not comply with this mandatory authentication s <bcp14>MUST</bcp14> authenticate the floor control server, and the floor contr
requirement.</t> ol servers <bcp14>MUST</bcp14> authenticate the client before communicating as d
<t>BFCP supports TLS/DTLS mutual authentication between clients and floor co escribed above. Note that BFCP entities supporting only the <xref target="RFC458
ntrol servers, as specified in <xref target="sec:auth:tls"/>. This is the RECOMM 2" format="default" sectionFormat="of" derivedContent="3"/> subset may not compl
ENDED authentication mechanism in BFCP.</t> y with this mandatory authentication requirement.</t>
<t>Note that future extensions may define additional authentication mechanis <t indent="0" pn="section-9-3">BFCP supports TLS/DTLS mutual authenticatio
ms.</t> n between clients and floor control servers, as specified in <xref target="sec_a
<t>In addition to authenticating BFCP messages, floor control servers need t uth_tls" format="default" sectionFormat="of" derivedContent="Section 9.1"/>. Thi
o authorize them. On receiving an authenticated BFCP message, the floor control s is the <bcp14>RECOMMENDED</bcp14> authentication mechanism in BFCP.</t>
server checks whether the client sending the message is authorized. If the clien <t indent="0" pn="section-9-4">Note that future extensions may define addi
t is not authorized to perform the operation being requested, the floor control tional authentication mechanisms.</t>
server generates an Error message, as described in <xref target="sec:server:erro <t indent="0" pn="section-9-5">In addition to authenticating BFCP messages
r"/>, with an Error code with a value of 5 (Unauthorized Operation). Messages fr , floor control servers need to authorize them. On receiving an authenticated BF
om a client that cannot be authorized MUST NOT be processed further.</t> CP message, the floor control server checks whether the client sending the messa
ge is authorized. If the client is not authorized to perform the operation being
<section title="TLS/DTLS Based Mutual Authentication" anchor="sec:auth:tls"> requested, the floor control server generates an Error message, as described in
<t>BFCP supports TLS/DTLS based mutual authentication between clients and <xref target="sec_server_error" format="default" sectionFormat="of" derivedCont
floor control servers. If TLS/DTLS is used, an initial integrity-protected chan ent="Section 13.8"/>, with an error code with a value of 5 (Unauthorized Operati
nel is REQUIRED between the client and the floor control server that can be used on). Messages from a client that cannot be authorized <bcp14>MUST NOT</bcp14> be
to exchange their certificates (which MAY be self-signed certificates) or, more processed further.</t>
commonly, the fingerprints of these certificates. These certificates are used <section anchor="sec_auth_tls" numbered="true" toc="include" removeInRFC="
at TLS/DTLS establishment time.</t> false" pn="section-9.1">
<t><list style="hanging"> <name slugifiedName="name-tls-dtls-based-mutual-authe">TLS/DTLS Based Mu
<t>The implementation of such an integrity-protected channel using SIP tual Authentication</name>
and the SDP offer/answer model is described in <xref target="I-D.ietf-bfcpbis-r <t indent="0" pn="section-9.1-1">BFCP supports TLS/DTLS based mutual aut
fc4583bis"/>.</t> hentication between clients and floor control servers. If TLS/DTLS is used, an
</list></t> initial integrity-protected channel is <bcp14>REQUIRED</bcp14> between the clien
<t>BFCP messages received over an authenticated TLS/DTLS connection are co t and the floor control server that can be used to exchange their certificates (
nsidered authenticated. A floor control server that receives a BFCP message over which <bcp14>MAY</bcp14> be self-signed certificates) or, more commonly, the fin
TCP/UDP (no TLS/DTLS) MAY request the use of TLS/DTLS by generating an Error me gerprints of these certificates. These certificates are used at TLS/DTLS estab
ssage, as described in <xref target="sec:server:error"/>, with an Error code wit lishment time.</t>
h a value of 9 (Use TLS) or a value of 11 (Use DTLS) respectively. Clients con <aside pn="section-9.1-2">
figured to require the use of TLS/DTLS MUST ignore unauthenticated messages.</t> <t indent="0" pn="section-9.1-2.1">The implementation of such an integ
<t>Note that future extensions may define additional authentication mechan rity-protected channel using SIP and the SDP offer/answer model is described in
isms that may not require an initial integrity-protected channel (e.g., authenti <xref target="RFC8856" format="default" sectionFormat="of" derivedContent="12"/>
cation based on certificates signed by a certificate authority).</t> .</t>
<t>As described in <xref target="sec:auth"/>, floor control servers need t </aside>
o perform authorization before processing any message. In particular, the floor <t indent="0" pn="section-9.1-3">BFCP messages received over an authenti
control server MUST check that messages arriving over a given authenticated TLS/ cated TLS/DTLS connection are considered authenticated. A floor control server t
DTLS connection use an authorized User ID (i.e., a User ID that the user that es hat receives a BFCP message over TCP/UDP (no TLS/DTLS) <bcp14>MAY</bcp14> reques
tablished the authenticated TLS/DTLS connection is allowed to use).</t> t the use of TLS/DTLS by generating an Error message, as described in <xref targ
</section> et="sec_server_error" format="default" sectionFormat="of" derivedContent="Sectio
</section> n 13.8"/>, with an error code with a value of 9 (Use TLS) or a value of 11 (Use
DTLS) respectively. Clients configured to require the use of TLS/DTLS <bcp14>M
<section title="Floor Participant Operations" anchor="sec:participant"> UST</bcp14> ignore unauthenticated messages.</t>
<t>This section specifies how floor participants can perform different opera <t indent="0" pn="section-9.1-4">Note that future extensions may define
tions, such as requesting a floor, using the protocol elements described in earl additional authentication mechanisms that may not require an initial integrity-p
ier sections. <xref target="sec:chair"/> specifies operations that are specific rotected channel (e.g., authentication based on certificates signed by a certifi
to floor chairs, such as instructing the floor control server to grant or revoke cate authority).</t>
a floor, and <xref target="sec:client"/> specifies operations that can be perfo <t indent="0" pn="section-9.1-5">As described in <xref target="sec_auth"
rmed by any client (i.e., both floor participants and floor chairs).</t> format="default" sectionFormat="of" derivedContent="Section 9"/>, floor control
servers need to perform authorization before processing any message. In particu
<section title="Requesting a Floor" anchor="sec:participant:request"> lar, the floor control server <bcp14>MUST</bcp14> check that messages arriving o
<t>A floor participant that wishes to request one or more floors does so b ver a given authenticated TLS/DTLS connection use an authorized User ID (i.e., a
y sending a FloorRequest message to the floor control server.</t> User ID that the user that established the authenticated TLS/DTLS connection is
allowed to use).</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>
<section title="Receiving a Response" anchor="sec:client:request:response" <section anchor="sec_participant" numbered="true" toc="include" removeInRFC=
> "false" pn="section-10">
<t>A message from the floor control server is considered a response to t <name slugifiedName="name-floor-participant-operation">Floor Participant O
he FloorRequest message if the message from the floor control server has the sam perations</name>
e Conference ID, Transaction ID, and User ID as the FloorRequest message, as des <t indent="0" pn="section-10-1">This section specifies how floor participa
cribed in <xref target="sec:transactions:client"/>. On receiving such a response nts can perform different operations, such as requesting a floor, using the prot
, the floor participant follows the rules in <xref target="sec:auth"/> that rela ocol elements described in earlier sections. <xref target="sec_chair" format="de
te to floor control server authentication.</t> fault" sectionFormat="of" derivedContent="Section 11"/> specifies operations tha
<t>The successful processing of a FloorRequest message at the floor cont t are specific to floor chairs, such as instructing the floor control server to
rol server involves generating one or several FloorRequestStatus messages. The f grant or revoke a floor, and <xref target="sec_client" format="default" sectionF
loor participant obtains a Floor Request ID in the Floor Request ID field of a F ormat="of" derivedContent="Section 12"/> specifies operations that can be perfor
LOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from med by any client (i.e., both floor participants and floor chairs).</t>
the floor control server. Subsequent FloorRequestStatus messages from the floor <section anchor="sec_participant_request" numbered="true" toc="include" re
control server regarding the same floor request will carry the same Floor Reques moveInRFC="false" pn="section-10.1">
t ID in a FLOOR-REQUEST-INFORMATION attribute as the initial FloorRequestStatus <name slugifiedName="name-requesting-a-floor">Requesting a Floor</name>
message. This way, the floor participant can associate subsequent incoming Floor <t indent="0" pn="section-10.1-1">A floor participant that wishes to req
RequestStatus messages with the ongoing floor request.</t> uest one or more floors does so by sending a FloorRequest message to the floor c
<t>The floor participant obtains information about the status of the flo ontrol server.</t>
or request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorReques <section anchor="sec_participant_request_send" numbered="true" toc="incl
tStatus messages received from the floor control server. This attribute is a gro ude" removeInRFC="false" pn="section-10.1.1">
uped attribute, and as such it includes a number of attributes that provide info <name slugifiedName="name-sending-a-floorrequest-mess">Sending a Floor
rmation about the floor request.</t> Request Message</name>
<t>The OVERALL-REQUEST-STATUS attribute provides information about the o <t indent="0" pn="section-10.1.1-1">The ABNF in <xref target="sec_msg_
verall status of the floor request. If the Request Status value is Granted, all format_FloorRequest" format="default" sectionFormat="of" derivedContent="Section
the floors that were requested in the FloorRequest message have been granted. If 5.3.1"/> describes the attributes that a FloorRequest message can contain. In a
the Request Status value is Denied, all the floors that were requested in the F ddition, the ABNF specifies normatively which of these attributes are mandatory,
loorRequest message have been denied. A floor request is considered to be ongoin and which ones are optional.</t>
g while it is in the Pending, Accepted, or Granted states. If the floor request <t indent="0" pn="section-10.1.1-2">The floor participant sets the Con
value is unknown, then the response is still processed. However, no meaningful ference ID and the Transaction ID in the COMMON-HEADER following the rules given
value can be reported to the user.</t> in <xref target="sec_transactions_client" format="default" sectionFormat="of" d
<t>The STATUS-INFO attribute, if present, provides extra information tha erivedContent="Section 8.1"/>.</t>
t the floor participant can display to the user.</t> <t indent="0" pn="section-10.1.1-3">The floor participant sets the Use
<t>The FLOOR-REQUEST-STATUS attributes provide information about the sta r ID in the COMMON-HEADER to the floor participant's identifier. If the sender
tus of the floor request as it relates to a particular floor. The STATUS-INFO a of the FloorRequest message (identified by the User ID) is not the participant t
ttribute, if present, provides extra information that the floor participant can hat would eventually get the floor (i.e., a third-party floor request), the send
display to the user.</t> er <bcp14>SHOULD</bcp14> add a BENEFICIARY-ID attribute to the message identifyi
<t>The BENEFICIARY-INFORMATION attribute identifies the beneficiary of t ng the beneficiary of the floor.</t>
he floor request in third-party floor requests. The REQUESTED-BY-INFORMATION at <aside pn="section-10.1.1-4">
tribute need not be present in FloorRequestStatus messages received by the floor <t indent="0" pn="section-10.1.1-4.1">Note that the namespace for bo
participant that requested the floor, as this floor participant is already iden th the User ID and the Beneficiary ID is the same. That is, a given participant
tified by the User ID in the common header.</t> is identified by a single 16-bit value that can be used in the User ID in the CO
<t>The PRIORITY attribute, when present, contains the priority that was MMON-HEADER and in several attributes: BENEFICIARY-ID, BENEFICIARY-INFORMATION,
requested by the generator of the FloorRequest message.</t> and REQUESTED-BY-INFORMATION.</t>
<t>If the response is an Error message, the floor control server could n </aside>
ot process the FloorRequest message for some reason, which is described in the E <t indent="0" pn="section-10.1.1-5">The floor participant <bcp14>MUST<
rror message.</t> /bcp14> insert at least one FLOOR-ID attribute in the FloorRequest message. If t
he client inserts more than one FLOOR-ID attribute, the floor control server wil
l 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 indent="0" pn="section-10.1.1-6">The floor participant may use a PA
RTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors ar
e being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is
intended for human consumption.</t>
<t indent="0" pn="section-10.1.1-7">The floor participant may request
that the server handle the floor request with a certain priority using a PRIORIT
Y attribute.</t>
</section>
<section anchor="sec_client_request_response" numbered="true" toc="inclu
de" removeInRFC="false" pn="section-10.1.2">
<name slugifiedName="name-receiving-a-response">Receiving a Response</
name>
<t indent="0" pn="section-10.1.2-1">A message from the floor control s
erver is considered a response to the FloorRequest message if the message from t
he floor control server has the same Conference ID, Transaction ID, and User ID
as the FloorRequest message, as described in <xref target="sec_transactions_clie
nt" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On recei
ving such a response, the floor participant follows the rules in <xref target="s
ec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that r
elate to floor control server authentication.</t>
<t indent="0" pn="section-10.1.2-2">The successful processing of a Flo
orRequest message at the floor control server involves generating one or several
FloorRequestStatus messages. The floor participant obtains a Floor Request ID i
n the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the fir
st FloorRequestStatus message from the floor control server. Subsequent FloorReq
uestStatus messages from the floor control server regarding the same floor reque
st will carry the same Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute
as the initial FloorRequestStatus message. This way, the floor participant can
associate subsequent incoming FloorRequestStatus messages with the ongoing floor
request.</t>
<t indent="0" pn="section-10.1.2-3">The floor participant obtains info
rmation about the status of the floor request in the FLOOR-REQUEST-INFORMATION a
ttribute of each of the FloorRequestStatus messages received from the floor cont
rol server. This attribute is a grouped attribute, and as such it includes a num
ber of attributes that provide information about the floor request.</t>
<t indent="0" pn="section-10.1.2-4">The OVERALL-REQUEST-STATUS attribu
te provides information about the overall status of the floor request. If the Re
quest Status value is Granted, all the floors that were requested in the FloorRe
quest 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 ongoing while it is in the Pending, Accepted, or Gr
anted states. If the floor request value is unknown, then the response is still
processed. However, no meaningful value can be reported to the user.</t>
<t indent="0" pn="section-10.1.2-5">The STATUS-INFO attribute, if pres
ent, provides extra information that the floor participant can display to the us
er.</t>
<t indent="0" pn="section-10.1.2-6">The FLOOR-REQUEST-STATUS attribute
s provide information about the status of the floor request as it relates to a p
articular floor. The STATUS-INFO attribute, if present, provides extra informat
ion that the floor participant can display to the user.</t>
<t indent="0" pn="section-10.1.2-7">The BENEFICIARY-INFORMATION attrib
ute identifies the beneficiary of the floor request in third-party floor request
s. The REQUESTED-BY-INFORMATION attribute need not be present in FloorRequestSt
atus messages received by the floor participant that requested the floor, as thi
s floor participant is already identified by the User ID in the COMMON-HEADER.</
t>
<t indent="0" pn="section-10.1.2-8">The PRIORITY attribute, when prese
nt, contains the priority that was requested by the generator of the FloorReques
t message.</t>
<t indent="0" pn="section-10.1.2-9">If the response is an Error messag
e, 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="include" removeIn
RFC="false" pn="section-10.1.3">
<name slugifiedName="name-reception-of-a-subsequent-f">Reception of a
Subsequent FloorRequestStatus Message</name>
<t indent="0" pn="section-10.1.3-1">When communicating over an unrelia
ble transport and upon receiving a FloorRequestStatus message from a floor contr
ol server, the participant <bcp14>MUST</bcp14> respond with a FloorRequestStatus
Ack message within the transaction failure window to complete the transaction.</
t>
</section>
</section> </section>
<section anchor="sec_participant_cancel" numbered="true" toc="include" rem
<section title="Reception of a Subsequent FloorRequestStatus Message" anch oveInRFC="false" pn="section-10.2">
or="sec:recept:frsm"> <name slugifiedName="name-cancelling-a-floor-request-">Cancelling a Floo
<t>When communicating over an unreliable transport and upon receiving a F r Request and Releasing a Floor</name>
loorRequestStatus message from a floor control server, the participant MUST resp <t indent="0" pn="section-10.2-1">A floor participant that wishes to can
ond with a FloorRequestStatusAck message within the transaction failure window t cel an ongoing floor request does so by sending a FloorRelease message to the fl
o complete the transaction.</t> oor control server. The FloorRelease message is also used by floor participants
that hold a floor and would like to release it.</t>
<section anchor="sec_participant_cancel_send" numbered="true" toc="inclu
de" removeInRFC="false" pn="section-10.2.1">
<name slugifiedName="name-sending-a-floorrelease-mess">Sending a Floor
Release Message</name>
<t indent="0" pn="section-10.2.1-1">The ABNF in <xref target="sec_msg_
format_FloorRelease" format="default" sectionFormat="of" derivedContent="Section
5.3.2"/> describes the attributes that a FloorRelease message can contain. In a
ddition, the ABNF specifies normatively which of these attributes are mandatory,
and which ones are optional.</t>
<t indent="0" pn="section-10.2.1-2">The floor participant sets the Con
ference ID and the Transaction ID in the COMMON-HEADER following the rules given
in <xref target="sec_transactions_client" format="default" sectionFormat="of" d
erivedContent="Section 8.1"/>. The floor participant sets the User ID in the COM
MON-HEADER to the floor participant's identifier.</t>
<aside pn="section-10.2.1-3">
<t indent="0" pn="section-10.2.1-3.1">Note that the FloorRelease mes
sage is used to release a floor or floors that were granted and to cancel ongoin
g floor requests (from the protocol perspective, both are ongoing floor requests
). Using the same message in both situations helps resolve the race condition th
at occurs when the FloorRelease message and the FloorGrant message cross each ot
her on the wire.</t>
</aside>
<t indent="0" pn="section-10.2.1-4">The floor participant uses the FLO
OR-REQUEST-ID that was received in the response to the FloorRequest message that
the FloorRelease message is cancelling.</t>
<aside pn="section-10.2.1-5">
<t indent="0" pn="section-10.2.1-5.1">Note that if the floor partici
pant requested several floors as an atomic operation (i.e., in a single FloorReq
uest message), all the floors are released 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="i
nclude" removeInRFC="false" pn="section-10.2.2">
<name slugifiedName="name-receiving-a-response-2">Receiving a Response
</name>
<t indent="0" pn="section-10.2.2-1">A message from the floor control s
erver is considered a response to the FloorRelease message if the message from t
he floor control server has the same Conference ID, Transaction ID, and User ID
as the FloorRelease message, as described in <xref target="sec_transactions_clie
nt" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On recei
ving such a response, the floor participant follows the rules in <xref target="s
ec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that r
elate to floor control server authentication.</t>
<t indent="0" pn="section-10.2.2-2">If the response is a FloorRequestS
tatus message, the Request Status value in the OVERALL-REQUEST-STATUS attribute
(within the FLOOR-REQUEST-INFORMATION grouped attribute) will be Cancelled or Re
leased.</t>
<t indent="0" pn="section-10.2.2-3">If the response is an Error messag
e, the floor control server could not process the FloorRequest message for some
reason, which is described in the Error message.</t>
<t indent="0" pn="section-10.2.2-4">It is possible that the FloorRelea
se message crosses on the wire with 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 match that of the FloorRelease.</t>
</section>
</section> </section>
</section> </section>
<section anchor="sec_chair" numbered="true" toc="include" removeInRFC="false
<section title="Cancelling a Floor Request and Releasing a Floor" anchor="se " pn="section-11">
c:participant:cancel"> <name slugifiedName="name-chair-operations">Chair Operations</name>
<t>A floor participant that wishes to cancel an ongoing floor request does <t indent="0" pn="section-11-1">This section specifies how floor chairs ca
so by sending a FloorRelease message to the floor control server. The FloorRele n instruct the floor control server to grant or revoke a floor using the protoco
ase message is also used by floor participants that hold a floor and would like l elements described in earlier sections.</t>
to release it.</t> <t indent="0" pn="section-11-2">Floor chairs that wish to send instruction
s to a floor control server do so by sending a ChairAction message.</t>
<section title="Sending a FloorRelease Message" anchor="sec:participant:ca <section anchor="sec_chair_send" numbered="true" toc="include" removeInRFC
ncel:send"> ="false" pn="section-11.1">
<t>The ABNF in <xref target="sec:msg_format:FloorRelease"/> describes th <name slugifiedName="name-sending-a-chairaction-messa">Sending a ChairAc
e attributes that a FloorRelease message can contain. In addition, the ABNF spec tion Message</name>
ifies normatively which of these attributes are mandatory, and which ones are op <t indent="0" pn="section-11.1-1">The ABNF in <xref target="sec_msg_form
tional.</t> at_ChairAction" format="default" sectionFormat="of" derivedContent="Section 5.3.
<t>The floor participant sets the Conference ID and the Transaction ID i 9"/> describes the attributes that a ChairAction message can contain. In additio
n the common header following the rules given in <xref target="sec:transactions: n, the ABNF specifies normatively which of these attributes are mandatory, and w
client"/>. The floor participant sets the User ID in the common header to the fl hich ones are optional.</t>
oor participant's identifier.</t> <t indent="0" pn="section-11.1-2">The floor chair sets the Conference ID
<t><list style="empty"> and the Transaction ID in the COMMON-HEADER following the rules given in <xref
<t>Note that the FloorRelease message is used to release a floor or target="sec_transactions_client" format="default" sectionFormat="of" derivedCont
floors that were granted and to cancel ongoing floor requests (from the protocol ent="Section 8.1"/>. The floor chair sets the User ID in the COMMON-HEADER to th
perspective, both are ongoing floor requests). Using the same message in both s e floor chair's identifier.</t>
ituations helps resolve the race condition that occurs when the FloorRelease mes <t indent="0" pn="section-11.1-3">The ChairAction message contains instr
sage and the FloorGrant message cross each other on the wire.</t> uctions that apply to one or more floors within a particular floor request. The
</list></t> floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the fl
<t>The floor participant uses the FLOOR-REQUEST-ID that was received in oor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are car
the response to the FloorRequest message that the FloorRelease message is cancel ried in the ChairAction message.</t>
ling.</t> <t indent="0" pn="section-11.1-4">For example, if a floor request consis
<t><list style="empty"> ts of two floors that depend on different floor chairs, each floor chair will gr
<t>Note that if the floor participant requested several floors as an ant its floor within the floor request. Once both chairs have granted their floo
atomic operation (i.e., in a single FloorRequest message), all the floors are r r, the floor control server will grant the floor request as a whole. On the othe
eleased as an atomic operation as well (i.e., all are released at the same time) r hand, if one of the floor chairs denies its floor, the floor control server wi
.</t> ll deny the floor request as a whole, regardless of the other floor chair's deci
</list></t> sion.</t>
<t indent="0" pn="section-11.1-5">The floor chair provides the new statu
s of the floor request as it relates to a particular floor using a FLOOR-REQUEST
-STATUS attribute. If the new status of the floor request is Accepted, the floor
chair <bcp14>MAY</bcp14> use the Queue Position field to provide a queue positi
on for the floor request. If the floor chair does not wish to provide a queue po
sition, all the bits of the Queue Position field <bcp14>MUST</bcp14> be set to z
ero. The floor chair <bcp14>MUST</bcp14> use the Status Revoked to revoke a floo
r that was granted (i.e., Granted status) and <bcp14>MUST</bcp14> use the Status
Denied to reject floor requests in any other status (e.g., Pending and Accepted
).</t>
<t indent="0" pn="section-11.1-6">The floor chair <bcp14>MAY</bcp14> add
an OVERALL-REQUEST-STATUS attribute to the ChairAction message to provide a new
overall status for the floor request. If the new overall status of the floor r
equest is Accepted, the floor chair can use the Queue Position field to provide
a queue position for the floor request.</t>
<aside pn="section-11.1-7">
<t indent="0" pn="section-11.1-7.1">Note that a particular floor contr
ol server can implement a different queue for each floor containing all the floo
r requests that relate to that particular floor, a general queue for all floor r
equests, or both. Also note that a floor request can involve several floors and
that a ChairAction message can only deal with a subset of these floors (e.g., i
f a single floor chair is not authorized to manage all the floors). In this cas
e, the floor control server will combine the instructions received from the diff
erent floor chairs in FLOOR-REQUEST-STATUS attributes to come up with the overal
l status of the floor request.</t>
<t indent="0" pn="section-11.1-7.2">Note that, while the action of a f
loor chair may communicate information in the OVERALL-REQUEST-STATUS attribute,
the floor control server may override, modify, or ignore this field's content.</
t>
</aside>
<t indent="0" pn="section-11.1-8">The floor chair <bcp14>MAY</bcp14> inc
lude STATUS-INFO attributes to state the reason why the floor or floors are bein
g accepted, granted, or revoked. The Text in the STATUS-INFO attribute is intend
ed for human consumption.</t>
</section> </section>
<section anchor="sec_chair_instruct_response" numbered="true" toc="include
<section title="Receiving a Response" anchor="sec:participant:cancel:respo " removeInRFC="false" pn="section-11.2">
nse"> <name slugifiedName="name-receiving-a-response-3">Receiving a Response</
<t>A message from the floor control server is considered a response to t name>
he FloorRelease message if the message from the floor control server has the sam <t indent="0" pn="section-11.2-1">A message from the floor control serve
e Conference ID, Transaction ID, and User ID as the FloorRelease message, as des r is considered a response to the ChairAction message if the message from the se
cribed in <xref target="sec:transactions:client"/>. On receiving such a response rver has the same Conference ID, Transaction ID, and User ID as the ChairAction
, the floor participant follows the rules in <xref target="sec:auth"/> that rela message, as described in <xref target="sec_transactions_client" format="default"
te to floor control server authentication.</t> sectionFormat="of" derivedContent="Section 8.1"/>. On receiving such a response
<t>If the response is a FloorRequestStatus message, the Request Status v , the floor chair follows the rules in <xref target="sec_auth" format="default"
alue in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATI sectionFormat="of" derivedContent="Section 9"/> that relate to floor control ser
ON grouped attribute) will be Cancelled or Released.</t> ver authentication.</t>
<t>If the response is an Error message, the floor control server could n <t indent="0" pn="section-11.2-2">A ChairActionAck message from the floo
ot process the FloorRequest message for some reason, which is described in the E r control server confirms that the floor control server has accepted the ChairAc
rror message.</t> tion message. An Error message indicates that the floor control server could not
<t>It is possible that the FloorRelease message crosses on the wire with process the ChairAction message for some reason, which is described in the Erro
a FloorRequestStatus message from the server with a Request Status different fr r message.</t>
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_client" numbered="true" toc="include" removeInRFC="fals
e" pn="section-12">
<section title="Chair Operations" anchor="sec:chair"> <name slugifiedName="name-general-client-operations">General Client Operat
<t>This section specifies how floor chairs can instruct the floor control se ions</name>
rver to grant or revoke a floor using the protocol elements described in earlier <t indent="0" pn="section-12-1">This section specifies operations that can
sections.</t> be performed by any client. That is, they are not specific to floor participant
<t>Floor chairs that wish to send instructions to a floor control server do s or floor chairs. They can be performed by both.</t>
so by sending a ChairAction message.</t> <section anchor="sec_client_floorinfo" numbered="true" toc="include" remov
eInRFC="false" pn="section-12.1">
<section title="Sending a ChairAction Message" anchor="sec:chair:send"> <name slugifiedName="name-requesting-information-abou">Requesting Inform
<t>The ABNF in <xref target="sec:msg_format:ChairAction"/> describes the a ation about Floors</name>
ttributes that a ChairAction message can contain. In addition, the ABNF specifie <t indent="0" pn="section-12.1-1">A client can obtain information about
s normatively which of these attributes are mandatory, and which ones are option the status of a floor or floors in different ways, which include using BFCP and
al.</t> using out-of-band mechanisms. Clients using BFCP to obtain such information use
<t>The floor chair sets the Conference ID and the Transaction ID in the co the procedures described in this section. </t>
mmon header following the rules given in <xref target="sec:transactions:client"/ <t indent="0" pn="section-12.1-2">Clients request information about the
>. The floor chair sets the User ID in the common header to the floor chair's id status of one or several floors by sending a FloorQuery message to the floor con
entifier.</t> trol server.</t>
<t>The ChairAction message contains instructions that apply to one or more <section anchor="sec_client_floorinfo_send" numbered="true" toc="include
floors within a particular floor request. The floor or floors are identified by " removeInRFC="false" pn="section-12.1.1">
the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the <name slugifiedName="name-sending-a-floorquery-messag">Sending a Floor
FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message.< Query Message</name>
/t> <t indent="0" pn="section-12.1.1-1">The ABNF in <xref target="sec_msg_
<t>For example, if a floor request consists of two floors that depend on d format_FloorQuery" format="default" sectionFormat="of" derivedContent="Section 5
ifferent floor chairs, each floor chair will grant its floor within the floor re .3.7"/> describes the attributes that a FloorQuery message can contain. In addit
quest. Once both chairs have granted their floor, the floor control server will ion, the ABNF specifies normatively which of these attributes are mandatory, and
grant the floor request as a whole. On the other hand, if one of the floor chair which ones are optional.</t>
s denies its floor, the floor control server will deny the floor request as a wh <t indent="0" pn="section-12.1.1-2">The client sets the Conference ID
ole, regardless of the other floor chair's decision.</t> and the Transaction ID in the COMMON-HEADER following the rules given in <xref t
<t>The floor chair provides the new status of the floor request as it rela arget="sec_transactions_client" format="default" sectionFormat="of" derivedConte
tes to a particular floor using a FLOOR-REQUEST-STATUS attribute. If the new sta nt="Section 8.1"/>. The client sets the User ID in the COMMON-HEADER to the clie
tus of the floor request is Accepted, the floor chair MAY use the Queue Position nt's identifier.</t>
field to provide a queue position for the floor request. If the floor chair doe <t indent="0" pn="section-12.1.1-3">The client inserts in the message
s not wish to provide a queue position, all the bits of the Queue Position field all the Floor IDs it wants to receive information about. The floor control serve
MUST be set to zero. The floor chair MUST use the Status Revoked to revoke a fl r will send periodic information about all of these floors. If the client does n
oor that was granted (i.e., Granted status) and MUST use the Status Denied to re ot want to receive information about a particular floor any longer, it sends a n
ject floor requests in any other status (e.g., Pending and Accepted).</t> ew FloorQuery message removing the FLOOR-ID of this floor. If the client does no
<t>The floor chair MAY add an OVERALL-REQUEST-STATUS attribute to the Chai t want to receive information about any floor any longer, it sends a FloorQuery
rAction message to provide a new overall status for the floor request. If the n message with no FLOOR-ID attribute.</t>
ew overall status of the floor request is Accepted, the floor chair can use the </section>
Queue Position field to provide a queue position for the floor request.</t> <section anchor="sec_client_floorinfo_response" numbered="true" toc="inc
<t><list style="hanging"> lude" removeInRFC="false" pn="section-12.1.2">
<t>Note that a particular floor control server can implement a differe <name slugifiedName="name-receiving-a-response-4">Receiving a Response
nt queue for each floor containing all the floor requests that relate to that pa </name>
rticular floor, a general queue for all floor requests, or both. Also note that <t indent="0" pn="section-12.1.2-1">A message from the floor control s
a floor request can involve several floors and that a ChairAction message can o erver is considered a response to the FloorQuery message if the message from the
nly deal with a subset of these floors (e.g., if a single floor chair is not aut floor control server has the same Conference ID, Transaction ID, and User ID as
horized to manage all the floors). In this case, the floor control server will the FloorQuery message, as described in <xref target="sec_transactions_client"
combine the instructions received from the different floor chairs in FLOOR-REQUE format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving
ST-STATUS attributes to come up with the overall status of the floor request.</t such a response, the client follows the rules in <xref target="sec_auth" format
> ="default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor
<t>Note that, while the action of a floor chair may communicate inform control server authentication.</t>
ation in the OVERALL-REQUEST-STATUS attribute, the floor control server may over <t indent="0" pn="section-12.1.2-2">On reception of the FloorQuery mes
ride, modify, or ignore this field's content.</t> sage, the floor control server <bcp14>MUST</bcp14> respond with a FloorStatus me
</list></t> ssage or with an Error message. If the response is a FloorStatus message, it wil
<t>The floor chair MAY include STATUS-INFO attributes to state the reason l contain information about one of the floors the client requested information a
why the floor or floors are being accepted, granted, or revoked. The Text in the bout. If the client did not include any FLOOR-ID attribute in its FloorQuery mes
STATUS-INFO attribute is intended for human consumption.</t> sage (i.e., the client does not want to receive information about any floor any
</section> longer), the FloorStatus message from the floor control server will not include
any FLOOR-ID attribute either. </t>
<section title="Receiving a Response" anchor="sec:chair:instruct:response"> <t indent="0" pn="section-12.1.2-3">FloorStatus messages that carry in
<t>A message from the floor control server is considered a response to the formation about a floor contain a FLOOR-ID attribute that identifies the floor.
ChairAction message if the message from the server has the same Conference ID, After this attribute, FloorStatus messages contain information about existing (o
Transaction ID, and User ID as the ChairAction message, as described in <xref ta ne or more) floor requests that relate to that floor. The information about each
rget="sec:transactions:client"/>. On receiving such a response, the floor chair particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. T
follows the rules in <xref target="sec:auth"/> that relate to floor control serv his grouped attribute carries a Floor Request ID that identifies the floor reque
er authentication.</t> st, followed by a set of attributes that provide information about the floor req
<t>A ChairActionAck message from the floor control server confirms that th uest.</t>
e floor control server has accepted the ChairAction message. An Error message in <t indent="0" pn="section-12.1.2-4">After the first FloorStatus, the f
dicates that the floor control server could not process the ChairAction message loor control server will continue sending FloorStatus messages, periodically inf
for some reason, which is described in the Error message.</t> orming the client about changes on the floors the client requested information a
</section> bout.</t>
</section> </section>
<section anchor="sec_recept_fsm" numbered="true" toc="include" removeInR
<section title="General Client Operations" anchor="sec:client"> FC="false" pn="section-12.1.3">
<t>This section specifies operations that can be performed by any client. Th <name slugifiedName="name-reception-of-a-subsequent-fl">Reception of a
at is, they are not specific to floor participants or floor chairs. They can be Subsequent FloorStatus Message</name>
performed by both.</t> <t indent="0" pn="section-12.1.3-1">When communicating over an unrelia
ble transport and upon receiving a FloorStatus message from a floor control serv
<section title="Requesting Information about Floors" anchor="sec:client:floo er, the participant <bcp14>MUST</bcp14> respond with a FloorStatusAck message wi
rinfo"> thin the transaction failure window to complete the transaction.</t>
<t>A client can obtain information about the status of a floor or floors i </section>
n different ways, which include using BFCP and using out-of-band mechanisms. Cli
ents using BFCP to obtain such information use the procedures described in this
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
:send">
<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>
<section anchor="sec_client_info" numbered="true" toc="include" removeInRF
<section title="Receiving a Response" anchor="sec:client:floorinfo:respons C="false" pn="section-12.2">
e"> <name slugifiedName="name-requesting-information-about">Requesting Infor
<t>A message from the floor control server is considered a response to t mation about Floor Requests</name>
he FloorQuery message if the message from the floor control server has the same <t indent="0" pn="section-12.2-1">A client can obtain information about
Conference ID, Transaction ID, and User ID as the FloorQuery message, as describ the status of one or several floor requests in different ways, which include usi
ed in <xref target="sec:transactions:client"/>. On receiving such a response, th ng BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such info
e client follows the rules in <xref target="sec:auth"/> that relate to floor con rmation use the procedures described in this section.</t>
trol server authentication.</t> <t indent="0" pn="section-12.2-2">Clients request information about the
<t>On reception of the FloorQuery message, the floor control server MUST current status of a floor request by sending a FloorRequestQuery message to the
respond with a FloorStatus message or with an Error message. If the response is floor control server.</t>
a FloorStatus message, it will contain information about one of the floors the <t indent="0" pn="section-12.2-3">Requesting information about a particu
client requested information about. If the client did not include any FLOOR-ID a lar floor request is useful in a number of situations. For example, on reception
ttribute in its FloorQuery message (i.e., the client does not want to receive in of a FloorRequest message, a floor control server may choose to return FloorReq
formation about any floor any longer), the FloorStatus message from the floor co uestStatus messages only when the floor request changes its state (e.g., from Ac
ntrol server will not include any FLOOR-ID attribute either. </t> cepted to Granted), but not when the floor request advances in its queue. In thi
<t>FloorStatus messages that carry information about a floor contain a F s situation, if the user requests it, the floor participant can use a FloorReque
LOOR-ID attribute that identifies the floor. After this attribute, FloorStatus m stQuery message to poll the floor control server for the status of the floor req
essages contain information about existing (one or more) floor requests that rel uest.</t>
ate to that floor. The information about each particular floor request is encode <section anchor="sec_client_info_send" numbered="true" toc="include" rem
d in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Flo oveInRFC="false" pn="section-12.2.1">
or Request ID that identifies the floor request, followed by a set of attributes <name slugifiedName="name-sending-a-floorrequestquery">Sending a Floor
that provide information about the floor request.</t> RequestQuery Message</name>
<t>After the first FloorStatus, the floor control server will continue s <t indent="0" pn="section-12.2.1-1">The ABNF in <xref target="sec_msg_
ending FloorStatus messages, periodically informing the client about changes on format_FloorRequestQuery" format="default" sectionFormat="of" derivedContent="Se
the floors the client requested information about.</t> ction 5.3.3"/> describes the attributes that a FloorRequestQuery message can con
tain. In addition, the ABNF specifies normatively which of these attributes are
mandatory, and which ones are optional.</t>
<t indent="0" pn="section-12.2.1-2">The client sets the Conference ID
and the Transaction ID in the COMMON-HEADER following the rules given in <xref t
arget="sec_transactions_client" format="default" sectionFormat="of" derivedConte
nt="Section 8.1"/>. The client sets the User ID in the COMMON-HEADER to the clie
nt's identifier.</t>
<t indent="0" pn="section-12.2.1-3">The client <bcp14>MUST</bcp14> ins
ert 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="include"
removeInRFC="false" pn="section-12.2.2">
<name slugifiedName="name-receiving-a-response-5">Receiving a Response
</name>
<t indent="0" pn="section-12.2.2-1">A message from the floor control s
erver is considered a response to the FloorRequestQuery message if the message f
rom the floor control server has the same Conference ID, Transaction ID, and Use
r ID as the FloorRequestQuery message, as described in <xref target="sec_transac
tions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>
. On receiving such a response, the client follows the rules in <xref target="s
ec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that r
elate to floor control server authentication.</t>
<t indent="0" pn="section-12.2.2-2">If the response is a FloorRequestS
tatus message, the client obtains information about the status of the FloorReque
st the client requested information about in a FLOOR-REQUEST-INFORMATION attribu
te.</t>
<t indent="0" pn="section-12.2.2-3">If the response is an Error messag
e, the floor control server could not process the FloorRequestQuery message for
some reason, which is described in the Error message.</t>
</section>
</section> </section>
<section anchor="sec_client_user" numbered="true" toc="include" removeInRF
<section title="Reception of a Subsequent FloorStatus Message" anchor="sec C="false" pn="section-12.3">
:recept:fsm"> <name slugifiedName="name-requesting-information-about-">Requesting Info
<t>When communicating over an unreliable transport and upon receiving a F rmation about a User</name>
loorStatus message from a floor control server, the participant MUST respond wit <t indent="0" pn="section-12.3-1">A client can obtain information about
h a FloorStatusAck message within the transaction failure window to complete the a participant and the floor requests related to this participant in different wa
transaction.</t> ys, which include using BFCP and using out-of-band mechanisms. Clients using BFC
P to obtain such information use the procedures described in this section.</t>
<t indent="0" pn="section-12.3-2">Clients request information about a pa
rticipant and the floor requests related to this participant by sending a UserQu
ery message to the floor control server.</t>
<t indent="0" pn="section-12.3-3">This functionality may be useful for f
loor chairs or floor participants interested in the display name and the URI of
a particular floor participant. In addition, a floor participant may find it use
ful to request information about itself. For example, a floor participant, after
experiencing connectivity problems (e.g., its TCP connection with the floor con
trol server was down for a while and eventually was re-established), may need to
request information about all the floor requests associated to itself that stil
l exist.</t>
<section anchor="sec_client_user_send" numbered="true" toc="include" rem
oveInRFC="false" pn="section-12.3.1">
<name slugifiedName="name-sending-a-userquery-message">Sending a UserQ
uery Message</name>
<t indent="0" pn="section-12.3.1-1">The ABNF in <xref target="sec_msg_
format_UserQuery" format="default" sectionFormat="of" derivedContent="Section 5.
3.5"/> describes the attributes that a UserQuery message can contain. In additio
n, the ABNF specifies normatively which of these attributes are mandatory, and w
hich ones are optional.</t>
<t indent="0" pn="section-12.3.1-2">The client sets the Conference ID
and the Transaction ID in the COMMON-HEADER following the rules given in <xref t
arget="sec_transactions_client" format="default" sectionFormat="of" derivedConte
nt="Section 8.1"/>. The client sets the User ID in the COMMON-HEADER to the clie
nt's identifier.</t>
<t indent="0" pn="section-12.3.1-3">If the floor participant the clien
t is requesting information about is not the client issuing the UserQuery messag
e (which is identified by the User ID in the COMMON-HEADER of the message), the
client <bcp14>MUST</bcp14> insert a BENEFICIARY-ID attribute.</t>
</section>
<section anchor="sec_client_user_response" numbered="true" toc="include"
removeInRFC="false" pn="section-12.3.2">
<name slugifiedName="name-receiving-a-response-6">Receiving a Response
</name>
<t indent="0" pn="section-12.3.2-1">A message from the floor control s
erver is considered a response to the UserQuery message if the message from the
floor control server has the same Conference ID, Transaction ID, and User ID as
the UserQuery message, as described in <xref target="sec_transactions_client" fo
rmat="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving
such a response, the client follows the rules in <xref target="sec_auth" format=
"default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor c
ontrol server authentication.</t>
<t indent="0" pn="section-12.3.2-2">If the response is a UserStatus me
ssage, the client obtains information about the floor participant in a BENEFICIA
RY-INFORMATION grouped attribute and about the status of the floor requests asso
ciated with the floor participant in FLOOR-REQUEST-INFORMATION attributes.</t>
<t indent="0" pn="section-12.3.2-3">If the response is an Error messag
e, the floor control server could not process the UserQuery message for some rea
son, which is described in the Error message.</t>
</section>
</section>
<section anchor="sec_client_hello" numbered="true" toc="include" removeInR
FC="false" pn="section-12.4">
<name slugifiedName="name-obtaining-the-capabilities-">Obtaining the Cap
abilities of a Floor Control Server</name>
<t indent="0" pn="section-12.4-1">A client that wishes to obtain the cap
abilities of a floor control server does so by sending a Hello message to the fl
oor control server.</t>
<section anchor="sec_client_hello_send" numbered="true" toc="include" re
moveInRFC="false" pn="section-12.4.1">
<name slugifiedName="name-sending-a-hello-message">Sending a Hello Mes
sage</name>
<t indent="0" pn="section-12.4.1-1">The ABNF in <xref target="sec_msg_
format_Hello" format="default" sectionFormat="of" derivedContent="Section 5.3.11
"/> describes the attributes that a Hello message can contain. In addition, the
ABNF specifies normatively which of these attributes are mandatory, and which on
es are optional.</t>
<t indent="0" pn="section-12.4.1-2">The client sets the Conference ID
and the Transaction ID in the COMMON-HEADER following the rules given in <xref t
arget="sec_transactions_client" format="default" sectionFormat="of" derivedConte
nt="Section 8.1"/>. The client sets the User ID in the COMMON-HEADER to the clie
nt's identifier.</t>
</section>
<section anchor="sec_client_hello_responses" numbered="true" toc="includ
e" removeInRFC="false" pn="section-12.4.2">
<name slugifiedName="name-receiving-responses">Receiving Responses</na
me>
<t indent="0" pn="section-12.4.2-1">A message from the floor control s
erver is considered a response to the Hello message by the client if the message
from the floor control server has the same Conference ID, Transaction ID, and U
ser ID as the Hello message, as described in <xref target="sec_transactions_clie
nt" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On recei
ving such a response, the client follows the rules in <xref target="sec_auth" fo
rmat="default" sectionFormat="of" derivedContent="Section 9"/> that relate to fl
oor control server authentication.</t>
<t indent="0" pn="section-12.4.2-2">If the response is a HelloAck mess
age, the floor control server could process the Hello message successfully. The
SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes indicate which primitiv
es and attributes, respectively, are supported by the server.</t>
<t indent="0" pn="section-12.4.2-3">If the response is an Error messag
e, 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 anchor="sec_server" numbered="true" toc="include" removeInRFC="fals
<section title="Requesting Information about Floor Requests" anchor="sec:cli e" pn="section-13">
ent:info"> <name slugifiedName="name-floor-control-server-operat">Floor Control Serve
<t>A client can obtain information about the status of one or several floo r Operations</name>
r requests in different ways, which include using BFCP and using out-of-band mec <t indent="0" pn="section-13-1">This section specifies how floor control s
hanisms. Clients using BFCP to obtain such information use the procedures descri ervers can perform different operations, such as granting a floor, using the pro
bed in this section.</t> tocol elements described in earlier sections.</t>
<t>Clients request information about the current status of a floor request <t indent="0" pn="section-13-2">On reception of a message from a client, t
by sending a FloorRequestQuery message to the floor control server.</t> he floor control server <bcp14>MUST</bcp14> check whether the value of the primi
<t>Requesting information about a particular floor request is useful in a tive is supported. If it is not, the floor control server <bcp14>MUST</bcp14> s
number of situations. For example, on reception of a FloorRequest message, a flo end an Error message, as described in <xref target="sec_server_error" format="de
or control server may choose to return FloorRequestStatus messages only when the fault" sectionFormat="of" derivedContent="Section 13.8"/>, with Error Code 3 (Un
floor request changes its state (e.g., from Accepted to Granted), but not when known Primitive).</t>
the floor request advances in its queue. In this situation, if the user requests <t indent="0" pn="section-13-3">On reception of a message from a client, t
it, the floor participant can use a FloorRequestQuery message to poll the floor he floor control server <bcp14>MUST</bcp14> check whether the value of the Confe
control server for the status of the floor request.</t> rence ID matched an existing conference. If it does not, the floor control serve
r <bcp14>MUST</bcp14> send an Error message, as described in <xref target="sec_s
<section title="Sending a FloorRequestQuery Message" anchor="sec:client:in erver_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>
fo:send"> , with Error Code 1 (Conference Does Not Exist).</t>
<t>The ABNF in <xref target="sec:msg_format:FloorRequestQuery"/> describ <t indent="0" pn="section-13-4">On reception of a message from a client, t
es the attributes that a FloorRequestQuery message can contain. In addition, the he floor control server follows the rules in <xref target="sec_auth" format="def
ABNF specifies normatively which of these attributes are mandatory, and which o ault" sectionFormat="of" derivedContent="Section 9"/> that relate to the authent
nes are optional.</t> ication of the message.</t>
<t>The client sets the Conference ID and the Transaction ID in the commo <t indent="0" pn="section-13-5">On reception of a message from a client, t
n header following the rules given in <xref target="sec:transactions:client"/>. he floor control server <bcp14>MUST</bcp14> check whether it understands all the
The client sets the User ID in the common header to the client's identifier.</t> mandatory ('M' bit set) attributes in the message. If the floor control server
<t>The client MUST insert a FLOOR-REQUEST-ID attribute that identifies t does not understand all of them, the floor control server <bcp14>MUST</bcp14> se
he floor request at the floor control server.</t> nd an Error message, as described in <xref target="sec_server_error" format="def
ault" sectionFormat="of" derivedContent="Section 13.8"/>, with Error Code 4 (Unk
nown Mandatory Attribute). The Error message <bcp14>SHOULD</bcp14> list the attr
ibutes that were not understood.</t>
<section anchor="sec_server_request" numbered="true" toc="include" removeI
nRFC="false" pn="section-13.1">
<name slugifiedName="name-reception-of-a-floorrequest">Reception of a Fl
oorRequest Message</name>
<t indent="0" pn="section-13.1-1">On reception of a FloorRequest message
, the floor control server follows the rules in <xref target="sec_auth" format="
default" sectionFormat="of" derivedContent="Section 9"/> that relate to client a
uthentication and authorization. If while processing the FloorRequest message, t
he floor control server encounters an error, it <bcp14>MUST</bcp14> generate an
Error response following the procedures described in <xref target="sec_server_er
ror" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t>
<aside pn="section-13.1-2">
<t indent="0" pn="section-13.1-2.1">BFCP allows floor participants to
have several ongoing floor requests for the same floor (e.g., the same floor par
ticipant can occupy more than one position in a queue at the same time). A floor
control server that only supports a certain number of ongoing floor requests pe
r floor participant (e.g., one) can use Error Code 8 (You have Already Reached t
he Maximum Number of Ongoing Floor Requests for This Floor) to inform the floor
participant.</t>
</aside>
<t indent="0" pn="section-13.1-3">When communicating over an unreliable
transport and upon receiving a FloorRequest from a participant, the floor contro
l server <bcp14>MUST</bcp14> respond with a FloorRequestStatus message within th
e transaction failure window to complete the transaction.</t>
<section anchor="sec_server_request_first" numbered="true" toc="include"
removeInRFC="false" pn="section-13.1.1">
<name slugifiedName="name-generating-the-first-floorr">Generating the
First FloorRequestStatus Message</name>
<t indent="0" pn="section-13.1.1-1">The successful processing of a Flo
orRequest message by a floor control server involves generating one or several F
loorRequestStatus messages, the first of which <bcp14>SHOULD</bcp14> be generate
d as soon as possible. If the floor control server cannot accept, grant, or deny
the floor request right away (e.g., a decision from a chair is needed), it <bcp
14>SHOULD</bcp14> use a Request Status value of Pending in the OVERALL-REQUEST-S
TATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the
first FloorRequestStatus message it generates.</t>
<aside pn="section-13.1.1-2">
<t indent="0" pn="section-13.1.1-2.1">The policy that a floor contro
l server follows to grant or deny floors is outside the scope of this document.
A given floor control server may perform these decisions automatically while ano
ther may contact a human acting as a chair every time a decision needs to be mad
e.</t>
</aside>
<t indent="0" pn="section-13.1.1-3">The floor control server <bcp14>MU
ST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the
FloorRequest into the FloorRequestStatus, as described in <xref target="sec_tran
sactions_server" format="default" sectionFormat="of" derivedContent="Section 8.2
"/>. Additionally, the floor control server <bcp14>MUST</bcp14> add a FLOOR-REQU
EST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes cont
ained in this grouped attribute carry information about the floor request.</t>
<t indent="0" pn="section-13.1.1-4">The floor control server <bcp14>MU
ST</bcp14> assign an identifier that is unique within the conference to this flo
or request, and <bcp14>MUST</bcp14> insert it in the Floor Request ID field of t
he FLOOR-REQUEST-INFORMATION attribute. This identifier will be used by the floo
r participant (or by a chair or chairs) to refer to this specific floor request
in the future.</t>
<t indent="0" pn="section-13.1.1-5">The floor control server <bcp14>MU
ST</bcp14> copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest int
o the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped a
ttribute. These Floor IDs identify the floors being requested (i.e., the floors
associated with this particular floor request).</t>
<t indent="0" pn="section-13.1.1-6">The floor control server <bcp14>SH
OULD</bcp14> copy (if present) the contents of the BENEFICIARY-ID attribute from
the FloorRequest into a BENEFICIARY-INFORMATION attribute inside the FLOOR-REQU
EST-INFORMATION grouped attribute. Additionally, the floor control server <bcp14
>MAY</bcp14> provide the display name and the URI of the beneficiary in this BEN
EFICIARY-INFORMATION attribute.</t>
<t indent="0" pn="section-13.1.1-7">The floor control server <bcp14>MA
Y</bcp14> provide information about the requester of the floor in a REQUESTED-BY
-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.</
t>
<t indent="0" pn="section-13.1.1-8">The floor control server <bcp14>MA
Y</bcp14> copy (if present) the PRIORITY attribute from the FloorRequest into th
e FLOOR-REQUEST-INFORMATION grouped attribute.</t>
<aside pn="section-13.1.1-9">
<t indent="0" pn="section-13.1.1-9.1">Note that this attribute carri
es the priority requested by the participant. The priority that the floor contro
l server assigns to the floor request depends on the priority requested by the p
articipant and the rights the participant has according to the policy of the con
ference. For example, a participant that is only allowed to use the Normal prior
ity may request Highest priority for a floor request. In that case, the floor co
ntrol server would ignore the priority requested by the participant.</t>
</aside>
<t indent="0" pn="section-13.1.1-10">The floor control server <bcp14>M
AY</bcp14> copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the Fl
oorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.</t>
</section>
<section anchor="sec_server_request_subsequent" numbered="true" toc="inc
lude" removeInRFC="false" pn="section-13.1.2">
<name slugifiedName="name-generation-of-subsequent-fl">Generation of S
ubsequent FloorRequestStatus Messages</name>
<t indent="0" pn="section-13.1.2-1">A floor request is considered to b
e ongoing as long as it is not in the Cancelled, Released, or Revoked states. If
the OVERALL-REQUEST-STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grou
ped attribute) of the first FloorRequestStatus message generated by the floor co
ntrol server did not indicate any of these states, the floor control server will
need to send subsequent FloorRequestStatus messages.</t>
<t indent="0" pn="section-13.1.2-2">When the status of the floor reque
st changes, the floor control server <bcp14>SHOULD</bcp14> send new FloorRequest
Status messages with the appropriate Request Status. The floor control server <b
cp14>MUST</bcp14> add a FLOOR-REQUEST-INFORMATION attribute with a Floor Request
ID equal to the one sent in the first FloorRequestStatus message to any new Flo
orRequestStatus related to the same floor request. (The Floor Request ID identif
ies the floor request to which the FloorRequestStatus applies.)</t>
<t indent="0" pn="section-13.1.2-3">When using BFCP over a reliable tr
ansport, the floor control server <bcp14>MUST</bcp14> set the Transaction ID of
subsequent FloorRequestStatus messages to zero. When using BFCP over an unreliab
le transport, the Transaction ID <bcp14>MUST</bcp14> be non-zero and unique in t
he context of outstanding transactions over an unreliable transport as described
in <xref target="sec_transactions" format="default" sectionFormat="of" derivedC
ontent="Section 8"/>.</t>
<aside pn="section-13.1.2-4">
<t indent="0" pn="section-13.1.2-4.1">The rate at which the floor co
ntrol server sends FloorRequestStatus messages is a matter of local policy. A fl
oor control server may choose to send a new FloorRequestStatus message every tim
e the floor request moves in the floor request queue, while another may choose o
nly to send a new FloorRequestStatus message when the floor request is Granted o
r Denied.</t>
</aside>
<t indent="0" pn="section-13.1.2-5">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 pn="section-13.1.2-6">
<t indent="0" pn="section-13.1.2-6.1">Floor participants and floor c
hairs may request to be informed about the status of a floor following the proce
dures in <xref target="sec_client_floorinfo" format="default" sectionFormat="of"
derivedContent="Section 12.1"/>. If the processing of a floor request changes t
he status of a floor (e.g., the floor request is granted and consequently the fl
oor has a new holder), the floor control server needs to follow the procedures i
n <xref target="sec_server_floorinfo" format="default" sectionFormat="of" derive
dContent="Section 13.5"/> to inform the clients that have requested that informa
tion.</t>
</aside>
<t indent="0" pn="section-13.1.2-7">The COMMON-HEADER and the rest of
the attributes are the same as in the first FloorRequestStatus message.</t>
<t indent="0" pn="section-13.1.2-8">The floor control server can disca
rd the state information about a particular floor request when this reaches a st
atus of Cancelled, Released, or Revoked.</t>
<t indent="0" pn="section-13.1.2-9">When communicating over an unrelia
ble transport and a FloorRequestStatusAck message is not received within the tra
nsaction failure window, the floor control server <bcp14>MUST</bcp14> retransmit
the FloorRequestStatus message according to <xref target="udp_transport" format
="default" sectionFormat="of" derivedContent="Section 6.2"/>.</t>
</section>
</section> </section>
<section anchor="sec_server_requestinfo" numbered="true" toc="include" rem
<section title="Receiving a Response" anchor="sec:client:info:response"> oveInRFC="false" pn="section-13.2">
<t>A message from the floor control server is considered a response to t <name slugifiedName="name-reception-of-a-floorrequestq">Reception of a F
he FloorRequestQuery message if the message from the floor control server has th loorRequestQuery Message</name>
e same Conference ID, Transaction ID, and User ID as the FloorRequestQuery messa <t indent="0" pn="section-13.2-1">On reception of a FloorRequestQuery me
ge, as described in <xref target="sec:transactions:client"/>. On receiving such ssage, the floor control server follows the rules in <xref target="sec_auth" for
a response, the client follows the rules in <xref target="sec:auth"/> that rela mat="default" sectionFormat="of" derivedContent="Section 9"/> that relate to cli
te to floor control server authentication.</t> ent authentication and authorization. If while processing the FloorRequestQuery
<t>If the response is a FloorRequestStatus message, the client obtains i message, the floor control server encounters an error, it <bcp14>MUST</bcp14> ge
nformation about the status of the FloorRequest the client requested information nerate an Error response following the procedures described in <xref target="sec
about in a FLOOR-REQUEST-INFORMATION attribute.</t> _server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"
<t>If the response is an Error message, the floor control server could n />.</t>
ot process the FloorRequestQuery message for some reason, which is described in <t indent="0" pn="section-13.2-2">The successful processing of a FloorRe
the Error message.</t> questQuery message by a floor control server involves generating a FloorRequestS
tatus message, which <bcp14>SHOULD</bcp14> be generated as soon as possible.</t>
<t indent="0" pn="section-13.2-3">When communicating over an unreliable
transport and upon receiving a FloorRequestQuery from a participant, the floor c
ontrol server <bcp14>MUST</bcp14> respond with a FloorRequestStatus message with
in the transaction failure window to complete the transaction.</t>
<t indent="0" pn="section-13.2-4">The floor control server <bcp14>MUST</
bcp14> copy the Conference ID, the Transaction ID, and the User ID from the Floo
rRequestQuery message into the FloorRequestStatus message, as described in <xref
target="sec_transactions_server" format="default" sectionFormat="of" derivedCon
tent="Section 8.2"/>. Additionally, the floor control server <bcp14>MUST</bcp14>
include information about the floor request in the FLOOR-REQUEST-INFORMATION gr
ouped attribute to the FloorRequestStatus.</t>
<t indent="0" pn="section-13.2-5">The floor control server <bcp14>MUST</
bcp14> copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRequest
Query message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION a
ttribute.</t>
<t indent="0" pn="section-13.2-6">The floor control server <bcp14>MUST</
bcp14> add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grou
ped attribute identifying the floors being requested (i.e., the floors associate
d with the floor request identified by the FLOOR-REQUEST-ID attribute).</t>
<t indent="0" pn="section-13.2-7">The floor control server <bcp14>SHOULD
</bcp14> add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION grouped
attribute identifying the beneficiary of the floor request. 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 indent="0" pn="section-13.2-8">The floor control server <bcp14>MAY</b
cp14> provide information about the requester of the floor in a REQUESTED-BY-INF
ORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.</t>
<t indent="0" pn="section-13.2-9">The floor control server <bcp14>MAY</b
cp14> provide the reason why the floor participant requested the floor in a PART
ICIPANT-PROVIDED-INFO.</t>
<t indent="0" pn="section-13.2-10">The floor control server <bcp14>MAY</
bcp14> also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY at
tribute with the Priority value requested for the floor request and a STATUS-INF
O attribute with extra information about the floor request.</t>
<t indent="0" pn="section-13.2-11">The floor control server <bcp14>MUST<
/bcp14> add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION
grouped attribute with the current status of the floor request. The floor contr
ol server <bcp14>MAY</bcp14> provide information about the status of the floor r
equest as it relates to each of the floors being requested in the FLOOR-REQUEST-
STATUS attributes.</t>
</section> </section>
</section> <section anchor="sec_server_userinfo" numbered="true" toc="include" remove
InRFC="false" pn="section-13.3">
<section title="Requesting Information about a User" anchor="sec:client:user <name slugifiedName="name-reception-of-a-userquery-me">Reception of a Us
"> erQuery Message</name>
<t>A client can obtain information about a participant and the floor reque <t indent="0" pn="section-13.3-1">On reception of a UserQuery message, t
sts related to this participant in different ways, which include using BFCP and he floor control server follows the rules in <xref target="sec_auth" format="def
using out-of-band mechanisms. Clients using BFCP to obtain such information use ault" sectionFormat="of" derivedContent="Section 9"/> that relate to client auth
the procedures described in this section.</t> entication and authorization. If while processing the UserQuery message, the flo
<t>Clients request information about a participant and the floor requests or control server encounters an error, it <bcp14>MUST</bcp14> generate an Error
related to this participant by sending a UserQuery message to the floor control response following the procedures described in <xref target="sec_server_error" f
server.</t> ormat="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t>
<t>This functionality may be useful for floor chairs or floor participants <t indent="0" pn="section-13.3-2">The successful processing of a UserQue
interested in the display name and the URI of a particular floor participant. I ry message by a floor control server involves generating a UserStatus message, w
n addition, a floor participant may find it useful to request information about hich <bcp14>SHOULD</bcp14> be generated as soon as possible.</t>
itself. For example, a floor participant, after experiencing connectivity proble <t indent="0" pn="section-13.3-3">When communicating over an unreliable
ms (e.g., its TCP connection with the floor control server was down for a while transport and upon receiving a UserQuery from a participant, the floor control s
and eventually was re-established), may need to request information about all th erver <bcp14>MUST</bcp14> respond with a UserStatus message within the transacti
e floor requests associated to itself that still exist.</t> on failure window to complete the transaction.</t>
<t indent="0" pn="section-13.3-4">The floor control server <bcp14>MUST</
<section title="Sending a UserQuery Message" anchor="sec:client:user:send" bcp14> copy the Conference ID, the Transaction ID, and the User ID from the User
> Query message into the UserStatus message, as described in <xref target="sec_tra
<t>The ABNF in <xref target="sec:msg_format:UserQuery"/> describes the a nsactions_server" format="default" sectionFormat="of" derivedContent="Section 8.
ttributes that a UserQuery message can contain. In addition, the ABNF specifies 2"/>.</t>
normatively which of these attributes are mandatory, and which ones are optional <t indent="0" pn="section-13.3-5">The sender of the UserQuery message is
.</t> requesting information about all the floor requests associated with a given par
<t>The client sets the Conference ID and the Transaction ID in the commo ticipant (i.e., the floor requests where the participant is either the beneficia
n header following the rules given in <xref target="sec:transactions:client"/>. ry or the requester). This participant is identified by a BENEFICIARY-ID attribu
The client sets the User ID in the common header to the client's identifier.</t> te or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in the COM
<t>If the floor participant the client is requesting information about i MON-HEADER of the UserQuery message.</t>
s not the client issuing the UserQuery message (which is identified by the User <t indent="0" pn="section-13.3-6">The floor control server <bcp14>MUST</
ID in the common header of the message), the client MUST insert a BENEFICIARY-ID bcp14> copy, if present, the contents of the BENEFICIARY-ID attribute from the U
attribute.</t> serQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus mess
age. Additionally, the floor control server <bcp14>MAY</bcp14> provide the displ
ay name and the URI of the participant about which the UserStatus message provid
es information in this BENEFICIARY-INFORMATION attribute.</t>
<t indent="0" pn="section-13.3-7">The floor control server <bcp14>SHOULD
</bcp14> add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attri
bute for each floor request related to the participant about which the message p
rovides information (i.e., the floor requests where the participant is either th
e beneficiary or the requester). For each FLOOR-REQUEST-INFORMATION attribute, t
he floor control server follows the following steps.</t>
<t indent="0" pn="section-13.3-8">The floor control server <bcp14>MUST</
bcp14> identify the floor request the FLOOR-REQUEST-INFORMATION attribute applie
s to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attr
ibute.</t>
<t indent="0" pn="section-13.3-9">The floor control server <bcp14>MUST</
bcp14> add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grou
ped attribute identifying the floors being requested (i.e., the floors associate
d with the floor request identified by the FLOOR-REQUEST-ID attribute).</t>
<t indent="0" pn="section-13.3-10">The floor control server <bcp14>SHOUL
D</bcp14> add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION groupe
d attribute identifying the beneficiary of the floor request. 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 indent="0" pn="section-13.3-11">The floor control server <bcp14>MAY</
bcp14> provide information about the requester of the floor in a REQUESTED-BY-IN
FORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.</t>
<t indent="0" pn="section-13.3-12">The floor control server <bcp14>MAY</
bcp14> provide the reason why the floor participant requested the floor in a PAR
TICIPANT-PROVIDED-INFO.</t>
<t indent="0" pn="section-13.3-13">The floor control server <bcp14>MAY</
bcp14> also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY at
tribute with the Priority value requested for the floor request.</t>
<t indent="0" pn="section-13.3-14">The floor control server <bcp14>MUST<
/bcp14> include the current status of the floor request in an OVERALL-REQUEST-ST
ATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The floor con
trol server <bcp14>MAY</bcp14> add a STATUS-INFO attribute with extra informatio
n about the floor request.</t>
<t indent="0" pn="section-13.3-15">The floor control server <bcp14>MAY</
bcp14> provide information about the status of the floor request as it relates t
o each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.</t>
</section> </section>
<section anchor="sec_server_release" numbered="true" toc="include" removeI
<section title="Receiving a Response" anchor="sec:client:user:response"> nRFC="false" pn="section-13.4">
<t>A message from the floor control server is considered a response to t <name slugifiedName="name-reception-of-a-floorrelease">Reception of a Fl
he UserQuery message if the message from the floor control server has the same C oorRelease Message</name>
onference ID, Transaction ID, and User ID as the UserQuery message, as described <t indent="0" pn="section-13.4-1">On reception of a FloorRelease message
in <xref target="sec:transactions:client"/>. On receiving such a response, the , the floor control server follows the rules in <xref target="sec_auth" format="
client follows the rules in <xref target="sec:auth"/> that relate to floor cont default" sectionFormat="of" derivedContent="Section 9"/> that relate to client a
rol server authentication.</t> uthentication and authorization. If while processing the FloorRelease message, t
<t>If the response is a UserStatus message, the client obtains informati he floor control server encounters an error, it <bcp14>MUST</bcp14> generate an
on about the floor participant in a BENEFICIARY-INFORMATION grouped attribute an Error response following the procedures described in <xref target="sec_server_er
d about the status of the floor requests associated with the floor participant i ror" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t>
n FLOOR-REQUEST-INFORMATION attributes.</t> <t indent="0" pn="section-13.4-2">The successful processing of a FloorRe
<t>If the response is an Error message, the floor control server could n lease message by a floor control server involves generating a FloorRequestStatus
ot process the UserQuery message for some reason, which is described in the Erro message, which <bcp14>SHOULD</bcp14> be generated as soon as possible.</t>
r message.</t> <t indent="0" pn="section-13.4-3">When communicating over an unreliable
transport and upon receiving a FloorRelease from a participant, the floor contro
l server <bcp14>MUST</bcp14> respond with a FloorRequestStatus message within th
e transaction failure window to complete the transaction.</t>
<t indent="0" pn="section-13.4-4">The floor control server <bcp14>MUST</
bcp14> copy the Conference ID, the Transaction ID, and the User ID from the Floo
rRelease message into the FloorRequestStatus message, as described in <xref targ
et="sec_transactions_server" format="default" sectionFormat="of" derivedContent=
"Section 8.2"/>.</t>
<t indent="0" pn="section-13.4-5">The floor control server <bcp14>MUST</
bcp14> add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStat
us. The attributes contained in this grouped attribute carry information about t
he floor request.</t>
<t indent="0" pn="section-13.4-6">The FloorRelease message identifies th
e floor request it applies to using a FLOOR-REQUEST-ID. The floor control server
<bcp14>MUST</bcp14> copy the contents of the FLOOR-REQUEST-ID attribute from th
e FloorRelease message into the Floor Request ID field of the FLOOR-REQUEST-INFO
RMATION attribute.</t>
<t indent="0" pn="section-13.4-7">The floor control server <bcp14>MUST</
bcp14> identify the floors being released (i.e., the floors associated with the
floor request identified by the FLOOR-REQUEST-ID attribute) in FLOOR-REQUEST-STA
TUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute.</t>
<t indent="0" pn="section-13.4-8">The floor control server <bcp14>MUST</
bcp14> add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION
grouped attribute. The Request Status value <bcp14>SHOULD</bcp14> be Released,
if the floor (or floors) had been previously granted, or Cancelled, if the floor
(or floors) had not been previously granted. The floor control server <bcp14>M
AY</bcp14> add a STATUS-INFO attribute with extra information about the floor re
quest.</t>
</section> </section>
</section> <section anchor="sec_server_floorinfo" numbered="true" toc="include" remov
eInRFC="false" pn="section-13.5">
<section title="Obtaining the Capabilities of a Floor Control Server" anchor <name slugifiedName="name-reception-of-a-floorquery-m">Reception of a Fl
="sec:client:hello"> oorQuery Message</name>
<t>A client that wishes to obtain the capabilities of a floor control serv <t indent="0" pn="section-13.5-1">On reception of a FloorQuery message,
er does so by sending a Hello message to the floor control server.</t> the floor control server follows the rules in <xref target="sec_auth" format="de
fault" sectionFormat="of" derivedContent="Section 9"/> that relate to client aut
<section title="Sending a Hello Message" anchor="sec:client:hello:send"> hentication. If while processing the FloorQuery message, the floor control serve
<t>The ABNF in <xref target="sec:msg_format:Hello"/> describes the attri r encounters an error, it <bcp14>MUST</bcp14> generate an Error response followi
butes that a Hello message can contain. In addition, the ABNF specifies normativ ng the procedures described in <xref target="sec_server_error" format="default"
ely which of these attributes are mandatory, and which ones are optional.</t> sectionFormat="of" derivedContent="Section 13.8"/>.</t>
<t>The client sets the Conference ID and the Transaction ID in the commo <t indent="0" pn="section-13.5-2">When communicating over an unreliable
n header following the rules given in <xref target="sec:transactions:client"/>. transport and upon receiving a FloorQuery from a participant, the floor control
The client sets the User ID in the common header to the client's identifier.</t> server <bcp14>MUST</bcp14> respond with a FloorStatus message within the transac
tion failure window to complete the transaction.</t>
<t indent="0" pn="section-13.5-3">A floor control server receiving a Flo
orQuery message from a client <bcp14>SHOULD</bcp14> keep this client informed ab
out the status of the floors identified by FLOOR-ID attributes in the FloorQuery
message. Floor control servers keep clients informed by using FloorStatus messa
ges.</t>
<t indent="0" pn="section-13.5-4">An individual FloorStatus message carr
ies information about a single floor. So, when a FloorQuery message requests inf
ormation about more than one floor, the floor control server needs to send separ
ate FloorStatus messages for different floors.</t>
<t indent="0" pn="section-13.5-5">The information FloorQuery messages ca
rry may depend on the user requesting the information. For example, a chair may
be able to receive information about pending requests, while a regular user may
not be authorized to do so.</t>
<section anchor="sec_server_floorinfo_first" numbered="true" toc="includ
e" removeInRFC="false" pn="section-13.5.1">
<name slugifiedName="name-generation-of-the-first-flo">Generation of t
he First FloorStatus Message</name>
<t indent="0" pn="section-13.5.1-1">The successful processing of a Flo
orQuery message by a floor control server involves generating one or several Flo
orStatus messages, the first of which <bcp14>SHOULD</bcp14> be generated as soon
as possible.</t>
<t indent="0" pn="section-13.5.1-2">The floor control server <bcp14>MU
ST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the
FloorQuery message into the FloorStatus message, as described in <xref target="s
ec_transactions_server" format="default" sectionFormat="of" derivedContent="Sect
ion 8.2"/>.</t>
<t indent="0" pn="section-13.5.1-3">If the FloorQuery message did not
contain any FLOOR-ID attribute, the floor control server sends the FloorStatus m
essage without adding any additional attribute and does not send any subsequent
FloorStatus message to the floor participant.</t>
<t indent="0" pn="section-13.5.1-4">If the FloorQuery message containe
d one or more FLOOR-ID attributes, the floor control server chooses one from amo
ng them and adds this FLOOR-ID attribute to the FloorStatus message. The floor c
ontrol server <bcp14>SHOULD</bcp14> add a FLOOR-REQUEST-INFORMATION grouped attr
ibute for each floor request associated to the floor. Each FLOOR-REQUEST-INFORMA
TION grouped attribute contains a number of attributes that provide information
about the floor request. For each FLOOR-REQUEST-INFORMATION attribute, the floor
control server follows the following steps.</t>
<t indent="0" pn="section-13.5.1-5">The floor control server <bcp14>MU
ST</bcp14> identify the floor request the FLOOR-REQUEST-INFORMATION attribute ap
plies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION
attribute.</t>
<t indent="0" pn="section-13.5.1-6">The floor control server <bcp14>MU
ST</bcp14> add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION
grouped attribute identifying the floors being requested (i.e., the floors assoc
iated with the floor request identified by the FLOOR-REQUEST-ID attribute).</t>
<t indent="0" pn="section-13.5.1-7">The floor control server <bcp14>SH
OULD</bcp14> add a BENEFICIARY-ID attribute to the FLOOR-REQUEST-INFORMATION gro
uped attribute identifying the beneficiary of the floor request. 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 indent="0" pn="section-13.5.1-8">The floor control server <bcp14>MA
Y</bcp14> provide information about the requester of the floor in a REQUESTED-BY
-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.</
t>
<t indent="0" pn="section-13.5.1-9">The floor control server <bcp14>MA
Y</bcp14> provide the reason why the floor participant requested the floor in a
PARTICIPANT-PROVIDED-INFO.</t>
<t indent="0" pn="section-13.5.1-10">The floor control server <bcp14>M
AY</bcp14> also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORIT
Y attribute with the Priority value requested for the floor request.</t>
<t indent="0" pn="section-13.5.1-11">The floor control server <bcp14>M
UST</bcp14> add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMA
TION grouped attribute with the current status of the floor request. The floor c
ontrol server <bcp14>MAY</bcp14> add a STATUS-INFO attribute with extra informat
ion about the floor request.</t>
<t indent="0" pn="section-13.5.1-12">The floor control server <bcp14>M
AY</bcp14> provide information about the status of the floor request as it relat
es to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.
</t>
</section>
<section anchor="sec_server_floorinfo_subsequent" numbered="true" toc="i
nclude" removeInRFC="false" pn="section-13.5.2">
<name slugifiedName="name-generation-of-subsequent-flo">Generation of
Subsequent FloorStatus Messages</name>
<t indent="0" pn="section-13.5.2-1">If the FloorQuery message carried
more than one FLOOR-ID attribute, the floor control server <bcp14>SHOULD</bcp14>
generate a FloorStatus message for each of them (except for the FLOOR-ID attrib
ute chosen for the first FloorStatus message) as soon as possible. These FloorSt
atus messages are generated following the same rules as those for the first Floo
rStatus message (see <xref target="sec_server_floorinfo_first" format="default"
sectionFormat="of" derivedContent="Section 13.5.1"/>), but their Transaction ID
is 0 when using a reliable transport and non-zero and unique in the context of o
utstanding transactions when using an unreliable transport (cf. <xref target="se
c_transactions" format="default" sectionFormat="of" derivedContent="Section 8"/>
).</t>
<t indent="0" pn="section-13.5.2-2">After generating these messages, t
he floor control server sends FloorStatus messages, periodically keeping the cli
ent informed about all the floors for which the client requested information. Th
e Transaction ID of these messages <bcp14>MUST</bcp14> be 0 when using a reliabl
e transport and non-zero and unique in the context of outstanding transactions w
hen using an unreliable transport (cf. <xref target="sec_transactions" format="d
efault" sectionFormat="of" derivedContent="Section 8"/>).</t>
<aside pn="section-13.5.2-3">
<t indent="0" pn="section-13.5.2-3.1">The rate at which the floor co
ntrol server sends FloorStatus messages is a matter of local policy. A floor con
trol server may choose to send a new 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 Granted.</t>
</aside>
<t indent="0" pn="section-13.5.2-4">When communicating over an unrelia
ble transport and a FloorStatusAck message is not received within the transactio
n failure window, the floor control server <bcp14>MUST</bcp14> retransmit the Fl
oorStatus message according to <xref target="udp_transport" format="default" sec
tionFormat="of" derivedContent="Section 6.2"/>.</t>
</section>
</section> </section>
<section anchor="sec_server_chairaction" numbered="true" toc="include" rem
<section title="Receiving Responses" anchor="sec:client:hello:responses"> oveInRFC="false" pn="section-13.6">
<t>A message from the floor control server is considered a response to t <name slugifiedName="name-reception-of-a-chairaction-">Reception of a Ch
he Hello message by the client if the message from the floor control server has airAction Message</name>
the same Conference ID, Transaction ID, and User ID as the Hello message, as des <t indent="0" pn="section-13.6-1">On reception of a ChairAction message,
cribed in <xref target="sec:transactions:client"/>. On receiving such a response the floor control server follows the rules in <xref target="sec_auth" format="d
, the client follows the rules in <xref target="sec:auth"/> that relate to floor efault" sectionFormat="of" derivedContent="Section 9"/> that relate to client au
control server authentication.</t> thentication and authorization. If while processing the ChairAction message, the
<t>If the response is a HelloAck message, the floor control server could floor control server encounters an error, it <bcp14>MUST</bcp14> generate an Er
process the Hello message successfully. The SUPPORTED-PRIMITIVES and SUPPORTED- ror response following the procedures described in <xref target="sec_server_erro
ATTRIBUTES attributes indicate which primitives and attributes, respectively, ar r" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t>
e supported by the server.</t> <t indent="0" pn="section-13.6-2">The successful processing of a ChairAc
<t>If the response is an Error message, the floor control server could n tion message by a floor control server involves generating a ChairActionAck mess
ot process the Hello message for some reason, which is described in the Error me age, which <bcp14>SHOULD</bcp14> be generated as soon as possible.</t>
ssage.</t> <t indent="0" pn="section-13.6-3">When communicating over an unreliable
transport and upon receiving a ChairAction from a chair, the floor control serve
r <bcp14>MUST</bcp14> respond with a ChairActionAck message within the transacti
on failure window to complete the transaction.</t>
<t indent="0" pn="section-13.6-4">The floor control server <bcp14>MUST</
bcp14> copy the Conference ID, the Transaction ID, and the User ID from the Chai
rAction message into the ChairActionAck message, as described in <xref target="s
ec_transactions_server" format="default" sectionFormat="of" derivedContent="Sect
ion 8.2"/>.</t>
<t indent="0" pn="section-13.6-5">The floor control server needs to take
into consideration the operation requested in the ChairAction message (e.g., gr
anting a floor) but does not necessarily 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 indent="0" pn="section-13.6-6">For example, a floor chair may send a
ChairAction message granting a floor that was requested as part of an atomic flo
or request operation that involved several floors. Even if the chair responsible
for one of the floors instructs the floor control server to grant the floor, th
e floor control server will not grant it until the chairs responsible for the ot
her floors agree to grant them as well.</t>
<t indent="0" pn="section-13.6-7">So, the floor control server is ultima
tely responsible for keeping a coherent floor state using instructions from floo
r chairs as input to this state.</t>
<t indent="0" pn="section-13.6-8">If the new Status in the ChairAction m
essage is Accepted and all the bits of the Queue Position field are zero, the fl
oor chair is requesting that the floor control server assign a queue position (e
.g., the last in the queue) to the floor request based on the local policy of th
e floor control server. (Of course, such a request only applies if the floor con
trol server implements a queue.)</t>
</section> </section>
</section> <section anchor="sec_server_helloack" numbered="true" toc="include" remove
</section> InRFC="false" pn="section-13.7">
<name slugifiedName="name-reception-of-a-hello-messag">Reception of a He
<section title="Floor Control Server Operations" anchor="sec:server"> llo Message</name>
<t>This section specifies how floor control servers can perform different op <t indent="0" pn="section-13.7-1">On reception of a Hello message, the f
erations, such as granting a floor, using the protocol elements described in ear loor control server follows the rules in <xref target="sec_auth" format="default
lier sections.</t> " sectionFormat="of" derivedContent="Section 9"/> that relate to client authenti
<t>On reception of a message from a client, the floor control server MUST ch cation. If while processing the Hello message, the floor control server encounte
eck whether the value of the Primitive is supported. If it is not, the floor co rs an error, it <bcp14>MUST</bcp14> generate an Error response following the pro
ntrol server MUST send an Error message, as described in <xref target="sec:serve cedures described in <xref target="sec_server_error" format="default" sectionFor
r:error"/>, with Error code 3 (Unknown Primitive).</t> mat="of" derivedContent="Section 13.8"/>.</t>
<t>On reception of a message from a client, the floor control server MUST ch <t indent="0" pn="section-13.7-2">If the version of BFCP specified in th
eck whether the value of the Conference ID matched an existing conference. If it e version field of the COMMON-HEADER is supported by the floor control server, i
does not, the floor control server MUST send an Error message, as described in t <bcp14>MUST</bcp14> respond with the same version number in the HelloAck; this
<xref target="sec:server:error"/>, with Error code 1 (Conference does not Exist) defines the version for all subsequent BFCP messages within this BFCP Connectio
.</t> n.</t>
<t>On reception of a message from a client, the floor control server follows <t indent="0" pn="section-13.7-3">When communicating over an unreliable
the rules in <xref target="sec:auth"/> that relate to the authentication of the transport and upon receiving a Hello from a participant, the floor control serve
message.</t> r <bcp14>MUST</bcp14> respond with a HelloAck message within the transaction fai
<t>On reception of a message from a client, the floor control server MUST ch lure window to complete the transaction.</t>
eck whether it understands all the mandatory ('M' bit set) attributes in the mes <t indent="0" pn="section-13.7-4">The successful processing of a Hello m
sage. If the floor control server does not understand all of them, the floor con essage by a floor control server involves generating a HelloAck message, which <
trol server MUST send an Error message, as described in <xref target="sec:server bcp14>SHOULD</bcp14> be generated as soon as possible. The floor control server
:error"/>, with Error code 4 (Unknown Mandatory Attribute). The Error message SH <bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID
OULD list the attributes that were not understood.</t> from the Hello into the HelloAck, as described in <xref target="sec_transactions
_server" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</t>
<section title="Reception of a FloorRequest Message" anchor="sec:server:requ <t indent="0" pn="section-13.7-5">The floor control server <bcp14>MUST</
est"> bcp14> add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all
<t>On reception of a FloorRequest message, the floor control server follow the primitives (i.e., BFCP messages) supported by the floor control server.</t>
s the rules in <xref target="sec:auth"/> that relate to client authentication an <t indent="0" pn="section-13.7-6">The floor control server <bcp14>MUST</
d authorization. If while processing the FloorRequest message, the floor control bcp14> add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all
server encounters an error, it MUST generate an Error response following the pr the attributes supported by the floor control server.</t>
ocedures described in <xref target="sec:server:error"/>.</t>
<t><list style="hanging">
<t>BFCP allows floor participants to have several ongoing floor reques
ts for the same floor (e.g., the same floor participant can occupy more than one
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
ec:server:request:first">
<t>The successful processing of a FloorRequest message by a floor contro
l server involves generating one or several FloorRequestStatus messages, the fir
st of which SHOULD be generated as soon as possible. If the floor control server
cannot accept, grant, or deny the floor request right away (e.g., a decision fr
om a chair is needed), it SHOULD use a Request Status value of Pending in the OV
ERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped att
ribute) of the first FloorRequestStatus message it generates.</t>
<t><list style="hanging">
<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>
</list></t>
<t>The floor control server MUST copy the Conference ID, the Transaction
ID, and the User ID from the FloorRequest into the FloorRequestStatus, as descr
ibed in <xref target="sec:transactions:server"/>. Additionally, the floor contro
l server MUST add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequ
estStatus. The attributes contained in this grouped attribute carry information
about the floor request.</t>
<t>The floor control server MUST assign an identifier that is unique wit
hin the conference to this floor request, and MUST insert it in the Floor Reques
t ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be u
sed by the floor participant (or by a chair or chairs) to refer to this specific
floor request in the future.</t>
<t>The floor control server MUST copy the Floor IDs in the FLOOR-ID attr
ibutes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR
-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors bein
g requested (i.e., the floors associated with this particular floor request).</t
>
<t>The floor control server SHOULD copy (if present) the contents of the
BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-INFORMATION a
ttribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, t
he floor control server MAY provide the display name and the URI of the benefici
ary 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-IN
FORMATION grouped attribute.</t>
<t>The floor control server MAY copy (if present) the PRIORITY attribute
from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.</t>
<!-- note: assumed bug in RFC 4582. s/PARTICIPANT-PROVIDED-INFO attr/PRIORITY a
ttr/ -->
<t><list style="empty">
<t>Note that this attribute carries the priority requested by the
participant. The priority that the floor control server assigns to the floor req
uest depends on the priority requested by the participant and the rights the par
ticipant has according to the policy of the conference. For example, a participa
nt that is only allowed to use the Normal priority may request Highest priority
for a floor request. In that case, the floor control server would ignore the pri
ority requested by the participant.</t>
</list></t>
<t>The floor control server MAY copy (if present) the PARTICIPANT-PROVID
ED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION group
ed attribute.</t>
</section> </section>
<section anchor="sec_server_error" numbered="true" toc="include" removeInR
<section title="Generation of Subsequent FloorRequestStatus Messages" anch FC="false" pn="section-13.8">
or="sec:server:request:subsequent"> <name slugifiedName="name-error-message-generation">Error Message Genera
<t>A floor request is considered to be ongoing as long as it is not in t tion</name>
he Cancelled, Released, or Revoked states. If the OVERALL-REQUEST-STATUS attribu <t indent="0" pn="section-13.8-1">Error messages are always sent in resp
te (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRe onse to a previous message from the client as part of a client-initiated transac
questStatus message generated by the floor control server did not indicate any o tion. The ABNF in <xref target="sec_msg_format_Error" format="default" sectionFo
f these states, the floor control server will need to send subsequent FloorReque rmat="of" derivedContent="Section 5.3.13"/> describes the attributes that an Err
stStatus messages.</t> or message can contain. In addition, the ABNF specifies normatively which of the
<t>When the status of the floor request changes, the floor control serve se attributes are mandatory and which ones are optional.</t>
r SHOULD send new FloorRequestStatus messages with the appropriate Request Statu <t indent="0" pn="section-13.8-2">The floor control server <bcp14>MUST</
s. The floor control server MUST add a FLOOR-REQUEST-INFORMATION attribute with bcp14> copy the Conference ID, the Transaction ID, and the User ID from the mess
a Floor Request ID equal to the one sent in the first FloorRequestStatus message age from the client into the Error message, as described in <xref target="sec_tr
to any new FloorRequestStatus related to the same floor request. (The Floor Req ansactions_server" format="default" sectionFormat="of" derivedContent="Section 8
uest ID identifies the floor request to which the FloorRequestStatus applies.)</ .2"/>.</t>
t> <t indent="0" pn="section-13.8-3">The floor control server <bcp14>MUST</
<t>When using BFCP over a reliable transport, the floor control server M bcp14> add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribut
UST set the Transaction ID of subsequent FloorRequestStatus messages to 0. When e contains an error code from <xref target="tab_errorcode" format="default" sect
using BFCP over an unreliable transport, the Transaction ID MUST be non-zero and ionFormat="of" derivedContent="Table 5"/>. Additionally, the floor control serve
unique in the context of outstanding transactions over an unreliable transport r may add an ERROR-INFO attribute with extra information about the error.</t>
as described in <xref target="sec:transactions"/>.</t>
<t><list style="hanging">
<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>
</list></t>
<t>The floor control server may add a STATUS-INFO attribute to any of th
e FloorRequestStatus messages it generates to provide extra information about it
s decisions regarding the floor request (e.g., why it was denied).</t>
<t><list style="hanging">
<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"/>. If the processing of a floor request changes the status 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 <xref target="sec:s
erver:floorinfo"/> to inform the clients that have requested that information.</
t>
</list></t>
<t>The common header and the rest of the attributes are the same as in t
he first FloorRequestStatus message.</t>
<t>The floor control server can discard the state information about a pa
rticular floor request when this reaches a status of Cancelled, Released, or Rev
oked.</t>
<t>When communicating over an unreliable transport and a FloorRequestSta
tusAck message is not received within the transaction failure window, the floor
control server MUST retransmit the FloorRequestStatus message according to <xref
target="udp_transport"/>.</t>
</section> </section>
</section> </section>
<section anchor="sec_security" numbered="true" toc="include" removeInRFC="fa
<section title="Reception of a FloorRequestQuery Message" anchor="sec:server lse" pn="section-14">
:requestinfo"> <name slugifiedName="name-security-considerations">Security Considerations
<t>On reception of a FloorRequestQuery message, the floor control server f </name>
ollows the rules in <xref target="sec:auth"/> that relate to client authenticati <t indent="0" pn="section-14-1">BFCP uses TLS/DTLS to provide mutual authe
on and authorization. If while processing the FloorRequestQuery message, the flo ntication between clients and servers. TLS/DTLS also provides replay and integri
or control server encounters an error, it MUST generate an Error response follow ty protection and confidentiality. It is <bcp14>RECOMMENDED</bcp14> that TLS/DT
ing the procedures described in <xref target="sec:server:error"/>.</t> LS with an encryption algorithm according to <xref target="sec_lower-security" f
<t>The successful processing of a FloorRequestQuery message by a floor con ormat="default" sectionFormat="of" derivedContent="Section 7"/> always be used.
trol server involves generating a FloorRequestStatus message, which SHOULD be ge In cases where signaling/control traffic is properly protected, as described in
nerated as soon as possible.</t> <xref target="sec_auth" format="default" sectionFormat="of" derivedContent="Sec
<t>When communicating over an unreliable transport and upon receiving a Fl tion 9"/>, it is <bcp14>REQUIRED</bcp14> to use a mandated encryption algorithm.
oorRequestQuery from a participant, the floor control server MUST respond with a BFCP entities <bcp14>MAY</bcp14> use other security mechanisms to interwork wi
FloorRequestStatus message within the transaction failure window to complete th th legacy implementation that do not use TLS/DTLS as long as these mechanisms pr
e transaction.</t> ovide similar security properties. An example of other mechanisms to effectivel
<t>The floor control server MUST copy the Conference ID, the Transaction I y secure a nonsecure BFCP connection is IPsec <xref target="RFC4301" format="def
D, and the User ID from the FloorRequestQuery message into the FloorRequestStatu ault" sectionFormat="of" derivedContent="21"/>.</t>
s message, as described in <xref target="sec:transactions:server"/>. Additionall <t indent="0" pn="section-14-2">The remainder of this section analyzes som
y, the floor control server MUST include information about the floor request in e of the threats against BFCP and how they are addressed.</t>
the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus.</t> <t indent="0" pn="section-14-3">An attacker may attempt to impersonate a c
<t>The floor control server MUST copy the contents of the FLOOR-REQUEST-ID lient (a floor participant or a floor chair) in order to generate forged floor r
attribute from the FloorRequestQuery message into the Floor Request ID field of equests or to grant or deny existing floor requests. Client impersonation is avo
the FLOOR-REQUEST-INFORMATION attribute.</t> ided by having servers only accept BFCP messages over authenticated TLS/DTLS con
<t>The floor control server MUST add FLOOR-REQUEST-STATUS attributes to th nections. The floor control server assumes that attackers cannot hijack the TLS/
e FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being reque DTLS connection and, therefore, that messages over the TLS/DTLS connection come
sted (i.e., the floors associated with the floor request identified by the FLOOR from the client that was initially authenticated.</t>
-REQUEST-ID attribute).</t> <t indent="0" pn="section-14-4">An attacker may attempt to impersonate a f
<t>The floor control server SHOULD add a BENEFICIARY-ID attribute to the F loor control server. A successful attacker would be able to make clients think t
LOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the fl hat they hold a particular floor so that they would try to access a resource (e.
oor request. Additionally, the floor control server MAY provide the display nam g., sending media) without having legitimate rights to access it. Floor control
e and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t> server impersonation is avoided by having servers only accept BFCP messages over
<t>The floor control server MAY provide information about the requester of authenticated TLS/DTLS connections, as well as ensuring clients only send and a
the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFO ccept messages over authenticated TLS/DTLS connections.</t>
RMATION grouped attribute.</t> <t indent="0" pn="section-14-5">Attackers may attempt to modify messages e
<t>The floor control server MAY provide the reason why the floor participa xchanged by a client and a floor control server. The integrity protection provid
nt requested the floor in a PARTICIPANT-PROVIDED-INFO.</t> ed by TLS/DTLS connections prevents this attack.</t>
<t>The floor control server MAY also add to the FLOOR-REQUEST-INFORMATION <t indent="0" pn="section-14-6">An attacker may attempt to fetch a valid m
grouped attribute a PRIORITY attribute with the Priority value requested for the essage sent by a client to a floor control server and replay it over a connectio
floor request and a STATUS-INFO attribute with extra information about the floo n between the attacker and the floor control server. This attack is prevented by
r request.</t> having floor control servers check that messages arriving over a given authenti
<t>The floor control server MUST add an OVERALL-REQUEST-STATUS attribute t cated TLS/DTLS connection use an authorized user ID (i.e., a user ID that the us
o the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of the er that established the authenticated TLS/DTLS connection is allowed to use).</t
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 <t indent="0" pn="section-14-7">Attackers may attempt to pick messages fro
e FLOOR-REQUEST-STATUS attributes.</t> m the network to get access to confidential information between the floor contro
</section> l server and a client (e.g., why a floor request was denied). TLS/DTLS confident
iality prevents this attack. Therefore, it is <bcp14>REQUIRED</bcp14> that TLS/D
<section title="Reception of a UserQuery Message" anchor="sec:server:userinf TLS be used with an encryption algorithm according to <xref target="sec_lower-se
o"> curity" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t>
<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
ase">
<t>On reception of a FloorRelease message, the floor control server follow
s the rules in <xref target="sec:auth"/> that relate to client authentication an
d authorization. If while processing the FloorRelease message, the floor control
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>
<section anchor="sec_iana" numbered="true" toc="include" removeInRFC="false"
<section title="Reception of a FloorQuery Message" anchor="sec:server:floori pn="section-15">
nfo"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>On reception of a FloorQuery message, the floor control server follows <t indent="0" pn="section-15-1">The IANA has created a registry for BFCP p
the rules in <xref target="sec:auth"/> that relate to client authentication. If arameters called "The Binary Floor Control Protocol (BFCP) Parameters". This reg
while processing the FloorQuery message, the floor control server encounters an istry has a number of subregistries, which are described in the following sectio
error, it MUST generate an Error response following the procedures described in ns.</t>
<xref target="sec:server:error"/>.</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-15.
<t>When communicating over an unreliable transport and upon receiving a Fl 1">
oorQuery from a participant, the floor control server MUST respond with a FloorS <name slugifiedName="name-attributes-subregistry">Attributes Subregistry
tatus message within the transaction failure window to complete the transaction. </name>
</t> <t indent="0" pn="section-15.1-1">This section establishes the "Attribut
<t>A floor control server receiving a FloorQuery message from a client SHO es" subregistry under the BFCP
ULD keep this client informed about the status of the floors identified by FLOOR Parameters registry. As per the terminology in RFC 8126 <xref target="RFC
-ID attributes in the FloorQuery message. Floor Control Servers keep clients inf 8126" format="default" sectionFormat="of" derivedContent="6"/>, the registration
ormed by using FloorStatus messages.</t> policy for BFCP
<t>An individual FloorStatus message carries information about a single fl attributes is "Specification Required". For the purposes of this
oor. So, when a FloorQuery message requests information about more than one floo subregistry, the BFCP attributes for which IANA registration is
r, the floor control server needs to send separate FloorStatus messages for diff requested <bcp14>MUST</bcp14> be defined by a Standards Track
erent floors.</t> RFC. Such an RFC <bcp14>MUST</bcp14> specify the attribute's type,
<t>The information FloorQuery messages carry may depend on the user reques name, format, and semantics.</t>
ting the information. For example, a chair may be able to receive information ab <t indent="0" pn="section-15.1-2">For each BFCP attribute, the IANA regi
out pending requests, while a regular user may not be authorized to do so.</t> sters its type, its name, and
the reference to the RFC where the attribute is defined. The following
<section title="Generation of the First FloorStatus Message" anchor="sec:s table contains the initial values of this subregistry.</t>
erver:floorinfo:first"> <table anchor="tab_iana-attributes" align="center" pn="table-7">
<t>The successful processing of a FloorQuery message by a floor control <name slugifiedName="name-initial-values-of-the-bfcp-">Initial values
server involves generating one or several FloorStatus messages, the first of whi of the BFCP Attributes subregistry</name>
ch SHOULD be generated as soon as possible.</t> <thead>
<t>The floor control server MUST copy the Conference ID, the Transaction <tr>
ID, and the User ID from the FloorQuery message into the FloorStatus message, a <th align="center" colspan="1" rowspan="1">Type</th>
s described in <xref target="sec:transactions:server"/>.</t> <th align="left" colspan="1" rowspan="1">Attribute</th>
<t>If the FloorQuery message did not contain any FLOOR-ID attribute, the <th align="left" colspan="1" rowspan="1">Reference</th>
floor control server sends the FloorStatus message without adding any additiona </tr>
l attribute and does not send any subsequent FloorStatus message to the floor pa </thead>
rticipant.</t> <tbody>
<t>If the FloorQuery message contained one or more FLOOR-ID attributes, <tr>
the floor control server chooses one from among them and adds this FLOOR-ID attr <td align="center" colspan="1" rowspan="1">1</td>
ibute to the FloorStatus message. The floor control server SHOULD add a FLOOR-RE <td align="left" colspan="1" rowspan="1">BENEFICIARY-ID</td>
QUEST-INFORMATION grouped attribute for each floor request associated to the flo <td align="left" colspan="1" rowspan="1">RFC 8855</td>
or. Each FLOOR-REQUEST-INFORMATION grouped attribute contains a number of attrib </tr>
utes that provide information about the floor request. For each FLOOR-REQUEST-IN <tr>
FORMATION attribute, the floor control server follows the following steps.</t> <td align="center" colspan="1" rowspan="1">2</td>
<t>The floor control server MUST identify the floor request the FLOOR-RE <td align="left" colspan="1" rowspan="1">FLOOR-ID</td>
QUEST-INFORMATION attribute applies to by filling the Floor Request ID field of <td align="left" colspan="1" rowspan="1">RFC 8855</td>
the FLOOR-REQUEST-INFORMATION attribute.</t> </tr>
<t>The floor control server MUST add FLOOR-REQUEST-STATUS attributes to <tr>
the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being req <td align="center" colspan="1" rowspan="1">3</td>
uested (i.e., the floors associated with the floor request identified by the FLO <td align="left" colspan="1" rowspan="1">FLOOR-REQUEST-ID</td>
OR-REQUEST-ID attribute).</t> <td align="left" colspan="1" rowspan="1">RFC 8855</td>
<t>The floor control server SHOULD add a BENEFICIARY-ID attribute to the </tr>
FLOOR-REQUEST-INFORMATION grouped attribute identifying the beneficiary of the <tr>
floor request. Additionally, the floor control server MAY provide the display n <td align="center" colspan="1" rowspan="1">4</td>
ame and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t <td align="left" colspan="1" rowspan="1">PRIORITY</td>
> <td align="left" colspan="1" rowspan="1">RFC 8855</td>
<t>The floor control server MAY provide information about the requester </tr>
of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-IN <tr>
FORMATION grouped attribute.</t> <td align="center" colspan="1" rowspan="1">5</td>
<t>The floor control server MAY provide the reason why the floor partici <td align="left" colspan="1" rowspan="1">REQUEST-STATUS</td>
pant requested the floor in a PARTICIPANT-PROVIDED-INFO.</t> <td align="left" colspan="1" rowspan="1">RFC 8855</td>
<t>The floor control server MAY also add to the FLOOR-REQUEST-INFORMATIO </tr>
N grouped attribute a PRIORITY attribute with the Priority value requested for t <tr>
he floor request.</t> <td align="center" colspan="1" rowspan="1">6</td>
<t>The floor control server MUST add an OVERALL-REQUEST-STATUS attribute <td align="left" colspan="1" rowspan="1">ERROR-CODE</td>
to the FLOOR-REQUEST-INFORMATION grouped attribute with the current status of t <td align="left" colspan="1" rowspan="1">RFC 8855</td>
he floor request. The floor control server MAY add a STATUS-INFO attribute with </tr>
extra information about the floor request.</t> <tr>
<t>The floor control server MAY provide information about the status of <td align="center" colspan="1" rowspan="1">7</td>
the floor request as it relates to each of the floors being requested in the FLO <td align="left" colspan="1" rowspan="1">ERROR-INFO</td>
OR-REQUEST-STATUS attributes.</t> <td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">PARTICIPANT-PROVIDED-INFO
</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">STATUS-INFO</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">SUPPORTED-ATTRIBUTES</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">11</td>
<td align="left" colspan="1" rowspan="1">SUPPORTED-PRIMITIVES</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">12</td>
<td align="left" colspan="1" rowspan="1">USER-DISPLAY-NAME</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">USER-URI</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">BENEFICIARY-INFORMATION</
td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">FLOOR-REQUEST-INFORMATION
</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">16</td>
<td align="left" colspan="1" rowspan="1">REQUESTED-BY-INFORMATION<
/td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">17</td>
<td align="left" colspan="1" rowspan="1">FLOOR-REQUEST-STATUS</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">18</td>
<td align="left" colspan="1" rowspan="1">OVERALL-REQUEST-STATUS</t
d>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sec_iana_primitive" numbered="true" toc="include" removeI
<section title="Generation of Subsequent FloorStatus Messages" anchor="sec nRFC="false" pn="section-15.2">
:server:floorinfo:subsequent"> <name slugifiedName="name-primitives-subregistry">Primitives Subregistry
<t>If the FloorQuery message carried more than one FLOOR-ID attribute, t </name>
he floor control server SHOULD generate a FloorStatus message for each of them ( <t indent="0" pn="section-15.2-1">This section establishes the "Primitiv
except for the FLOOR-ID attribute chosen for the first FloorStatus message) as s es" subregistry under the
oon as possible. These FloorStatus messages are generated following the same rul BFCP Parameters registry. As per the terminology in RFC 8126 <xref target
es as those for the first FloorStatus message (see <xref target="sec:server:floo ="RFC8126" format="default" sectionFormat="of" derivedContent="6"/>, the registr
rinfo:first"/>), but their Transaction ID is 0 when using a reliable transport a ation policy for BFCP
nd non-zero and unique in the context of outstanding transactions when using an primitives is "Specification Required". For the purposes of this
unreliable transport (cf. <xref target="sec:transactions"/>).</t> subregistry, the BFCP primitives for which IANA registration is
<t>After generating these messages, the floor control server sends Floor requested <bcp14>MUST</bcp14> be defined by a Standards Track
Status messages, periodically keeping the client informed about all the floors f RFC. Such an RFC <bcp14>MUST</bcp14> specify the primitive's value,
or which the client requested information. The Transaction ID of these messages name, format, and semantics.</t>
MUST be 0 when using a reliable transport and non-zero and unique in the context <t indent="0" pn="section-15.2-2">For each BFCP primitive, the IANA regi
of outstanding transactions when using an unreliable transport (cf. <xref targe sters its value, its name, and the reference to the RFC where the primitive is d
t="sec:transactions"/>).</t> efined. The following table contains the initial values of this subregistry.</t>
<t><list style="hanging"> <table anchor="tab_iana-primitives" align="center" pn="table-8">
<t>The rate at which the floor control server sends FloorStatus mess <name slugifiedName="name-initial-values-of-the-bfcp-p">Initial values
ages is a matter of local policy. A floor control server may choose to send a ne of the BFCP Primitives subregistry</name>
w FloorStatus message every time a new floor request arrives, while another may <thead>
choose to only send a new FloorStatus message when a new floor request is Grante <tr>
d.</t> <th align="center" colspan="1" rowspan="1">Value</th>
</list></t> <th align="left" colspan="1" rowspan="1">Primitive</th>
<t>When communicating over an unreliable transport and a FloorStatusAck <th align="left" colspan="1" rowspan="1">Reference</th>
message is not received within the transaction failure window, the floor control </tr>
server MUST retransmit the FloorStatus message according to <xref target="udp_t </thead>
ransport"/>.</t> <tbody>
<tr>
<td align="center" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">FloorRequest</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">FloorRelease</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">FloorRequestQuery</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">FloorRequestStatus</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">UserQuery</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">UserStatus</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">FloorQuery</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">FloorStatus</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">ChairAction</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">ChairActionAck</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">11</td>
<td align="left" colspan="1" rowspan="1">Hello</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">12</td>
<td align="left" colspan="1" rowspan="1">HelloAck</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">Error</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">FloorRequestStatusAck</td
>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">15</td>
<td align="left" colspan="1" rowspan="1">FloorStatusAck</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">16</td>
<td align="left" colspan="1" rowspan="1">Goodbye</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">17</td>
<td align="left" colspan="1" rowspan="1">GoodbyeAck</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-15.
3">
<name slugifiedName="name-request-statuses-subregistr">Request Statuses
Subregistry</name>
<t indent="0" pn="section-15.3-1">This section establishes the "Request
Statuses" subregistry under the
BFCP Parameters registry. As per the terminology in RFC 8126 <xref target
="RFC8126" format="default" sectionFormat="of" derivedContent="6"/>, the registr
ation policy for BFCP
request statuses is "Specification Required". For the purposes of
this subregistry, the BFCP request statuses for which IANA registration
is requested <bcp14>MUST</bcp14> be defined by a Standards Track
RFC. Such an RFC <bcp14>MUST</bcp14> specify the value and the
semantics of the request status.</t>
<t indent="0" pn="section-15.3-2">For each BFCP request status, the IANA
registers its value, its meaning, and the reference to the RFC where the reques
t status is defined. The following table contains the initial values of this sub
registry.</t>
<table anchor="tab_iana-requeststatusvalues" align="center" pn="table-9"
>
<name slugifiedName="name-initial-values-of-the-reque">Initial values
of the Request Statuses subregistry</name>
<thead>
<tr>
<th align="center" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Status</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">Pending</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">Accepted</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">Granted</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">Denied</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">Cancelled</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">Released</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">Revoked</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sec_iana_errorcode" numbered="true" toc="include" removeI
nRFC="false" pn="section-15.4">
<name slugifiedName="name-error-codes-subregistry">Error Codes Subregist
ry</name>
<t indent="0" pn="section-15.4-1">This section establishes the "Error Co
des" subregistry under the BFCP
Parameters registry. As per the terminology in RFC 8126 <xref target="RFC
8126" format="default" sectionFormat="of" derivedContent="6"/>, the registration
policy for BFCP
error codes is "Specification Required". For the purposes of
this subregistry, the BFCP error codes for which IANA registration is
requested <bcp14>MUST</bcp14> be defined by a Standards Track
RFC. Such an RFC <bcp14>MUST</bcp14> specify the value and the
semantics of the error code, and any Error Specific Details that apply
to it.</t>
<t indent="0" pn="section-15.4-2">For each BFCP primitive, the IANA regi
sters its value, its meaning, and the reference to the RFC where the primitive i
s defined. The following table contains the initial values of this subregistry.<
/t>
<table anchor="tab_iana-errorcode" align="center" pn="table-10">
<name slugifiedName="name-initial-values-of-the-error">Initial values
of the Error Codes subregistry</name>
<thead>
<tr>
<th align="center" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Meaning</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">Conference Does Not Exist
</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">User Does Not Exist</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">Unknown Primitive</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">4</td>
<td align="left" colspan="1" rowspan="1">Unknown Mandatory Attribu
te</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">5</td>
<td align="left" colspan="1" rowspan="1">Unauthorized Operation</t
d>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">6</td>
<td align="left" colspan="1" rowspan="1">Invalid Floor ID</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">7</td>
<td align="left" colspan="1" rowspan="1">Floor Request ID Does Not
Exist</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">8</td>
<td align="left" colspan="1" rowspan="1">You have Already Reached
the Maximum Number
of Ongoing Floor Requests for This Floor</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">9</td>
<td align="left" colspan="1" rowspan="1">Use TLS</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">10</td>
<td align="left" colspan="1" rowspan="1">Unable to Parse Message</
td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">11</td>
<td align="left" colspan="1" rowspan="1">Use DTLS</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">12</td>
<td align="left" colspan="1" rowspan="1">Unsupported Version</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">13</td>
<td align="left" colspan="1" rowspan="1">Incorrect Message Length<
/td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
<tr>
<td align="center" colspan="1" rowspan="1">14</td>
<td align="left" colspan="1" rowspan="1">Generic Error</td>
<td align="left" colspan="1" rowspan="1">RFC 8855</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="sec_changes" numbered="true" toc="include" removeInRFC="fal
<section title="Reception of a ChairAction Message" anchor="sec:server:chair se" pn="section-16">
action"> <name slugifiedName="name-changes-from-rfc-4582">Changes from RFC 4582</na
<t>On reception of a ChairAction message, the floor control server follows me>
the rules in <xref target="sec:auth"/> that relate to client authentication and <t indent="0" pn="section-16-1">The following is the list of technical cha
authorization. If while processing the ChairAction message, the floor control s nges and other non-trivial fixes from <xref target="RFC4582" format="default" se
erver encounters an error, it MUST generate an Error response following the proc ctionFormat="of" derivedContent="3"/>.</t>
edures described in <xref target="sec:server:error"/>.</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-16.
<t>The successful processing of a ChairAction message by a floor control s 1">
erver involves generating a ChairActionAck message, which SHOULD be generated as <name slugifiedName="name-extensions-for-an-unreliabl">Extensions for an
soon as possible.</t> Unreliable Transport</name>
<t>When communicating over an unreliable transport and upon receiving a Ch <t indent="0" pn="section-16.1-1">The main purpose of this work was to r
airAction from a chair, the floor control server MUST respond with a ChairAction evise the specification to support BFCP over an unreliable transport, resulting
Ack message within the transaction failure window to complete the transaction.</ in the following changes:</t>
t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-16
<t>The floor control server MUST copy the Conference ID, the Transaction I .1-2">
D, and the User ID from the ChairAction message into the ChairActionAck message, <li pn="section-16.1-2.1" derivedCounter="1.">
as described in <xref target="sec:transactions:server"/>.</t> <t indent="0" pn="section-16.1-2.1.1">Overview of Operation (<xref t
<t>The floor control server needs to take into consideration the operation arget="sec_overview" format="default" sectionFormat="of" derivedContent="Section
requested in the ChairAction message (e.g., granting a floor) but does not nece 4"/>):</t>
ssarily need to perform it as requested by the floor chair. The operation that t <t indent="0" pn="section-16.1-2.1.2">
he floor control server performs depends on the ChairAction message and on the i Changed the description of client-initiated and server-initiated tra
nternal state of the floor control server.</t> nsactions, referring to <xref target="sec_transactions" format="default" section
<t>For example, a floor chair may send a ChairAction message granting a fl Format="of" derivedContent="Section 8"/>.</t>
oor that was requested as part of an atomic floor request operation that involve </li>
d several floors. Even if the chair responsible for one of the floors instructs <li pn="section-16.1-2.2" derivedCounter="2.">
the floor control server to grant the floor, the floor control server will not g <t indent="0" pn="section-16.1-2.2.1">COMMON-HEADER Format (<xref ta
rant it until the chairs responsible for the other floors agree to grant them as rget="sec_format_common" format="default" sectionFormat="of" derivedContent="Sec
well.</t> tion 5.1"/>):</t>
<t>So, the floor control server is ultimately responsible for keeping a co <t indent="0" pn="section-16.1-2.2.2">
herent floor state using instructions from floor chairs as input to this state.< Ver(sion) field, where the value 2 is used for the extensions for an
/t> unreliable transport. Added new R and F flag bits for an unreliable transport.
<t>If the new Status in the ChairAction message is Accepted and all the bi Res(erved) field is now 3 bit. New optional Fragment Offset and Fragment Length
ts of the Queue Position field are zero, the floor chair is requesting that the fields.</t>
floor control server assign a queue position (e.g., the last in the queue) to th </li>
e floor request based on the local policy of the floor control server. (Of cours <li pn="section-16.1-2.3" derivedCounter="3.">
e, such a request only applies if the floor control server implements a queue.)< <t indent="0" pn="section-16.1-2.3.1">New primitives (<xref target="
/t> sec_format_common" format="default" sectionFormat="of" derivedContent="Section 5
</section> .1"/>):</t>
<t indent="0" pn="section-16.1-2.3.2">
<section title="Reception of a Hello Message" anchor="sec:server:helloack">
<t>On reception of a Hello message, the floor control server follows the r
ules in <xref target="sec:auth"/> that relate to client authentication. If while
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">
<t>Error messages are always sent in response to a previous message from t
he client as part of a client-initiated transaction. The ABNF in <xref target="s
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">
<t>BFCP uses TLS/DTLS to provide mutual authentication between clients and s
ervers. TLS/DTLS also provides replay and integrity protection and confidentiali
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">
<t><list style="empty">
<t>[Note to IANA: Much of this text exists from the previous version of
this document. While the old and new additions to the registries are presented
here, the items for which IANA needs to take action with respect to this draft a
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">
<t>This section establishes the Attribute subregistry under the BFCP Param
eters registry. As per the terminology in RFC 5226 <xref target="RFC5226"/>, the
registration policy for BFCP attributes shall be "Specification Required". For
the purposes of this subregistry, the BFCP attributes for which IANA registratio
n is requested MUST be defined by a standards-track RFC. Such an RFC MUST specif
y the attribute's type, name, format, and semantics.</t>
<t>For each BFCP attribute, the IANA registers its type, its name, and the
reference to the RFC where the attribute is defined. The following table contai
ns the initial values of this subregistry.</t>
<texttable title="Initial values of the BFCP Attribute subregistry"
anchor="tab:iana-attributes">
<ttcol align="center">Type</ttcol>
<ttcol>Attribute</ttcol>
<ttcol>Reference</ttcol>
<c>1</c> <c>BENEFICIARY-ID</c> <c>[RFC XXXX]</c>
<c>2</c> <c>FLOOR-ID</c> <c>[RFC XXXX]</c>
<c>3</c> <c>FLOOR-REQUEST-ID</c> <c>[RFC XXXX]</c>
<c>4</c> <c>PRIORITY</c> <c>[RFC XXXX]</c>
<c>5</c> <c>REQUEST-STATUS</c> <c>[RFC XXXX]</c>
<c>6</c> <c>ERROR-CODE</c> <c>[RFC XXXX]</c>
<c>7</c> <c>ERROR-INFO</c> <c>[RFC XXXX]</c>
<c>8</c> <c>PARTICIPANT-PROVIDED-INFO</c> <c>[RFC XXXX]</c>
<c>9</c> <c>STATUS-INFO</c> <c>[RFC XXXX]</c>
<c>10</c> <c>SUPPORTED-ATTRIBUTES</c> <c>[RFC XXXX]</c>
<c>11</c> <c>SUPPORTED-PRIMITIVES</c> <c>[RFC XXXX]</c>
<c>12</c> <c>USER-DISPLAY-NAME</c> <c>[RFC XXXX]</c>
<c>13</c> <c>USER-URI</c> <c>[RFC XXXX]</c>
<c>14</c> <c>BENEFICIARY-INFORMATION</c> <c>[RFC XXXX]</c>
<c>15</c> <c>FLOOR-REQUEST-INFORMATION</c> <c>[RFC XXXX]</c>
<c>16</c> <c>REQUESTED-BY-INFORMATION</c> <c>[RFC XXXX]</c>
<c>17</c> <c>FLOOR-REQUEST-STATUS</c> <c>[RFC XXXX]</c>
<c>18</c> <c>OVERALL-REQUEST-STATUS</c> <c>[RFC XXXX]</c>
</texttable>
</section>
<section title="Primitive Subregistry" anchor="sec:iana:primitive">
<t><list style="empty">
<t>[Note to IANA: This section instructs the IANA to register the foll
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">
<t>This section establishes the Request Status subregistry under the BFCP
Parameters registry. As per the terminology in RFC 5226 <xref target="RFC5226"/>
, the registration policy for BFCP request status shall be "Specification Requir
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">
<t><list style="empty">
<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">
<t>Following is the list of technical changes and other non-trivial fixes fr
om <xref target="RFC4582"/>.</t>
<section title="Extensions for an unreliable transport">
<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> Added four new primitives: FloorRequestStatusAck, FloorStatusAck, Go odbye, and GoodbyeAck.</t>
<t>New error codes (<xref target="sec:format:attributes:error-code"/>) </li>
:<vspace/> <li pn="section-16.1-2.4" derivedCounter="4.">
Added three new error codes: "Unable to Parse Message", "Use DTLS" a <t indent="0" pn="section-16.1-2.4.1">New error codes (<xref target=
nd "Unsupported Version". Note that two additional error codes were added, see < "sec_format_attributes_error-code" format="default" sectionFormat="of" derivedCo
xref target="sec:changes:other"/>.</t> ntent="Section 5.2.6"/>):</t>
<t>ABNF for new primitives (<xref target="sec:msg_format"/>):<vspace/> <t indent="0" pn="section-16.1-2.4.2">
New subsections with normative ABNF for the new primitives.</t> Added three new error codes: "Unable to Parse Message", "Use DTLS" a
<t>Transport split in two (<xref target="sec:transport"/>):<vspace/> nd "Unsupported Version". Note that two additional error codes were added, see <
<xref target="sec:transport"/> specifying the transport was split in xref target="sec_changes_other" format="default" sectionFormat="of" derivedConte
two subsections; <xref target="tcp_transport"/> for a reliable transport and <x nt="Section 16.2"/>.</t>
ref target="udp_transport"/> for an unreliable transport. Where the specificatio </li>
n for an unreliable transport amongst other issues deals with reliability, conge <li pn="section-16.1-2.5" derivedCounter="5.">
stion control, fragmentation and ICMP.</t> <t indent="0" pn="section-16.1-2.5.1">ABNF for new primitives (<xref
<t>Mandate DTLS (<xref target="sec:lower-security"/> and <xref target= target="sec_msg_format" format="default" sectionFormat="of" derivedContent="Sec
"sec:auth"/>):<vspace/> tion 5.3"/>):</t>
Mandate DTLS support when transport over UDP is used.</t> <t indent="0" pn="section-16.1-2.5.2">
<t>Transaction changes (<xref target="sec:transactions"/>):<vspace/> Added new subsections with normative ABNF for the new primitives.</t
Server-initiated transactions over an unreliable transport has non-z >
ero and unique Transaction ID. Over an unreliable transport, the retransmit time </li>
rs T1 and T2 described in <xref target="timers"/> apply.</t> <li pn="section-16.1-2.6" derivedCounter="6.">
<t>Requiring timely response (<xref target="timers"/>, <xref target="s <t indent="0" pn="section-16.1-2.6.1">Transport split in two (<xref
ec:client:request:response"/>, <xref target="sec:participant:cancel:response"/>, target="sec_transport" format="default" sectionFormat="of" derivedContent="Secti
<xref target="sec:chair:instruct:response"/>, <xref target="sec:client:floorinf on 6"/>):</t>
o:response"/>, <xref target="sec:client:info:response"/>, <xref target="sec:clie <t indent="0" pn="section-16.1-2.6.2"><xref target="sec_transport" f
nt:user:response"/>, <xref target="sec:client:hello:responses"/>, <xref target=" ormat="default" sectionFormat="of" derivedContent="Section 6"/> specifying the t
sec:recept:frsm"/> and <xref target="sec:recept:fsm"/>):<vspace/> ransport was split in two subsections; <xref target="tcp_transport" format="defa
Describing that a given response must be sent within the transaction ult" sectionFormat="of" derivedContent="Section 6.1"/> for a reliable transport
failure window to complete the transaction.</t> and <xref target="udp_transport" format="default" sectionFormat="of" derivedCont
<t>Updated IANA Considerations (<xref target="sec:iana"/>):<vspace/> ent="Section 6.2"/> for an unreliable transport. The specification for an unreli
Added the new primitives and error codes to <xref target="sec:iana:p able transport, among other issues, deals with reliability, congestion control,
rimitive"/> and <xref target="sec:iana:errorcode"/> respectively.</t> fragmentation and ICMP.</t>
<t>Examples over an unreliable transport (<xref target="app:unrelcallf </li>
low"/>):<vspace/> <li pn="section-16.1-2.7" derivedCounter="7.">
Added sample interactions over an unreliable transport for the scena <t indent="0" pn="section-16.1-2.7.1">Mandated DTLS (<xref target="s
rios in <xref target="fig:flow1"/> and <xref target="fig:flow2"/> </t> ec_lower-security" format="default" sectionFormat="of" derivedContent="Section 7
<t>Motivation for an unreliable transport (<xref target="app:motivatio "/> and <xref target="sec_auth" format="default" sectionFormat="of" derivedConte
n"/>):<vspace/> nt="Section 9"/>):</t>
Introduction to and motivation for extending BFCP to support an unre <t indent="0" pn="section-16.1-2.7.2">
liable transport.</t> Mandated DTLS support when transport over UDP is used.</t>
</list></t> </li>
</section> <li pn="section-16.1-2.8" derivedCounter="8.">
<section title="Other changes" anchor="sec:changes:other"> <t indent="0" pn="section-16.1-2.8.1">Transaction changes (<xref tar
<t>Clarifications and bug fixes:</t> get="sec_transactions" format="default" sectionFormat="of" derivedContent="Secti
<t><list style="numbers"> on 8"/>):</t>
<t>ABNF fixes (<xref target="fig:ben-information"/>, <xref target="fig <t indent="0" pn="section-16.1-2.8.2">
:floor-request-information"/>, ="fig:reqby-information"/>, <xref target="fig:flo Server-initiated transactions over an unreliable transport have non-
or-req-status"/>, <xref target="fig:overall-req-status"/>, and the ABNF figures zero and unique Transaction IDs. Over an unreliable transport, the retransmit ti
in <xref target="sec:msg_format"/>):<vspace/> mers T1 and T2 described in <xref target="timers" format="default" sectionFormat
Although formally correct in <xref target="RFC4582"/>, the notation h ="of" derivedContent="Section 8.3"/> apply.</t>
as changed in a number of Figures to an equivalent form for clarity, e.g., s/*1( </li>
FLOOR-ID)/[FLOOR-ID]/ in <xref target="fig:floorstatus"/> and s/*[XXX]/*(XXX)/ i <li pn="section-16.1-2.9" derivedCounter="9.">
n the other figures.</t> <t indent="0" pn="section-16.1-2.9.1">Timely response required (<xre
<t>Typo (<xref target="sec:client:hello:responses"/>):<vspace/> f target="timers" format="default" sectionFormat="of" derivedContent="Section 8.
Change from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the second 3"/>, <xref target="sec_client_request_response" format="default" sectionFormat=
paragraph.</t> "of" derivedContent="Section 10.1.2"/>, <xref target="sec_participant_cancel_res
<t>Corrected attribute type (<xref target="sec:server:request:first"/>): ponse" format="default" sectionFormat="of" derivedContent="Section 10.2.2"/>, <x
<vspace/> ref target="sec_chair_instruct_response" format="default" sectionFormat="of" der
Change from PARTICIPANT-PROVIDED-INFO to PRIORITY attributed in the ei ivedContent="Section 11.2"/>, <xref target="sec_client_floorinfo_response" forma
ghth paragraph, since the note below describes priority and that the last paragr t="default" sectionFormat="of" derivedContent="Section 12.1.2"/>, <xref target="
aph deals with PARTICIPANT-PROVIDED-INFO.</t> sec_client_info_response" format="default" sectionFormat="of" derivedContent="Se
<t>New error codes (<xref target="sec:format:attributes:error-code"/>):< ction 12.2.2"/>, <xref target="sec_client_user_response" format="default" sectio
vspace/> nFormat="of" derivedContent="Section 12.3.2"/>, <xref target="sec_client_hello_r
esponses" format="default" sectionFormat="of" derivedContent="Section 12.4.2"/>,
<xref target="sec_recept_frsm" format="default" sectionFormat="of" derivedConte
nt="Section 10.1.3"/> and <xref target="sec_recept_fsm" format="default" section
Format="of" derivedContent="Section 12.1.3"/>):</t>
<t indent="0" pn="section-16.1-2.9.2">
Described that a given response must be sent within the transaction
failure window to complete the transaction.</t>
</li>
<li pn="section-16.1-2.10" derivedCounter="10.">
<t indent="0" pn="section-16.1-2.10.1">Updated IANA Considerations (
<xref target="sec_iana" format="default" sectionFormat="of" derivedContent="Sect
ion 15"/>):</t>
<t indent="0" pn="section-16.1-2.10.2">
Added the new primitives and error codes to <xref target="sec_iana_p
rimitive" format="default" sectionFormat="of" derivedContent="Section 15.2"/> an
d <xref target="sec_iana_errorcode" format="default" sectionFormat="of" derivedC
ontent="Section 15.4"/> respectively.</t>
</li>
<li pn="section-16.1-2.11" derivedCounter="11.">
<t indent="0" pn="section-16.1-2.11.1">Examples over an unreliable t
ransport (<xref target="app_unrelcallflow" format="default" sectionFormat="of" d
erivedContent="Appendix A"/>):</t>
<t indent="0" pn="section-16.1-2.11.2">
Added sample interactions over an unreliable transport for the scena
rios in <xref target="fig_flow1" format="default" sectionFormat="of" derivedCont
ent="Figure 2"/> and <xref target="fig_flow2" format="default" sectionFormat="of
" derivedContent="Figure 3"/> </t>
</li>
<li pn="section-16.1-2.12" derivedCounter="12.">
<t indent="0" pn="section-16.1-2.12.1">Motivation for an unreliable
transport (<xref target="app_motivation" format="default" sectionFormat="of" der
ivedContent="Appendix B"/>):</t>
<t indent="0" pn="section-16.1-2.12.2">
Added introduction to and motivation for extending BFCP to support a
n unreliable transport.</t>
</li>
</ol>
</section>
<section anchor="sec_changes_other" numbered="true" toc="include" removeIn
RFC="false" pn="section-16.2">
<name slugifiedName="name-other-changes">Other Changes</name>
<t indent="0" pn="section-16.2-1">Clarifications and bug fixes:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-16
.2-2">
<li pn="section-16.2-2.1" derivedCounter="1.">
<t indent="0" pn="section-16.2-2.1.1">ABNF fixes (<xref target="fig_
ben-information" format="default" sectionFormat="of" derivedContent="Figure 22"/
>, <xref target="fig_floor-request-information" format="default" sectionFormat="
of" derivedContent="Figure 24"/>, <xref target="fig_reqby-information" format="d
efault" sectionFormat="of" derivedContent="Figure 26"/>, <xref target="fig_floor
-req-status" format="default" sectionFormat="of" derivedContent="Figure 28"/>, <
xref target="fig_overall-req-status" format="default" sectionFormat="of" derived
Content="Figure 30"/>, and the ABNF figures in <xref target="sec_msg_format" for
mat="default" sectionFormat="of" derivedContent="Section 5.3"/>):</t>
<t indent="0" pn="section-16.2-2.1.2">
Although formally correct in <xref target="RFC4582" format="default"
sectionFormat="of" derivedContent="3"/>, the notation has changed in a number of
figures to an equivalent form for clarity, e.g., <tt>s/*1(FLOOR-ID)/[FLOOR-ID]/
</tt> in <xref target="fig_floorstatus" format="default" sectionFormat="of" deri
vedContent="Figure 38"/> and <tt>s/*[XXX]/*(XXX)/</tt> in the other figures.</t>
</li>
<li pn="section-16.2-2.2" derivedCounter="2.">
<t indent="0" pn="section-16.2-2.2.1">Typo (<xref target="sec_client
_hello_responses" format="default" sectionFormat="of" derivedContent="Section 12
.4.2"/>):</t>
<t indent="0" pn="section-16.2-2.2.2">
Changed from SUPPORTED-PRIMITVIES to SUPPORTED-PRIMITIVES in the secon
d paragraph.</t>
</li>
<li pn="section-16.2-2.3" derivedCounter="3.">
<t indent="0" pn="section-16.2-2.3.1">Corrected attribute type (<xre
f target="sec_server_request_first" format="default" sectionFormat="of" derivedC
ontent="Section 13.1.1"/>):</t>
<t indent="0" pn="section-16.2-2.3.2">
Changed from PARTICIPANT-PROVIDED-INFO to PRIORITY attribute in the ei
ghth paragraph, since the note below describes priority and that the last paragr
aph deals with PARTICIPANT-PROVIDED-INFO.</t>
</li>
<li pn="section-16.2-2.4" derivedCounter="4.">
<t indent="0" pn="section-16.2-2.4.1">New error codes (<xref target=
"sec_format_attributes_error-code" format="default" sectionFormat="of" derivedCo
ntent="Section 5.2.6"/>):</t>
<t indent="0" pn="section-16.2-2.4.2">
Added two additional error codes: "Incorrect Message Length" and "Gene ric Error".</t> Added two additional error codes: "Incorrect Message Length" and "Gene ric Error".</t>
<t>Assorted clarifications (Across the document):<vspace/> </li>
Language clarifications as a result of reviews. Also, the normative la <li pn="section-16.2-2.5" derivedCounter="5.">
nguage where tightened where appropriate, i.e. changed from SHOULD strength to M <t indent="0" pn="section-16.2-2.5.1">New cipher suites (<xref targe
UST in a number of places.</t> t="sec_lower-security" format="default" sectionFormat="of" derivedContent="Secti
</list></t> on 7"/>)</t>
<t indent="0" pn="section-16.2-2.5.2">Additional cipher suites are n
ow specified which should be supported.</t>
</li>
<li pn="section-16.2-2.6" derivedCounter="6.">
<t indent="0" pn="section-16.2-2.6.1">Assorted clarifications (Acros
s the document):</t>
<t indent="0" pn="section-16.2-2.6.2">
Language clarifications as a result of reviews. Also, the normative la
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> </middle>
<back>
<section title="Acknowledgements" anchor="sec:acks"> <references pn="section-17">
<t>The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideas f <name slugifiedName="name-references">References</name>
or RFC 4582 <xref target="RFC4582"/>. Additionally, Xiaotao Wu, Paul Kyzivat, Jo <references pn="section-17.1">
nathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morga <name slugifiedName="name-normative-references">Normative References</na
n, and Oscar Novo provided useful comments during the work with RFC 4582. The au me>
thors also acknowledge contributions to the revision of BFCP for use over an unr <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
eliable transport from Geir Arne Sandbakken who had the initial idea, Alfred E. 119" quoteTitle="true" derivedAnchor="1">
Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Joe <front>
rg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Cullen Jennings <title>Key words for use in RFCs to Indicate Requirement Levels</tit
, David Benham, Nivedita Melinkeri, Woo Johnman, Vijaya Mandava and Alan Ford. I le>
n the final phase Ernst Horvath did a thorough review revealing issues that need <author initials="S." surname="Bradner" fullname="S. Bradner">
ed clarification and changes. Useful and important final reviews were done by Ma <organization showOnFrontPage="true"/>
ry Barnes. Paul Jones helped tremendously as editor for changes addressing IESG </author>
review comments.</t> <date year="1997" month="March"/>
</section> <abstract>
</middle> <t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
<back> pitalized. This document defines these words as they should be interpreted in IE
<references title="Normative References"> TF documents. This document specifies an Internet Best Current Practices for th
<?rfc include="reference.RFC.2119" ?> e Internet Community, and requests discussion and suggestions for improvements.<
<?rfc include="reference.RFC.2988" ?> /t>
<?rfc include="reference.RFC.4582" ?> </abstract>
<?rfc include="reference.RFC.5018" ?> </front>
<?rfc include="reference.RFC.5234" ?> <seriesInfo name="BCP" value="14"/>
<?rfc include="reference.RFC.5226" ?> <seriesInfo name="RFC" value="2119"/>
<?rfc include="reference.RFC.5246" ?> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<?rfc include="reference.RFC.6347" ?> </reference>
<?rfc include="reference.RFC.3629" ?> <reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6
<?rfc include="reference.I-D.draft-ietf-bfcpbis-rfc4583bis-12" ?> <!-- T 298" quoteTitle="true" derivedAnchor="2">
BD increase version! --> <front>
<?rfc include="reference.RFC.4961" ?> <title>Computing TCP's Retransmission Timer</title>
<?rfc include="reference.RFC.5389" ?> <author initials="V." surname="Paxson" fullname="V. Paxson">
<?rfc include="reference.RFC.5405" ?> <organization showOnFrontPage="true"/>
</references> </author>
<author initials="M." surname="Allman" fullname="M. Allman">
<references title="Informational References"> <organization showOnFrontPage="true"/>
<?rfc include="reference.RFC.3264" ?> </author>
<?rfc include="reference.RFC.4376" ?> <author initials="J." surname="Chu" fullname="J. Chu">
<?rfc include="reference.RFC.5239" ?> <organization showOnFrontPage="true"/>
<?rfc include="reference.RFC.5245" ?> </author>
<?rfc include="reference.RFC.3261" ?> <author initials="M." surname="Sargent" fullname="M. Sargent">
<?rfc include="reference.RFC.4301" ?> <organization showOnFrontPage="true"/>
<?rfc include="reference.RFC.6501" ?> </author>
<?rfc include="reference.RFC.6503" ?> <date year="2011" month="June"/>
<?rfc include="reference.RFC.6504" ?> <abstract>
<?rfc include="reference.RFC.1191" ?> <t indent="0">This document defines the standard algorithm that Tr
<?rfc include="reference.RFC.1981" ?> ansmission Control Protocol (TCP) senders are required to use to compute and man
<?rfc include="reference.RFC.4821" ?> age their retransmission timer. It expands on the discussion in Section 4.2.3.1
<?rfc include="reference.RFC.5763" ?> of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHO
<?rfc include="reference.RFC.6951" ?> ULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]</t>
<?rfc include="reference.RFC.7525" ?> </abstract>
</front>
<!-- Add reference to IMTC role-based video BCP, at some stage. <seriesInfo name="RFC" value="6298"/>
Refer to it in an informational note somehow. --> <seriesInfo name="DOI" value="10.17487/RFC6298"/>
</reference>
<!-- Motivation appendix references below --> <reference anchor="RFC4582" target="https://www.rfc-editor.org/info/rfc4
<?rfc include="reference.RFC.4380" ?> 582" quoteTitle="true" derivedAnchor="3">
<?rfc include="reference.RFC.6081" ?> <front>
<?rfc include="reference.RFC.4960" ?> <title>The Binary Floor Control Protocol (BFCP)</title>
<?rfc include="reference.RFC.6544" ?> <author initials="G." surname="Camarillo" fullname="G. Camarillo">
<?rfc include="reference.I-D.draft-manner-tsvwg-gut-02" ?> <organization showOnFrontPage="true"/>
<?rfc include="reference.I-D.draft-ietf-mmusic-media-path-middleboxes-07" ?> </author>
<reference anchor="IMC05" target="http://saikat.guha.cc/pub/imc05-tcpnat.pdf <author initials="J." surname="Ott" fullname="J. Ott">
/"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Characterization and Measurement of TCP Traversal through NATs an <author initials="K." surname="Drage" fullname="K. Drage">
d Firewalls</title> <organization showOnFrontPage="true"/>
<author initials="S" surname="Guha"/> </author>
<author initials="P" surname="Francis"/> <date year="2006" month="November"/>
<date month="" year="2005"/> <abstract>
</front> <t indent="0">Floor control is a means to manage joint or exclusiv
</reference> e access to shared resources in a (multiparty) conferencing environment. Thereby
<reference anchor="P2PNAT" target="http://www.brynosaurus.com/pub/net/p2pnat , floor control complements other functions -- such as conference and media sess
.pdf/"> ion setup, conference policy manipulation, and media control -- that are realize
<front> d by other protocols.</t>
<title>Peer-to-Peer Communication Across Network Address Translators</ti <t indent="0">This document specifies the Binary Floor Control Pro
tle> tocol (BFCP). BFCP is used between floor participants and floor control servers,
<author initials="B" surname="Ford"/> and between floor chairs (i.e., moderators) and floor control servers. [STANDA
<author initials="P" surname="Srisuresh"/> RDS-TRACK]</t>
<author initials="D" surname="Kegel"/> </abstract>
<date month="April" year="2005"/> </front>
</front> <seriesInfo name="RFC" value="4582"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC4582"/>
</references> </reference>
<reference anchor="RFC5018" target="https://www.rfc-editor.org/info/rfc5
<!-- Appendices --> 018" quoteTitle="true" derivedAnchor="4">
<section title="Example Call Flows for BFCP over an Unreliable Transport" anch <front>
or="app:unrelcallflow"> <title>Connection Establishment in the Binary Floor Control Protocol
<t>With reference to <xref target="sec:overview:user"/>, the following figur (BFCP)</title>
es show representative call-flows for requesting and releasing a floor, and obta <author initials="G." surname="Camarillo" fullname="G. Camarillo">
ining status information about a floor when BFCP is deployed over an unreliable <organization showOnFrontPage="true"/>
transport. The figures here show a loss-less interaction.</t> </author>
<t><figure align="left" anchor="ReqRelUnrelExample" title="Requesting and re <date year="2007" month="September"/>
leasing a floor"> <abstract>
<artwork align="left"><![CDATA[ <t indent="0">This document specifies how a Binary Floor Control P
rotocol (BFCP) client establishes a connection to a BFCP floor control server ou
tside the context of an offer/answer exchange. Client and server authentication
are based on Transport Layer Security (TLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5018"/>
<seriesInfo name="DOI" value="10.17487/RFC5018"/>
</reference>
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5
234" quoteTitle="true" derivedAnchor="5">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="D. Crocker" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Overell" fullname="P. Overell">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="January"/>
<abstract>
<t indent="0">Internet technical specifications often need to defi
ne a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF
), called Augmented BNF (ABNF), has been popular among many Internet specificati
ons. The current specification documents ABNF. It balances compactness and simp
licity with reasonable representational power. The differences between standard
BNF and ABNF involve naming rules, repetition, alternatives, order-independence
, and value ranges. This specification also supplies additional rule definition
s and encoding for a core lexical analyzer of the type common to several Interne
t specifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="6">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="June"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility t
hat use constants to identify various protocol parameters. To ensure that the v
alues in these fields do not have conflicting uses and to promote interoperabili
ty, their allocations are often coordinated by a central record keeper. For IET
F protocols, that role is filled by the Internet Assigned Numbers Authority (IAN
A).</t>
<t indent="0">To make assignments in a given registry prudently, g
uidance describing the conditions under which new values should be assigned, as
well as when and how modifications to existing values can be made, is needed. T
his document defines a framework for the documentation of these guidelines by sp
ecification authors, in order to assure that the provided guidance for the IANA
Considerations is clear and addresses the various issues that are likely in the
operation of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5
246" quoteTitle="true" derivedAnchor="7">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e>
<author initials="T." surname="Dierks" fullname="T. Dierks">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="August"/>
<abstract>
<t indent="0">This document specifies Version 1.2 of the Transport
Layer Security (TLS) protocol. The TLS protocol provides communications securi
ty over the Internet. The protocol allows client/server applications to communi
cate in a way that is designed to prevent eavesdropping, tampering, or message f
orgery. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
</reference>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6
347" quoteTitle="true" derivedAnchor="8">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="January"/>
<abstract>
<t indent="0">This document specifies version 1.2 of the Datagram
Transport Layer Security (DTLS) protocol. The DTLS protocol provides communicat
ions privacy for datagram protocols. The protocol allows client/server applicat
ions to communicate in a way that is designed to prevent eavesdropping, tamperin
g, or message forgery. The DTLS protocol is based on the Transport Layer Securi
ty (TLS) protocol and provides equivalent security guarantees. Datagram semanti
cs of the underlying transport are preserved by the DTLS protocol. This documen
t updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
<reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3
629" quoteTitle="true" derivedAnchor="9">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials="F." surname="Yergeau" fullname="F. Yergeau">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="November"/>
<abstract>
<t indent="0">ISO/IEC 10646-1 defines a large character set called
the Universal Character Set (UCS) which encompasses most of the world's writing
systems. The originally proposed encodings of the UCS, however, were not compa
tible with many current applications and protocols, and this has led to the deve
lopment of UTF-8, the object of this memo. UTF-8 has the characteristic of pres
erving the full US-ASCII range, providing compatibility with file systems, parse
rs and other software that rely on US-ASCII values but are transparent to other
values. This memo obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="10">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" quoteTitle="true" derivedAnchor="11">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="August"/>
<abstract>
<t indent="0">This document specifies version 1.3 of the Transport
Layer Security (TLS) protocol. TLS allows client/server applications to commun
icate over the Internet in a way that is designed to prevent eavesdropping, tamp
ering, and message forgery.</t>
<t indent="0">This document updates RFCs 5705 and 6066, and obsole
tes RFCs 5077, 5246, and 6961. This document also specifies new requirements fo
r TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8856" target="https://www.rfc-editor.org/info/rfc8
856" quoteTitle="true" derivedAnchor="12">
<front>
<title>Session Description Protocol (SDP) Format for Binary Floor Co
ntrol Protocol (BFCP) Streams</title>
<author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo
">
<organization showOnFrontPage="true"/>
</author>
<author initials="T" surname="Kristensen" fullname="Tom Kristensen">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Holmberg" fullname="Christer Holmberg
">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8856"/>
<seriesInfo name="DOI" value="10.17487/RFC8856"/>
</reference>
<reference anchor="RFC4961" target="https://www.rfc-editor.org/info/rfc4
961" quoteTitle="true" derivedAnchor="13">
<front>
<title>Symmetric RTP / RTP Control Protocol (RTCP)</title>
<author initials="D." surname="Wing" fullname="D. Wing">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="July"/>
<abstract>
<t indent="0">This document recommends using one UDP port pair for
both communication directions of bidirectional RTP and RTP Control Protocol (RT
CP) sessions, commonly called "symmetric RTP" and "symmetric RTCP". This docume
nt specifies an Internet Best Current Practices for the Internet Community, and
requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="131"/>
<seriesInfo name="RFC" value="4961"/>
<seriesInfo name="DOI" value="10.17487/RFC4961"/>
</reference>
<reference anchor="RFC5389" target="https://www.rfc-editor.org/info/rfc5
389" quoteTitle="true" derivedAnchor="14">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Mahy" fullname="R. Mahy">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Matthews" fullname="P. Matthews">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Wing" fullname="D. Wing">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="October"/>
<abstract>
<t indent="0">Session Traversal Utilities for NAT (STUN) is a prot
ocol that serves as a tool for other protocols in dealing with Network Address T
ranslator (NAT) traversal. It can be used by an endpoint to determine the IP ad
dress and port allocated to it by a NAT. It can also be used to check connectiv
ity between two endpoints, and as a keep-alive protocol to maintain NAT bindings
. STUN works with many existing NATs, and does not require any special behavior
from them.</t>
<t indent="0">STUN is not a NAT traversal solution by itself. Rat
her, it is a tool to be used in the context of a NAT traversal solution. This i
s an important change from the previous version of this specification (RFC 3489)
, which presented STUN as a complete solution.</t>
<t indent="0">This document obsoletes RFC 3489. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5389"/>
<seriesInfo name="DOI" value="10.17487/RFC5389"/>
</reference>
<reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
085" quoteTitle="true" derivedAnchor="15">
<front>
<title>UDP Usage Guidelines</title>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Shepherd" fullname="G. Shepherd">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="March"/>
<abstract>
<t indent="0">The User Datagram Protocol (UDP) provides a minimal
message-passing transport that has no inherent congestion control mechanisms. T
his document provides guidelines on the use of UDP for the designers of applicat
ions, tunnels, and other protocols that use UDP. Congestion control guidelines
are a primary focus, but the document also provides guidance on other topics, in
cluding message sizes, reliability, checksums, middlebox traversal, the use of E
xplicit Congestion Notification (ECN), Differentiated Services Code Points (DSCP
s), and ports.</t>
<t indent="0">Because congestion control is critical to the stable
operation of the Internet, applications and other protocols that choose to use
UDP as an Internet transport must employ mechanisms to prevent congestion collap
se and to establish some degree of fairness with concurrent traffic. They may a
lso need to implement additional mechanisms, depending on how they use UDP.</t>
<t indent="0">Some guidance is also applicable to the design of ot
her protocols (e.g., protocols layered directly on IP or via IP-based tunnels),
especially when these protocols do not themselves provide congestion control.</t
>
<t indent="0">This document obsoletes RFC 5405 and adds guidelines
for multicast UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8
445" quoteTitle="true" derivedAnchor="16">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal</title>
<author initials="A." surname="Keranen" fullname="A. Keranen">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Holmberg" fullname="C. Holmberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="July"/>
<abstract>
<t indent="0">This document describes a protocol for Network Addre
ss Translator (NAT) traversal for UDP-based communication. This protocol is cal
led Interactive Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using R
elay NAT (TURN).</t>
<t indent="0">This document obsoletes RFC 5245.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8445"/>
<seriesInfo name="DOI" value="10.17487/RFC8445"/>
</reference>
</references>
<references pn="section-17.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3
264" quoteTitle="true" derivedAnchor="17">
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)
</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<date year="2002" month="June"/>
<abstract>
<t indent="0">This document defines a mechanism by which two entit
ies can make use of the Session Description Protocol (SDP) to arrive at a common
view of a multimedia session between them. In the model, one participant offer
s the other a description of the desired session from their perspective, and the
other participant answers with the desired session from their perspective. Thi
s offer/answer model is most useful in unicast sessions where information from b
oth participants is needed for the complete view of the session. The offer/answ
er model is used by protocols like the Session Initiation Protocol (SIP). [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3264"/>
<seriesInfo name="DOI" value="10.17487/RFC3264"/>
</reference>
<reference anchor="RFC4376" target="https://www.rfc-editor.org/info/rfc4
376" quoteTitle="true" derivedAnchor="18">
<front>
<title>Requirements for Floor Control Protocols</title>
<author initials="P." surname="Koskelainen" fullname="P. Koskelainen
">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Ott" fullname="J. Ott">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<author initials="X." surname="Wu" fullname="X. Wu">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="February"/>
<abstract>
<t indent="0">Floor control is a means to manage joint or exclusiv
e access to shared resources in a (multiparty) conferencing environment. Thereby
, floor control complements other functions -- such as conference and media sess
ion setup, conference policy manipulation, and media control -- that are realize
d by other protocols. This document defines the requirements for a floor contro
l protocol for multiparty conferences in the context of an existing framework.
This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4376"/>
<seriesInfo name="DOI" value="10.17487/RFC4376"/>
</reference>
<reference anchor="RFC5239" target="https://www.rfc-editor.org/info/rfc5
239" quoteTitle="true" derivedAnchor="19">
<front>
<title>A Framework for Centralized Conferencing</title>
<author initials="M." surname="Barnes" fullname="M. Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Boulton" fullname="C. Boulton">
<organization showOnFrontPage="true"/>
</author>
<author initials="O." surname="Levin" fullname="O. Levin">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="June"/>
<abstract>
<t indent="0">This document defines the framework for Centralized
Conferencing. The framework allows participants using various call signaling pro
tocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange
media in a centralized unicast conference. The Centralized Conferencing Framewo
rk defines logical entities and naming conventions. The framework also outlines
a set of conferencing protocols, which are complementary to the call signaling
protocols, for building advanced conferencing applications. The framework binds
all the defined components together for the benefit of builders of conferencing
systems. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5239"/>
<seriesInfo name="DOI" value="10.17487/RFC5239"/>
</reference>
<reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3
261" quoteTitle="true" derivedAnchor="20">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Johnston" fullname="A. Johnston">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Sparks" fullname="R. Sparks">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Schooler" fullname="E. Schooler">
<organization showOnFrontPage="true"/>
</author>
<date year="2002" month="June"/>
<abstract>
<t indent="0">This document describes Session Initiation Protocol
(SIP), an application-layer control (signaling) protocol for creating, modifying
, and terminating sessions with one or more participants. These sessions includ
e Internet telephone calls, multimedia distribution, and multimedia conferences.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4
301" quoteTitle="true" derivedAnchor="21">
<front>
<title>Security Architecture for the Internet Protocol</title>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Seo" fullname="K. Seo">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="December"/>
<abstract>
<t indent="0">This document describes an updated version of the "S
ecurity Architecture for IP", which is designed to provide security services for
traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [S
TANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4301"/>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
</reference>
<reference anchor="RFC6501" target="https://www.rfc-editor.org/info/rfc6
501" quoteTitle="true" derivedAnchor="22">
<front>
<title>Conference Information Data Model for Centralized Conferencin
g (XCON)</title>
<author initials="O." surname="Novo" fullname="O. Novo">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Morgan" fullname="D. Morgan">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Urpalainen" fullname="J. Urpalainen">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">RFC 5239 defines centralized conferencing (XCON) as
an association of participants with a central focus. The state of a conference
is represented by a conference object. This document defines an XML- based conf
erence information data model to be used for conference objects. A conference i
nformation data model is designed to convey information about the conference and
about participation in the conference. The conference information data model d
efined in this document constitutes an extension of the data format specified in
the Session Initiation Protocol (SIP) event package for conference State. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6501"/>
<seriesInfo name="DOI" value="10.17487/RFC6501"/>
</reference>
<reference anchor="RFC6503" target="https://www.rfc-editor.org/info/rfc6
503" quoteTitle="true" derivedAnchor="23">
<front>
<title>Centralized Conferencing Manipulation Protocol</title>
<author initials="M." surname="Barnes" fullname="M. Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Boulton" fullname="C. Boulton">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Romano" fullname="S. Romano">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">The Centralized Conferencing Manipulation Protocol (
CCMP) allows a Centralized Conferencing (XCON) system client to create, retrieve
, change, and delete objects that describe a centralized conference. CCMP is a m
eans to control basic and advanced conference features such as conference state
and capabilities, participants, relative roles, and details. CCMP is a stateles
s, XML-based, client server protocol that carries, in its request and response m
essages, conference information in the form of XML documents and fragments confo
rming to the centralized conferencing data model schema. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6503"/>
<seriesInfo name="DOI" value="10.17487/RFC6503"/>
</reference>
<reference anchor="RFC6504" target="https://www.rfc-editor.org/info/rfc6
504" quoteTitle="true" derivedAnchor="24">
<front>
<title>Centralized Conferencing Manipulation Protocol (CCMP) Call Fl
ow Examples</title>
<author initials="M." surname="Barnes" fullname="M. Barnes">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Miniero" fullname="L. Miniero">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Presta" fullname="R. Presta">
<organization showOnFrontPage="true"/>
</author>
<author initials="S P." surname="Romano" fullname="S P. Romano">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">This document provides detailed call flows for the s
cenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 52
39) and in the XCON scenarios (RFC 4597). The call flows document the use of th
e interface between a conference control client and a conference control server
using the Centralized Conferencing Manipulation Protocol (CCMP) (RFC 6503). The
objective is to provide detailed examples for reference by both protocol resear
chers and developers. This document is not an Internet Standards Track specific
ation; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6504"/>
<seriesInfo name="DOI" value="10.17487/RFC6504"/>
</reference>
<reference anchor="RFC1191" target="https://www.rfc-editor.org/info/rfc1
191" quoteTitle="true" derivedAnchor="25">
<front>
<title>Path MTU discovery</title>
<author initials="J.C." surname="Mogul" fullname="J.C. Mogul">
<organization showOnFrontPage="true"/>
</author>
<author initials="S.E." surname="Deering" fullname="S.E. Deering">
<organization showOnFrontPage="true"/>
</author>
<date year="1990" month="November"/>
<abstract>
<t indent="0">This memo describes a technique for dynamically disc
overing the maximum transmission unit (MTU) of an arbitrary internet path. It s
pecifies a small change to the way routers generate one type of ICMP message. F
or a path that passes through a router that has not been so changed, this techni
que might not discover the correct Path MTU, but it will always choose a Path MT
U as accurate as, and in many cases more accurate than, the Path MTU that would
be chosen by current practice. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1191"/>
<seriesInfo name="DOI" value="10.17487/RFC1191"/>
</reference>
<reference anchor="RFC8201" target="https://www.rfc-editor.org/info/rfc8
201" quoteTitle="true" derivedAnchor="26">
<front>
<title>Path MTU Discovery for IP version 6</title>
<author initials="J." surname="McCann" fullname="J. McCann">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="July"/>
<abstract>
<t indent="0">This document describes Path MTU Discovery (PMTUD) f
or IP version 6. It is largely derived from RFC 1191, which describes Path MTU D
iscovery for IP version 4. It obsoletes RFC 1981.</t>
</abstract>
</front>
<seriesInfo name="STD" value="87"/>
<seriesInfo name="RFC" value="8201"/>
<seriesInfo name="DOI" value="10.17487/RFC8201"/>
</reference>
<reference anchor="RFC4821" target="https://www.rfc-editor.org/info/rfc4
821" quoteTitle="true" derivedAnchor="27">
<front>
<title>Packetization Layer Path MTU Discovery</title>
<author initials="M." surname="Mathis" fullname="M. Mathis">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Heffner" fullname="J. Heffner">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="March"/>
<abstract>
<t indent="0">This document describes a robust method for Path MTU
Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe
an Internet path with progressively larger packets. This method is described a
s an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Disco
very for IP versions 4 and 6, respectively. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4821"/>
<seriesInfo name="DOI" value="10.17487/RFC4821"/>
</reference>
<reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5
763" quoteTitle="true" derivedAnchor="28">
<front>
<title>Framework for Establishing a Secure Real-time Transport Proto
col (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</titl
e>
<author initials="J." surname="Fischl" fullname="J. Fischl">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="May"/>
<abstract>
<t indent="0">This document specifies how to use the Session Initi
ation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) s
ecurity context using the Datagram Transport Layer Security (DTLS) protocol. It
describes a mechanism of transporting a fingerprint attribute in the Session De
scription Protocol (SDP) that identifies the key that will be presented during t
he DTLS handshake. The key exchange travels along the media path as opposed to
the signaling path. The SIP Identity mechanism can be used to protect the integ
rity of the fingerprint attribute from modification by intermediate proxies. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5763"/>
<seriesInfo name="DOI" value="10.17487/RFC5763"/>
</reference>
<reference anchor="RFC6951" target="https://www.rfc-editor.org/info/rfc6
951" quoteTitle="true" derivedAnchor="29">
<front>
<title>UDP Encapsulation of Stream Control Transmission Protocol (SC
TP) Packets for End-Host to End-Host Communication</title>
<author initials="M." surname="Tuexen" fullname="M. Tuexen">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Stewart" fullname="R. Stewart">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="May"/>
<abstract>
<t indent="0">This document describes a simple method of encapsula
ting Stream Control Transmission Protocol (SCTP) packets into UDP packets and it
s limitations. This allows the usage of SCTP in networks with legacy NATs that
do not support SCTP. It can also be used to implement SCTP on hosts without dir
ectly accessing the IP layer, for example, implementing it as part of the applic
ation without requiring special privileges.</t>
<t indent="0">Please note that this document only describes the fu
nctionality required within an SCTP stack to add on UDP encapsulation, providing
only those mechanisms for two end-hosts to communicate with each other over UDP
ports. In particular, it does not provide mechanisms to determine whether UDP
encapsulation is being used by the peer, nor the mechanisms for determining whic
h remote UDP port number can be used. These functions are out of scope for this
document.</t>
<t indent="0">This document covers only end-hosts and not tunnelin
g (egress or ingress) endpoints.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6951"/>
<seriesInfo name="DOI" value="10.17487/RFC6951"/>
</reference>
<reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7
525" quoteTitle="true" derivedAnchor="30">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Holz" fullname="R. Holz">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="May"/>
<abstract>
<t indent="0">Transport Layer Security (TLS) and Datagram Transpor
t Layer Security (DTLS) are widely used to protect data exchanged over applicati
on protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few ye
ars, several serious attacks on TLS have emerged, including attacks on its most
commonly used cipher suites and their modes of operation. This document provide
s recommendations for improving the security of deployed services that use TLS a
nd DTLS. The recommendations are applicable to the majority of use cases.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="DOI" value="10.17487/RFC7525"/>
</reference>
<reference anchor="RFC4380" target="https://www.rfc-editor.org/info/rfc4
380" quoteTitle="true" derivedAnchor="31">
<front>
<title>Teredo: Tunneling IPv6 over UDP through Network Address Trans
lations (NATs)</title>
<author initials="C." surname="Huitema" fullname="C. Huitema">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="February"/>
<abstract>
<t indent="0">We propose here a service that enables nodes located
behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 conn
ectivity by tunneling packets over UDP; we call this the Teredo service. Runnin
g the service requires the help of "Teredo servers" and "Teredo relays". The Te
redo servers are stateless, and only have to manage a small fraction of the traf
fic between Teredo clients; the Teredo relays act as IPv6 routers between the Te
redo service and the "native" IPv6 Internet. The relays can also provide intero
perability with hosts using other transition mechanisms such as "6to4". [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4380"/>
<seriesInfo name="DOI" value="10.17487/RFC4380"/>
</reference>
<reference anchor="RFC6081" target="https://www.rfc-editor.org/info/rfc6
081" quoteTitle="true" derivedAnchor="32">
<front>
<title>Teredo Extensions</title>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization showOnFrontPage="true"/>
</author>
<date year="2011" month="January"/>
<abstract>
<t indent="0">This document specifies a set of extensions to the T
eredo protocol. These extensions provide additional capabilities to Teredo, incl
uding support for more types of Network Address Translations (NATs) and support
for more efficient communication. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6081"/>
<seriesInfo name="DOI" value="10.17487/RFC6081"/>
</reference>
<reference anchor="RFC4960" target="https://www.rfc-editor.org/info/rfc4
960" quoteTitle="true" derivedAnchor="33">
<front>
<title>Stream Control Transmission Protocol</title>
<author initials="R." surname="Stewart" fullname="R. Stewart" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="September"/>
<abstract>
<t indent="0">This document obsoletes RFC 2960 and RFC 3309. It d
escribes the Stream Control Transmission Protocol (SCTP). SCTP is designed to t
ransport Public Switched Telephone Network (PSTN) signaling messages over IP net
works, but is capable of broader applications.</t>
<t indent="0">SCTP is a reliable transport protocol operating on t
op of a connectionless packet network such as IP. It offers the following servi
ces to its users:</t>
<t indent="0">-- acknowledged error-free non-duplicated transfer
of user data,</t>
<t indent="0">-- data fragmentation to conform to discovered path
MTU size,</t>
<t indent="0">-- sequenced delivery of user messages within multi
ple streams, with an option for order-of-arrival delivery of individual user mes
sages,</t>
<t indent="0">-- optional bundling of multiple user messages into
a single SCTP packet, and</t>
<t indent="0">-- network-level fault tolerance through supporting
of multi-homing at either or both ends of an association.</t>
<t indent="0"> The design of SCTP includes appropriate congestion
avoidance behavior and resistance to flooding and masquerade attacks. [STANDARD
S-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4960"/>
<seriesInfo name="DOI" value="10.17487/RFC4960"/>
</reference>
<reference anchor="RFC6544" target="https://www.rfc-editor.org/info/rfc6
544" quoteTitle="true" derivedAnchor="34">
<front>
<title>TCP Candidates with Interactive Connectivity Establishment (I
CE)</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Keranen" fullname="A. Keranen">
<organization showOnFrontPage="true"/>
</author>
<author initials="B. B." surname="Lowekamp" fullname="B. B. Lowekamp
">
<organization showOnFrontPage="true"/>
</author>
<author initials="A. B." surname="Roach" fullname="A. B. Roach">
<organization showOnFrontPage="true"/>
</author>
<date year="2012" month="March"/>
<abstract>
<t indent="0">Interactive Connectivity Establishment (ICE) defines
a mechanism for NAT traversal for multimedia communication protocols based on t
he offer/answer model of session negotiation. ICE works by providing a set of c
andidate transport addresses for each media stream, which are then validated wit
h peer-to-peer connectivity checks based on Session Traversal Utilities for NAT
(STUN). ICE provides a general framework for describing candidates but only def
ines UDP-based media streams. This specification extends ICE to TCP-based media,
including the ability to offer a mix of TCP and UDP-based candidates for a sing
le stream. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6544"/>
<seriesInfo name="DOI" value="10.17487/RFC6544"/>
</reference>
<reference anchor="I-D.manner-tsvwg-gut" quoteTitle="true" target="https
://tools.ietf.org/html/draft-manner-tsvwg-gut-02" derivedAnchor="35">
<front>
<title>Generic UDP Tunnelling (GUT)</title>
<author initials="J" surname="Manner" fullname="Jukka Manner">
<organization showOnFrontPage="true"/>
</author>
<author initials="N" surname="Varis" fullname="Nuutti Varis">
<organization showOnFrontPage="true"/>
</author>
<author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization showOnFrontPage="true"/>
</author>
<date month="July" day="12" year="2010"/>
<abstract>
<t indent="0">Deploying new transport protocols on the Internet is
a well-known problem, as NATs and firewall drop packets with e.g. new protocol
types or unidentified TCP options. Tunnelling over UDP is one way to make IP pa
ckets hide the actual payload and enable end-to-end delivery. This document pro
poses a simple UDP tunnelling encapsulation and end-host operation to enable new
(and old) IP payloads, e.g., new transport protocols, to be deployed on the Int
ernet.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-manner-tsvwg-gut-02"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-m
anner-tsvwg-gut-02.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="I-D.ietf-mmusic-media-path-middleboxes" quoteTitle="t
rue" target="https://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxe
s-07" derivedAnchor="36">
<front>
<title>Analysis of Middlebox Interactions for Signaling Protocol Com
munication along the Media Path</title>
<author initials="B" surname="Stucker" fullname="Brian Stucker">
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Tschofenig" fullname="Hannes Tschofeni
g">
<organization showOnFrontPage="true"/>
</author>
<author initials="G" surname="Salgueiro" fullname="Gonzalo Salgueiro
">
<organization showOnFrontPage="true"/>
</author>
<date month="May" day="30" year="2013"/>
<abstract>
<t indent="0">Middleboxes are defined as any intermediary box perf
orming functions apart from normal, standard functions of an IP router on the da
ta path between a source host and destination host. Two such functions are netw
ork address translation and firewalling. When Application Layer Gateways, such
as SIP entities, interact with NATs and firewalls, as described in the MIDCOM ar
chitecture, then problems may occur in the transport of media traffic when signa
ling protocol interaction takes place along the media path, as it is the case fo
r recent key exchange proposals (such as DTLS-SRTP). This document highlights p
roblems that may arise. Unfortunately, it is difficult for the end points to de
tect or predict problematic behavior and to determine whether the media path is
reliably available for packet exchange. This document aims to summarize the var
ious sources and effects of NAT and firewall control, the reasons that they exis
t, and possible means of improving their behavior to allow protocols that rely u
pon signaling along the media path to operate effectively.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-media-path-
middleboxes-07"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-i
etf-mmusic-media-path-middleboxes-07.txt"/>
<refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="IMC05" target="https://www.usenix.org/legacy/event/im
c05/tech/full_papers/guha/guha.pdf" quoteTitle="true" derivedAnchor="37">
<front>
<title>Characterization and Measurement of TCP Traversal through NAT
s and Firewalls</title>
<author initials="S" surname="Guha"/>
<author initials="P" surname="Francis"/>
<date month="" year="2005"/>
</front>
</reference>
<reference anchor="P2PNAT" target="https://www.usenix.org/legacy/events/
usenix05/tech/general/full_papers/ford/ford.pdf" quoteTitle="true" derivedAnchor
="38">
<front>
<title>Peer-to-Peer Communication Across Network Address Translators
</title>
<author initials="B" surname="Ford"/>
<author initials="P" surname="Srisuresh"/>
<author initials="D" surname="Kegel"/>
<date month="April" year="2005"/>
</front>
</reference>
</references>
</references>
<section anchor="app_unrelcallflow" numbered="true" toc="include" removeInRF
C="false" pn="section-appendix.a">
<name slugifiedName="name-example-call-flows-for-bfcp">Example Call Flows
for BFCP over an Unreliable Transport</name>
<t indent="0" pn="section-appendix.a-1">With reference to <xref target="se
c_overview_user" format="default" sectionFormat="of" derivedContent="Section 4.1
"/>, the following figures show representative call flows for requesting and rel
easing a floor, and obtaining status information about a floor when BFCP is depl
oyed over an unreliable transport. The figures here show a lossless interaction.
</t>
<figure anchor="ReqRelUnrelExample" align="left" suppress-title="false" pn
="figure-48">
<name slugifiedName="name-requesting-and-releasing-a-f">Requesting and r
eleasing a floor</name>
<artwork align="left" name="" type="" alt="" pn="section-appendix.a-2.1"
>
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 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(2) FloorRequestStatus | |(2) FloorRequestStatus |
|Transaction Responder: 1 | |Transaction Responder: 1 |
|Transaction ID: 123 | |Transaction ID: 123 |
|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: Pending | | Request Status: Pending |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(3) FloorRequestStatus | |(3) FloorRequestStatus |
|Transaction Responder: 0 | |Transaction Responder: 0 |
|Transaction ID: 124 | |Transaction ID: 124 |
|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: Accepted | | Request Status: Accepted |
| Queue Position: 1st | | Queue Position: 1st |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(4) FloorRequestStatusAck | |(4) FloorRequestStatusAck |
|Transaction Responder: 1 | |Transaction Responder: 1 |
|Transaction ID: 124 | |Transaction ID: 124 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(5) FloorRequestStatus | |(5) FloorRequestStatus |
|Transaction Responder: 0 | |Transaction Responder: 0 |
|Transaction ID: 125 | |Transaction ID: 125 |
|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: Granted | | Request Status: Granted |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(6) FloorRequestStatusAck | |(6) FloorRequestStatusAck |
|Transaction Responder: 1 | |Transaction Responder: 1 |
|Transaction ID: 125 | |Transaction ID: 125 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(7) FloorRelease | |(7) FloorRelease |
|Transaction Responder: 0 | |Transaction Responder: 0 |
|Transaction ID: 126 | |Transaction ID: 126 |
|User ID: 234 | |User ID: 234 |
|FLOOR-REQUEST-ID: 789 | |FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(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 |
|<----------------------------------------------| ]]> |&lt;----------------------------------------------|</artwork>
</artwork> </figure>
</figure></t> <t indent="0" pn="section-appendix.a-3">Note that in <xref target="ReqRelU
<t>Note that in <xref target="ReqRelUnrelExample"/>, the FloorRequestStatus nrelExample" format="default" sectionFormat="of" derivedContent="Figure 48"/>, t
message from the floor control server to the floor participant is a transaction- he
closing message as a response to the client-initiated transaction with Transacti FloorRequestStatus message from the floor control server to the floor
on ID 154. As such, it is not followed by a FloorRequestStatusAck message from t participant is a transaction-closing message as a response to the
he floor participant to the floor control server.</t> client-initiated transaction with Transaction ID 126. As such, it is not
<t><figure align="left" anchor="StatusUnrelExample" title="Obtaining status followed by a FloorRequestStatusAck message from the floor participant to
information about a floor"> the floor control server.</t>
<artwork align="left"><![CDATA[ <figure anchor="StatusUnrelExample" align="left" suppress-title="false" pn
="figure-49">
<name slugifiedName="name-obtaining-status-information">Obtaining status
information about a floor</name>
<artwork align="left" name="" type="" alt="" pn="section-appendix.a-4.1"
>
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 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(2) FloorStatus | |(2) FloorStatus |
|Transaction Responder: 1 | |Transaction Responder: 1 |
|Transaction ID: 257 | |Transaction ID: 257 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 | | Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
skipping to change at line 1937 skipping to change at line 3904
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 2nd | | Queue Position: 2nd |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(3) FloorStatus | |(3) FloorStatus |
|Transaction Responder: 0 | |Transaction Responder: 0 |
|Transaction ID: 258 | |Transaction ID: 258 |
|User ID: 234 | |User ID: 234 |
|FLOOR-ID:543 | |FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 | | Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Granted | | Request Status: Granted |
skipping to change at line 1961 skipping to change at line 3928
| Beneficiary ID: 124 | | Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION | |FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 | | Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS | | OVERALL-REQUEST-STATUS |
| Request Status: Accepted | | Request Status: Accepted |
| Queue Position: 1st | | Queue Position: 1st |
| FLOOR-REQUEST-STATUS | | FLOOR-REQUEST-STATUS |
| Floor ID: 543 | | Floor ID: 543 |
| BENEFICIARY-INFORMATION | | BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 | | Beneficiary ID: 154 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(4) FloorStatusAck | |(4) FloorStatusAck |
|Transaction Responder: 1 | |Transaction Responder: 1 |
|Transaction ID: 258 | |Transaction ID: 258 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| |----------------------------------------------&gt;|
| | | |
|(5) FloorStatus | |(5) FloorStatus |
|Transaction Responder: 0 | |Transaction Responder: 0 |
|Transaction ID: 259 | |Transaction ID: 259 |
|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 |
|<----------------------------------------------| |&lt;----------------------------------------------|
| | | |
|(6) FloorStatusAck | |(6) FloorStatusAck |
|Transaction Responder: 1 | |Transaction Responder: 1 |
|Transaction ID: 259 | |Transaction ID: 259 |
|User ID: 234 | |User ID: 234 |
|---------------------------------------------->| ]]> |----------------------------------------------&gt;|</artwork>
</artwork> </figure>
</figure></t> </section>
</section> <section anchor="app_motivation" numbered="true" toc="include" removeInRFC="
false" pn="section-appendix.b">
<section title="Motivation for Supporting an Unreliable Transport" anchor="app <name slugifiedName="name-motivation-for-supporting-a">Motivation for Supp
:motivation"> orting an Unreliable Transport</name>
<t>This appendix is contained in this document as an aid to understand the b <t indent="0" pn="section-appendix.b-1">This appendix is provided as an ai
ackground and rationale for adding support for unreliable transport.</t> d to understand the background and rationale for adding support for unreliable t
ransport.</t>
<section anchor="motivation" title="Motivation"> <section anchor="motivation" numbered="true" toc="include" removeInRFC="fa
<t>In existing video conferencing deployments, BFCP is used to manage the lse" pn="section-b.1">
floor for the content sharing associated with the conference. For peer to peer s <name slugifiedName="name-motivation">Motivation</name>
cenarios, including business to business conferences and point to point conferen <t indent="0" pn="section-b.1-1">In existing video conferencing deployme
ces in general, it is frequently the case that one or both endpoints exists behi nts, BFCP is used to manage the floor for the content sharing associated with th
nd a NAT. BFCP roles are negotiated in the offer/answer exchange as specified in e conference. For peer-to-peer scenarios, including business-to-business confere
<xref target="I-D.ietf-bfcpbis-rfc4583bis"/>, resulting in one endpoint being r nces and point-to-point conferences in general, it is frequently the case that o
esponsible for opening the TCP connection used for the BFCP communication.</t> ne or both endpoints exist behind a NAT. BFCP roles are negotiated in the offer/
<t><figure align="left" anchor="use_case" title="Use Case"> answer exchange as specified in <xref target="RFC8856" format="default" sectionF
<artwork align="center"><![CDATA[ ormat="of" derivedContent="12"/>, resulting in one endpoint being responsible fo
r opening the TCP connection used for the BFCP communication.</t>
<figure anchor="use_case" align="left" suppress-title="false" pn="figure
-50">
<name slugifiedName="name-use-case">Use case</name>
<artwork align="center" name="" type="" alt="" pn="section-b.1-2.1">
+---------+ +---------+
| Network | | Network |
+---------+ +---------+
+-----+ / \ +-----+ +-----+ / \ +-----+
| NAT |/ \| NAT | | NAT |/ \| NAT |
+-----+ +-----+ +-----+ +-----+
+----+ / \ +----+ +----+ / \ +----+
|BFCP|/ \|BFCP| |BFCP|/ \|BFCP|
| UA | | UA | | UA | | UA |
+----+ +----+ ]]></artwork> +----+ +----+</artwork>
</figure></t> </figure>
<t indent="0" pn="section-b.1-3">The communication session between the v
<t>The communication session between the video conferencing endpoints typi ideo conferencing endpoints typically consists of a number of RTP over UDP media
cally consists of a number of RTP over UDP media streams, for audio and video, a streams for audio and video and a BFCP connection for floor control. Existing d
nd a BFCP connection for floor control. Existing deployments are most common in, eployments are most common in, but not limited to, enterprise networks. In exist
but not limited to, enterprise networks. In existing deployments, NAT traversal ing deployments, NAT traversal for the RTP streams works using ICE and/or other
for the RTP streams works using ICE and/or other methods, including those descr methods, including those described in <xref target="I-D.ietf-mmusic-media-path-m
ibed in <xref target="I-D.ietf-mmusic-media-path-middleboxes"/>.</t> iddleboxes" format="default" sectionFormat="of" derivedContent="36"/>.</t>
<t>When enhancing an existing SIP based video conferencing deployment with <t indent="0" pn="section-b.1-4">When enhancing an existing SIP-based vi
support for content sharing, the BFCP connection often poses a problem. The rea deo conferencing deployment with support for content sharing, the BFCP connectio
sons for this fall into two general classes. First, there may be a strong prefer n often poses a problem. The reasons for this fall into two general classes. Fir
ence for UDP based signaling in general. On high capacity endpoints (e.g., PSTN st, there may be a strong preference for UDP-based signaling in general. On high
gateways or SIP/H.323 inter-working gateways), TCP can suffer from head of line -capacity endpoints (e.g., Public Switched Telephone Network (PSTN) gateways or
blocking, and it uses many kernel buffers. Network operators view UDP as a way t SIP/H.323 inter-working gateways), TCP can suffer from head-of-line blocking, an
o avoid both of these. Second, establishment and traversal of the TCP connection d it uses many kernel buffers. Network operators view UDP as a way to avoid both
involving ephemeral ports, as is typically the case with BFCP over TCP, can be of these. Second, the establishment and traversal of the TCP connection involvi
problematic, as described in Appendix A of <xref target="RFC6544"/>. A broad stu ng ephemeral ports, as is typically the case with BFCP over TCP, can be problema
dy of NAT behavior and peer-to-peer TCP establishment for a comprehensive set of tic, as described in <xref target="RFC6544" section="A" sectionFormat="of" forma
TCP NAT traversal techniques over a wide range of commercial NAT products concl t="default" derivedLink="https://rfc-editor.org/rfc/rfc6544#appendix-A" derivedC
uded it was not possible to establish a TCP connection in 11% of the cases <xref ontent="34"/>. A broad study of NAT behavior and peer-to-peer TCP establishment
target="IMC05"/>. The results are worse when focusing on enterprise NATs. A stu for a comprehensive set of TCP NAT traversal techniques over a wide range of com
dy of hole punching as a NAT traversal technique across a wide variety of deploy mercial NAT products concluded that it was not possible to establish a TCP conne
ed NATs reported consistently higher success rates when using UDP than when usin ction in 11% of the cases <xref target="IMC05" format="default" sectionFormat="o
g TCP <xref target="P2PNAT"/>.</t> f" derivedContent="37"/>. The results are worse when focusing on enterprise NATs
<t>It is worth noticing that BFCP over UDP is already being used in real d . A study of hole-punching as a NAT traversal technique across a wide variety of
eployments, underlining the necessity to specify a common way to exchange BFCP m deployed NATs reported consistently higher success rates when using UDP than wh
essages where TCP is not appropriate, to avoid a situation where multiple differ en using TCP <xref target="P2PNAT" format="default" sectionFormat="of" derivedCo
ent and non-interoperable implementations would co-exist in the market. The purp ntent="38"/>.</t>
ose of this draft is to formalize and publish the extension from the standard sp <t indent="0" pn="section-b.1-5">It is worth noting that BFCP over UDP i
ecification to facilitate complete interoperability between implementations.</t> s already being used in real deployments, underlining the necessity to specify a
common way to exchange BFCP messages where TCP is not appropriate, to avoid a s
<section anchor="alternatives" title="Alternatives Considered"> ituation where multiple different and non-interoperable implementations would co
<t>In selecting the approach of defining UDP as an alternate transport f exist in the market. The purpose of this document is to extend the standard spec
or BFCP, several alternatives were considered and explored to some degree. Each ification to support unreliable transport in order to facilitate complete intero
of these is discussed briefly in the following subsections. In summary, while th perability between implementations.</t>
e not chosen alternatives work in a number of scenarios, they are not sufficient <section anchor="alternatives" numbered="true" toc="include" removeInRFC
, in and of themselves, to address the use case targeted by this draft. The last ="false" pn="section-b.1.1">
alternative, presented in <xref target="thisextension"/>, is the selected one a <name slugifiedName="name-alternatives-considered">Alternatives Consid
nd is specified in this draft.</t> ered</name>
<t>It is also worth noting that the IETF Transport Area were asked for a <t indent="0" pn="section-b.1.1-1">In selecting the approach of defini
way to tunnel TCP over UDP, but at that point there was no consensus on how to ng UDP as an alternate transport for BFCP, several alternatives were considered
achieve that.</t> and explored to some degree. Each of these is discussed briefly in the following
subsections. In summary, while the alternatives that were not chosen work in a
<section anchor="ice_tcp" title="ICE TCP"> number of scenarios, they are not sufficient, in and of themselves, to address t
<t>ICE TCP <xref target="RFC6544"/> extends ICE to TCP based media, in he use case targeted by this document. The last alternative, presented in <xref
cluding the ability to offer a mix of TCP and UDP based candidates for a single target="thisextension" format="default" sectionFormat="of" derivedContent="Appen
stream. ICE TCP has, in general, a lower success probability for enabling TCP co dix B.1.1.7"/>, was selected and is specified in this document.</t>
nnectivity without a relay if both of the hosts are behind a NAT (see Appendix A <t indent="0" pn="section-b.1.1-2">It is also worth noting that the IE
of <xref target="RFC6544"/>) than enabling UDP connectivity in the same scenari TF Transport Area was asked for a way to tunnel TCP over UDP, but at that point
os. The happens because many of the currently deployed NATs in video conferencin there was no consensus on how to achieve that.</t>
g networks do not support the flow of TCP hand shake packets seen in case of TCP <section anchor="ice_tcp" numbered="true" toc="include" removeInRFC="f
simultaneous-open, either because they do not allow incoming TCP SYN packets fr alse" pn="section-b.1.1.1">
om an address to which a SYN packet has been sent to recently, or because they d <name slugifiedName="name-ice-tcp">ICE TCP</name>
o not properly process the subsequent SYNACK. Implementing various techniques ad <t indent="0" pn="section-b.1.1.1-1">ICE TCP <xref target="RFC6544"
vocated for candidate collection in <xref target="RFC6544"/> should increase the format="default" sectionFormat="of" derivedContent="34"/> extends ICE to TCP-bas
success probability, but many of these techniques require support from some net ed media, including the ability to offer a mix of TCP- and UDP-based candidates
work elements (e.g., from the NATs). Such support is not common in enterprise NA for a single stream. ICE TCP has, in general, a lower success probability for en
Ts.</t> abling TCP connectivity without a relay if both of the hosts are behind a NAT (s
</section> ee <xref target="RFC6544" section="A" sectionFormat="of" format="default" derive
dLink="https://rfc-editor.org/rfc/rfc6544#appendix-A" derivedContent="34"/>) tha
<section anchor="teredo" title="Teredo"> n enabling UDP connectivity in the same scenarios. The happens because many of t
<t>Teredo <xref target="RFC4380"/> enables nodes located behind one or he currently deployed NATs in video conferencing networks do not support the flo
more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. Tere w of TCP handshake packets seen in the case of TCP simultaneous-open, either bec
do extensions <xref target="RFC6081"/> provide additional capabilities to Teredo ause they do not allow incoming TCP SYN packets from an address to which a SYN p
, including support for more types of NATs and support for more efficient commun acket has been sent recently, or because they do not properly process the subseq
ication.</t> uent SYNACK. Implementing various techniques advocated for candidate collection
<t>As defined, Teredo could be used to make BFCP work for the video co in <xref target="RFC6544" format="default" sectionFormat="of" derivedContent="34
nferencing use cases addressed in this draft. However, running the service requi "/> should increase the success probability, but many of these techniques requir
res the help of "Teredo servers" and "Teredo relays" <xref target="RFC4380"/>. T e support from some network elements (e.g., from the NATs). Such support is not
hese servers and relays generally do not exist in the existing video conferencin common in enterprise NATs.</t>
g deployments. It also requires IPv6 awareness on the endpoints. It should also </section>
be noted that ICMP6, as used with Teredo to complete an initial protocol exchang <section anchor="teredo" numbered="true" toc="include" removeInRFC="fa
e and confirm that the appropriate NAT bindings have been set up, is not a conve lse" pn="section-b.1.1.2">
ntional feature of IPv4 or even IPv6, and some currently deployed IPv6 firewalls <name slugifiedName="name-teredo">Teredo</name>
discard ICMP messages. As these networks continue to evolve and tackle the tran <t indent="0" pn="section-b.1.1.2-1">Teredo <xref target="RFC4380" f
saction to IPv6, Teredo servers and relays may be deployed, making Teredo availa ormat="default" sectionFormat="of" derivedContent="31"/> enables nodes located b
ble as a suitable alternative to BFCP over UDP.</t> ehind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets ove
</section> r UDP. Teredo extensions <xref target="RFC6081" format="default" sectionFormat=
"of" derivedContent="32"/> provide additional capabilities to Teredo, including
<section anchor="gut" title="GUT"> support for more types of NATs and support for more efficient communication.</t>
<t>GUT <xref target="I-D.manner-tsvwg-gut"/> attempts to facilitate tu <t indent="0" pn="section-b.1.1.2-2">As defined, Teredo could be use
nneling over UDP by encapsulating the native transport protocol and its payload d to make BFCP work for the video conferencing use cases addressed in this docum
(in general the whole IP payload) within a UDP packet destined to the well-known ent. However, running the service requires the help of "Teredo servers" and "Ter
port GUT_P. Unfortunately, it requires user-space TCP, for which there is not a edo relays" <xref target="RFC4380" format="default" sectionFormat="of" derivedCo
readily available implementation, and creating one is a large project in itself ntent="31"/>. These servers and relays generally do not exist in current video c
. This draft has expired and its future is still not clear as it has not yet bee onferencing deployments. It also requires IPv6 awareness on the endpoints. It sh
n adopted by a working group.</t> ould also be noted that ICMP6, as used with Teredo to complete an initial protoc
</section> ol exchange and confirm that the appropriate NAT bindings have been set up, is n
ot a conventional feature of IPv4 or even IPv6, and some currently deployed IPv6
<section anchor="upnp_igd" title="UPnP IGD"> firewalls discard ICMP messages. As these networks continue to evolve and tackl
<t>Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on e the transaction to IPv6, Teredo servers and relays may be deployed, making Ter
the edge of the network, providing connectivity to the Internet for computers in edo available as a suitable alternative to BFCP over UDP.</t>
ternal to the LAN, but do not allow Internet devices to connect to computers on </section>
the internal LAN. IGDs enable a computer on an internal LAN to create port mappi <section anchor="gut" numbered="true" toc="include" removeInRFC="false
ngs on their NAT, through which hosts on the Internet can send data that will be " pn="section-b.1.1.3">
forwarded to the computer on the internal LAN. IGDs may be self-contained hardw <name slugifiedName="name-gut">GUT</name>
are devices or may be software components provided within an operating system.</ <t indent="0" pn="section-b.1.1.3-1">GUT <xref target="I-D.manner-ts
t> vwg-gut" format="default" sectionFormat="of" derivedContent="35"/>
<t>In considering UPnP IGD, several issues exist. Not all NATs support attempts to facilitate tunneling over UDP by encapsulating the
UPnP, and many that do support it are configured with it turned off by default. native transport protocol and its payload (in general the whole IP
NATs are often multilayered, and UPnP does not work well with such NATs. For ex payload) within a UDP packet destined to the well-known port
ample, a typical DSL modems acts as a NAT, and the user plugs in a wireless acce GUT_P. Unfortunately, it requires user-space TCP, for which there
ss point behind that, which adds another layer NAT. The client can discover the is not a readily available implementation, and creating one is a
first layer of NAT using multicast but it is harder to figure out how to discove large project in itself. This document has expired, and its future is
r and control NATs in the next layer up.</t> still unclear as it has not yet been adopted by a working group.</t>
</section> </section>
<section anchor="upnp_igd" numbered="true" toc="include" removeInRFC="
<section anchor="nat_pmp" title="NAT PMP"> false" pn="section-b.1.1.4">
<t>The NAT Port Mapping Protocol (NAT PMP) allows a computer in a priv <name slugifiedName="name-upnp-igd">UPnP IGD</name>
ate network (behind a NAT router) to automatically configure the router to allow <t indent="0" pn="section-b.1.1.4-1">Universal Plug and Play Interne
parties outside the private network to contact it. NAT PMP runs over UDP. It es t Gateway Devices (UPnP IGD) sit on the edge of the network, providing connectiv
sentially automates the process of port forwarding. Included in the protocol is ity to the Internet for computers internal to the LAN, but do not allow Internet
a method for retrieving the public IP address of a NAT gateway, thus allowing a devices to connect to computers on the internal LAN. IGDs enable a computer on
client to make this public IP address and port number known to peers that may wi an internal LAN to create port mappings on their NAT, through which hosts on the
sh to communicate with it.</t> Internet can send data that will be forwarded to the computer on the internal L
<t>Many NATs do not support PMP. In those that do support it, it has s AN. IGDs may be self-contained hardware devices or may be software components pr
imilar issues with negotiation of multilayer NATs as UPnP. Video conferencing is ovided within an operating system.</t>
used extensively in enterprise networks, and NAT PMP is not generally available <t indent="0" pn="section-b.1.1.4-2">In considering UPnP IGD, severa
in enterprise-class routers.</t> l issues exist. Not all NATs support UPnP, and many that do support it are confi
</section> gured with it turned off by default. NATs are often multilayered, and UPnP does
not work well with such NATs. For example, a typical DSL modem acts as a NAT, an
<section anchor="sctp_udp" title="SCTP"> d the user plugs in a wireless access point behind that, which adds another laye
<t>It would be quite straight forward to specify a BFCP binding for SC r of NAT. The client can discover the first layer of NAT using multicast, but it
TP <xref target="RFC4960"/>, and then tunnel SCTP over UDP in the use case descr is harder to figure out how to discover and control NATs in the next layer up.<
ibed in <xref target="motivation"/>. SCTP is gaining some momentum currently. Th /t>
ere was ongoing discussion in the RTCWeb WG regarding this approach, which resul </section>
ted in <xref target="RFC6951"/>. However, this approach for tunneling over UDP w <section anchor="nat_pmp" numbered="true" toc="include" removeInRFC="f
as not mature enough when considered and not even fully specified.</t> alse" pn="section-b.1.1.5">
</section> <name slugifiedName="name-nat-pmp">NAT PMP</name>
<t indent="0" pn="section-b.1.1.5-1">The NAT Port Mapping Protocol (
<section anchor="thisextension" title="BFCP over UDP transport"> NAT PMP) allows a computer in a private network (behind a NAT router) to automat
<t>To overcome the problems with establishing TCP flows between BFCP e ically configure the router to allow parties outside the private network to cont
ntities, an alternative is to define UDP as an alternate transport for BFCP, lev act it. NAT PMP runs over UDP. It essentially automates the process of port forw
eraging the same mechanisms in place for the RTP over UDP media streams for the arding. Included in the protocol is a method for retrieving the public IP addres
BFCP communication. When using UDP as the transport, it is recommended to follow s of a NAT gateway, thus allowing a client to make this public IP address and po
the guidelines provided in <xref target="RFC5405"/>.</t> rt number known to peers that may wish to communicate with it.</t>
<t>Minor changes to the transaction model are introduced in that all r <t indent="0" pn="section-b.1.1.5-2">Many NATs do not support PMP. I
equests now have an appropriate response to complete the transaction. The reques n those that do support it, it has similar issues with negotiation of multilayer
ts are sent with a retransmit timer associated with the response to achieve reli NATs as UPnP. Video conferencing is used extensively in enterprise networks, an
ability. This alternative does not change the semantics of BFCP. It permits UDP d NAT PMP is not generally available in enterprise-class routers.</t>
as an alternate transport.</t> </section>
<t>Existing implementations, in the spirit of the approach detailed in <section anchor="sctp_udp" numbered="true" toc="include" removeInRFC="
earlier versions of this draft, have demonstrated this approach to be feasible. false" pn="section-b.1.1.6">
Initial compatibility among implementations has been achieved at previous inter <name slugifiedName="name-sctp">SCTP</name>
operability events. The authors view this extension as a pragmatic solution to a <t indent="0" pn="section-b.1.1.6-1">It would be quite straightforwa
n existing deployment challenge. This is the chosen approach, and the extensions rd to specify a BFCP binding for Stream Control Transmission Protocol (SCTP) <xr
are specified in this document.</t> ef target="RFC4960" format="default" sectionFormat="of" derivedContent="33"/>, a
nd then tunnel SCTP over UDP in the use case described in <xref target="motivati
on" format="default" sectionFormat="of" derivedContent="Appendix B.1"/>. SCTP is
gaining some momentum currently. There was ongoing discussion in the RTCWeb Wor
king Group regarding this approach, which resulted in <xref target="RFC6951" for
mat="default" sectionFormat="of" derivedContent="29"/>. However, this approach t
o tunneling over UDP was not mature enough when considered and was not even full
y specified.</t>
</section>
<section anchor="thisextension" numbered="true" toc="include" removeIn
RFC="false" pn="section-b.1.1.7">
<name slugifiedName="name-bfcp-over-udp-transport">BFCP over UDP Tra
nsport</name>
<t indent="0" pn="section-b.1.1.7-1">To overcome the problems with e
stablishing TCP flows between BFCP entities, an alternative is to define UDP as
an alternate transport for BFCP, leveraging the same mechanisms in place for the
RTP over UDP media streams for the BFCP communication. When using UDP as the tr
ansport, following the guidelines provided in <xref target="RFC8085" format="def
ault" sectionFormat="of" derivedContent="15"/> is recommended.</t>
<t indent="0" pn="section-b.1.1.7-2">Minor changes to the transactio
n model have been introduced in that all requests now have an appropriate respon
se to complete the transaction. The requests are sent with a retransmission time
r associated with the response to achieve reliability. This alternative does not
change the semantics of BFCP. It permits UDP as an alternate transport.</t>
<t indent="0" pn="section-b.1.1.7-3">Existing implementations, in th
e spirit of the approach detailed in earlier draft versions of this document, ha
ve demonstrated that this approach is feasible. Initial compatibility among impl
ementations has been achieved at previous interoperability events. The authors v
iew this extension as a pragmatic solution to an 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> <section anchor="sec_acks" numbered="false" toc="include" removeInRFC="false
" pn="section-appendix.c">
</back> <name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.c-1">The XCON Working Group chairs, <co
ntact fullname="Adam Roach"/> and <contact fullname="Alan Johnston"/>, provided
useful ideas for RFC 4582 <xref target="RFC4582" format="default" sectionFormat=
"of" derivedContent="3"/>. Additionally, <contact fullname="Xiaotao Wu"/>, <cont
act fullname="Paul Kyzivat"/>, <contact fullname="Jonathan Rosenberg"/>, <contac
t fullname="Miguel A. Garcia-Martin"/>, <contact fullname="Mary Barnes"/>, <cont
act fullname="Ben Campbell"/>, <contact fullname="Dave Morgan"/>, and <contact f
ullname="Oscar Novo"/> provided useful comments during the work with RFC 4582. T
he authors also acknowledge contributions to the revision of BFCP for use over a
n unreliable transport from <contact fullname="Geir Arne Sandbakken"/> who had t
he initial idea, <contact fullname="Alfred E. Heggestad"/>, <contact fullname="T
rond G. Andersen"/>, <contact fullname="Gonzalo Camarillo"/>, <contact fullname=
"Roni Even"/>, <contact fullname="Lorenzo Miniero"/>, <contact fullname="Jörg Ot
t"/>, <contact fullname="Eoin McLeod"/>, <contact fullname="Mark K. Thompson"/>,
<contact fullname="Hadriel Kaplan"/>, <contact fullname="Dan Wing"/>, <contact
fullname="Cullen Jennings"/>, <contact fullname="David Benham"/>, <contact fulln
ame="Nivedita Melinkeri"/>, <contact fullname="Woo Johnman"/>, <contact fullname
="Vijaya Mandava"/>, and <contact fullname="Alan Ford"/>. In the final phase, <c
ontact fullname="Ernst Horvath"/> did a thorough review, revealing issues that n
eeded clarification and changes. Useful and important final reviews were done by
<contact fullname="Mary Barnes"/>. <contact fullname="Paul Jones"/> helped tre
mendously as editor for changes addressing IESG review comments.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.d">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>gonzalo.camarillo@ericsson.com</email>
</address>
</author>
<author initials="K." surname="Drage" fullname="Keith Drage">
<address>
<postal>
</postal>
<email>drageke@ntlworld.com</email>
</address>
</author>
<author fullname="Tom Kristensen" initials="T." surname="Kristensen">
<organization abbrev="Jotron" showOnFrontPage="true">Jotron AS</organiza
tion>
<address>
<postal>
<street>Ringdalskogen 8</street>
<code>3270</code>
<city>Larvik</city>
<country>Norway</country>
</postal>
<email>tom.kristensen@jotron.com, tomkri@ifi.uio.no</email>
</address>
</author>
<author initials="J." surname="Ott" fullname="Jörg Ott">
<organization showOnFrontPage="true">Technical University Munich</organi
zation>
<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 showOnFrontPage="true">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>
</section>
</back>
</rfc> </rfc>
 End of changes. 92 change blocks. 
3173 lines changed or deleted 6538 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/