<?xmlversion="1.0" encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std"ipr="trust200902"consensus="true" docName="draft-ietf-bfcpbis-rfc4582bis-16"obsoletes="4582"> <?rfc strict="yes"?> <?rfc toc="yes"?> <?rfc tocdepth="4"?> <?rfc symrefs="no"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?>indexInclude="true" ipr="trust200902" number="8855" obsoletes="4582" prepTime="2021-01-17T13:06:20" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="false" tocDepth="4" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis-16" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc8855" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <title abbrev="BFCP">The Binary Floor Control Protocol (BFCP)</title> <seriesInfo name="RFC" value="8855" stream="IETF"/> <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo"><organization>Ericsson</organization><organization showOnFrontPage="true">Ericsson</organization> <address> <postal> <street>Hirsalantie 11</street><city>FI-02420 Jorvas</city><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"><organization>Alcatel-Lucent</organization><address> <postal><street>Quadrant, StoneHill Green, Westlea</street> <street>Swindon, Wilts</street> <country>UK</country></postal><email>drage@alcatel-lucent.com</email><email>drageke@ntlworld.com</email> </address> </author> <author fullname="Tom Kristensen" initials="T." surname="Kristensen"><organization>Cisco</organization><organization abbrev="Jotron" showOnFrontPage="true">Jotron AS</organization> <address> <postal><street>Philip Pedersens vei 1</street> <city>NO-1366 Lysaker</city><street>Ringdalskogen 8</street> <code>3270</code> <city>Larvik</city> <country>Norway</country> </postal><email>tomkrist@cisco.com,<email>tom.kristensen@jotron.com, tomkri@ifi.uio.no</email> </address> </author> <author initials="J." surname="Ott"fullname="Joergfullname="Jörg Ott"><organization>Aalto University</organization><organization showOnFrontPage="true">Technical University Munich</organization> <address> <postal><street>Otakaari 5 A</street> <city>FI-02150 Espoo</city> <country>Finland</country><street>Boltzmannstrasse 3</street> <code>85748</code> <city>Garching</city> <country>Germany</country> </postal><email>jo@comnet.tkk.fi</email><email>ott@in.tum.de</email> </address> </author> <author fullname="Charles Eckel" initials="C." surname="Eckel"><organization>Cisco</organization><organization showOnFrontPage="true">Cisco</organization> <address> <postal> <street>707 Tasman Drive</street><city>California, CA 95035</city><city>Milpitas</city> <region>California</region> <code>95035</code> <country>UnitedStates</country>States of America</country> </postal> <email>eckelcu@cisco.com</email> </address> </author><!-- Maximum 5 authors in current xml2rfc <author fullname="Paul E. Jones" initials="P.E." surname="Jones"> <organization>Cisco</organization> <address> <postal> <street>7025 Kit Creek Rd.</street> <city>Research Triangle Park, NC 27709</city> <country>USA</country> </postal> <email>paulej@packetizer.com</email> </address> </author> --> <date/><date month="01" year="2021"/> <area>Real-time Applications and Infrastructure</area> <workgroup>BFCPbis Working Group</workgroup> <keyword>floor control</keyword> <keyword>conference</keyword><abstract> <t>Floor<abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1">Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.</t><t>This<t indent="0" pn="section-abstract-2">This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.</t><t>This<t indent="0" pn="section-abstract-3">This document obsoletes RFC4582. Changes from RFC 4582 are summarized in Section 16.</t> <!-- Ensure correct section #, as xref is not allowed in abstract -->4582.</t> </abstract></front> <middle><boilerplate> <sectiontitle="Introduction" anchor="sec:intro"> <t>Withinanchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t indent="0" pn="section-boilerplate.1-2"> This document is aconference, some applications need to manageproduct of theaccess to a setInternet Engineering Task Force (IETF). It represents the consensus ofshared resources, such astheright to send media to a particular media session. Floor control enables such applications to provide users with coordinated (shared or exclusive) access to these resources.</t> <t>The RequirementsIETF community. It has received public review and has been approved forFloor Control Protocol <xref target="RFC4376"/> list a set of requirements that need to be metpublication byfloor control protocols. The Binary Floor Control Protocol (BFCP), whichthe Internet Engineering Steering Group (IESG). Further information on Internet Standards isspecifiedavailable in Section 2 of RFC 7841. </t> <t indent="0" pn="section-boilerplate.1-3"> Information about the current status of this document,meets these requirements.</t> <t>In addition, BFCP has been designed so thatany errata, and how to provide feedback on itcanmay beused in low-bandwidth environments. The binary encoding used by BFCP achieves a small message size (when message signatures are not used) that keepsobtained at <eref target="https://www.rfc-editor.org/info/rfc8855" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t indent="0" pn="section-boilerplate.2-1"> Copyright (c) 2021 IETF Trust and thetime it takes to transmit delay-sensitive BFCP messagespersons identified as the document authors. All rights reserved. </t> <t indent="0" pn="section-boilerplate.2-2"> This document is subject toa minimum. Delay-sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus,BCP 78 andChairAction. It is expected that future extensionsthe IETF Trust's Legal Provisions Relating tothese messages will not increaseIETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on thesizedate ofthese messages in a significant way.</t> <t>The remainderpublication of thisdocument is organizeddocument. Please review these documents carefully, asfollows: <xref target="sec:terminology"/> defines the terminology used throughoutthey describe your rights and restrictions with respect to thisdocument, <xref target="sec:scope"/> discusses the scopedocument. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e ofBFCP (i.e., which tasks fall withinthescope of BFCPTrust Legal Provisions andwhich onesareperformed using different mechanisms), <xref target="sec:overview"/> provides a non-normative overview of BFCP operation, and subsequent sections provideprovided without warranty as described in thenormative specification of BFCP.</t>Simplified BSD License. </t> </section> </boilerplate> <toc> <sectiontitle="Terminology" anchor="sec:terminology"> <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document areanchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t> </li> <li pn="section-toc.1-1.3"> <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-scope">Scope</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2"> <li pn="section-toc.1-1.3.2.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-creation">Floor Creation</xref></t> </li> <li pn="section-toc.1-1.3.2.2"> <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-obtaining-information-to-co">Obtaining Information tobe interpreted as described in BCP 14, <xref target="RFC2119">RFC 2119</xref> and indicate requirement levels for compliant implementations.</t> <t>Media Participant: An entity that has accessContact a Floor Control Server</xref></t> </li> <li pn="section-toc.1-1.3.2.3"> <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-obtaining-floor-resource-as">Obtaining Floor-Resource Associations</xref></t> </li> <li pn="section-toc.1-1.3.2.4"> <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-privileges-of-floor-control">Privileges of Floor Control</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.4"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-overview-of-operation">Overview of Operation</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2"> <li pn="section-toc.1-1.4.2.1"> <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-participant-to-floor-">Floor Participant tothe media resourcesFloor Control Server Interface</xref></t> </li> <li pn="section-toc.1-1.4.2.2"> <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-chair-to-floor-contro">Floor Chair to Floor Control Server Interface</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.5"> <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-format">Packet Format</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-attribute-format">Attribute Format</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-beneficiary-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 derivedContent="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 derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-request-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 derivedContent="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 derivedContent="5.2.5" format="counter" sectionFormat="of" target="section-5.2.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-request-status">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 derivedContent="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="name-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 derivedContent="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 derivedContent="5.2.8" format="counter" sectionFormat="of" target="section-5.2.8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-participant-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 derivedContent="5.2.9" format="counter" sectionFormat="of" target="section-5.2.9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-status-info">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 derivedContent="5.2.10" format="counter" sectionFormat="of" target="section-5.2.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-supported-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 derivedContent="5.2.11" format="counter" sectionFormat="of" target="section-5.2.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-supported-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 derivedContent="5.2.12" format="counter" sectionFormat="of" target="section-5.2.12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-user-display-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 derivedContent="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 derivedContent="5.2.14" format="counter" sectionFormat="of" target="section-5.2.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-beneficiary-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 derivedContent="5.2.15" format="counter" sectionFormat="of" target="section-5.2.15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-request-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 derivedContent="5.2.16" format="counter" sectionFormat="of" target="section-5.2.16"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requested-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 derivedContent="5.2.17" format="counter" sectionFormat="of" target="section-5.2.17"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-request-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 derivedContent="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 derivedContent="" format="title" sectionFormat="of" target="name-message-format">Message Format</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floorrequest">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 derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floorrelease">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 derivedContent="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floorrequestquery">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 derivedContent="5.3.4" format="counter" sectionFormat="of" target="section-5.3.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floorrequeststatus">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 derivedContent="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 derivedContent="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 derivedContent="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 derivedContent="5.3.8" format="counter" sectionFormat="of" target="section-5.3.8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floorstatus">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 derivedContent="5.3.9" format="counter" sectionFormat="of" target="section-5.3.9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-chairaction">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 derivedContent="5.3.10" format="counter" sectionFormat="of" target="section-5.3.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-chairactionack">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 derivedContent="5.3.11" format="counter" sectionFormat="of" target="section-5.3.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-hello">Hello</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 derivedContent="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 derivedContent="5.3.13" format="counter" sectionFormat="of" target="section-5.3.13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-error">Error</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 derivedContent="5.3.14" format="counter" sectionFormat="of" target="section-5.3.14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floorrequeststatusack">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 derivedContent="5.3.15" format="counter" sectionFormat="of" target="section-5.3.15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floorstatusack">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 derivedContent="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 derivedContent="5.3.17" format="counter" sectionFormat="of" target="section-5.3.17"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-goodbyeack">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" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-transport">Transport</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-reliable-transport">Reliable 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 derivedContent="" format="title" sectionFormat="of" target="name-unreliable-transport">Unreliable Transport</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="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 derivedContent="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 derivedContent="6.2.3" format="counter" sectionFormat="of" target="section-6.2.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-fragmentation-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 derivedContent="6.2.4" format="counter" sectionFormat="of" target="section-6.2.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-nat-traversal">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" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="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" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-transactions">Protocol Transactions</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-client-behavior">Client 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 derivedContent="" format="title" sectionFormat="of" target="name-server-behavior">Server 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 derivedContent="" format="title" sectionFormat="of" target="name-timers">Timers</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="8.3.1" format="counter" sectionFormat="of" target="section-8.3.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-request-retransmission-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 derivedContent="8.3.2" format="counter" sectionFormat="of" target="section-8.3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-response-retransmission-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 derivedContent="8.3.3" format="counter" sectionFormat="of" target="section-8.3.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-timer-values">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" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication-and-authoriz">Authentication and Authorization</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-participant-operation">Floor Participant Operations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2"> <li pn="section-toc.1-1.10.2.1"> <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requesting-a-floor">Requesting a Floor</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="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 derivedContent="10.1.2" format="counter" sectionFormat="of" target="section-10.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-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 derivedContent="10.1.3" format="counter" sectionFormat="of" target="section-10.1.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-subsequent-f">Reception of aconference (e.g., it can receiveSubsequent 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 derivedContent="" format="title" sectionFormat="of" target="name-cancelling-a-floor-request-">Cancelling amedia stream). In floor-controlled conferences,Floor Request and Releasing agiven media participant is typically colocated withFloor</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="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 afloor participant, but it does not need to be. Third-party floor requests consist of havingFloorRelease 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 derivedContent="10.2.2" format="counter" sectionFormat="of" target="section-10.2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-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" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-chair-operations">Chair Operations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2"> <li pn="section-toc.1-1.11.2.1"> <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sending-a-chairaction-messa">Sending afloor participant requestChairAction 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 derivedContent="" format="title" sectionFormat="of" target="name-receiving-a-response-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" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-general-client-operations">General Client Operations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-requesting-information-abou">Requesting Information about Floors</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="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 afloor forFloorQuery 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 derivedContent="12.1.2" format="counter" sectionFormat="of" target="section-12.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-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 derivedContent="12.1.3" format="counter" sectionFormat="of" target="section-12.1.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-subsequent-fl">Reception of amedia participant when they are not colocated. The protocol betweenSubsequent 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 derivedContent="" format="title" sectionFormat="of" target="name-requesting-information-about">Requesting Information about Floor Requests</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="12.2.1" format="counter" sectionFormat="of" target="section-12.2.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-sending-a-floorrequestquery">Sending afloor participant andFloorRequestQuery 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 derivedContent="12.2.2" format="counter" sectionFormat="of" target="section-12.2.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-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 derivedContent="" format="title" sectionFormat="of" target="name-requesting-information-about-">Requesting Information about amedia participant (that are not colocated) is outsideUser</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="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 derivedContent="12.3.2" format="counter" sectionFormat="of" target="section-12.3.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-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 derivedContent="" format="title" sectionFormat="of" target="name-obtaining-the-capabilities-">Obtaining thescopeCapabilities ofthis document.</t> <t>Client: A floor participant or a floor chair that communicates withafloor control server using BFCP.</t> <t>Floor: A temporary permission to access or manipulateFloor Control Server</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="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 aspecific shared resource or setHello 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 derivedContent="12.4.2" format="counter" sectionFormat="of" target="section-12.4.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-receiving-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" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-floor-control-server-operat">Floor Control Server Operations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-floorrequest">Reception ofresources.</t> <t>Floor Chair: A logical entity that manages one floor (grants, denies, or revokesafloor). An entity that assumesFloorRequest Message</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="13.1.1" format="counter" sectionFormat="of" target="section-13.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-the-first-floorr">Generating thelogical role ofFirst 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 derivedContent="13.1.2" format="counter" sectionFormat="of" target="section-13.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-generation-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 derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-floorrequestq">Reception of afloor chair forFloorRequestQuery 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 derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-userquery-me">Reception of agiven transaction may assumeUserQuery 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 derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-floorrelease">Reception of adifferent role (e.g., floor participant) forFloorRelease 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 derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-floorquery-m">Reception of adifferent transaction. The rolesFloorQuery Message</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="13.5.1" format="counter" sectionFormat="of" target="section-13.5.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-generation-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 derivedContent="13.5.2" format="counter" sectionFormat="of" target="section-13.5.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-generation-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 derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-chairaction-">Reception offloor chair and floor participant are defined onatransaction-by-transaction basis.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 derivedContent="" format="title" sectionFormat="of" target="name-reception-of-a-hello-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 derivedContent="" format="title" sectionFormat="of" target="name-error-message-generation">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" format="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> </li> <li pn="section-toc.1-1.15"> <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" format="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.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 derivedContent="" format="title" sectionFormat="of" target="name-attributes-subregistry">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 derivedContent="" format="title" sectionFormat="of" target="name-primitives-subregistry">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 derivedContent="" format="title" sectionFormat="of" target="name-request-statuses-subregistr">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 derivedContent="" format="title" sectionFormat="of" target="name-error-codes-subregistry">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" format="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-changes-from-rfc-4582">Changes from RFC 4582</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-extensions-for-an-unreliabl">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 derivedContent="" format="title" sectionFormat="of" target="name-other-changes">Other 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" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-normative-references">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 derivedContent="" format="title" sectionFormat="of" target="name-informative-references">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="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-call-flows-for-bfcp">Example Call Flows for BFCPtransactions are defined in <xref target="sec:transactions"/>.</t> <t>Floor Control: A mechanism that enablesover 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="Appendix 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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-motivation">Motivation</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="B.1.1" format="counter" sectionFormat="of" target="section-b.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-alternatives-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"><xref derivedContent="B.1.1.1" format="counter" sectionFormat="of" target="section-b.1.1.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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"><xref derivedContent="B.1.1.2" format="counter" sectionFormat="of" target="section-b.1.1.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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"><xref derivedContent="B.1.1.3" format="counter" sectionFormat="of" target="section-b.1.1.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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"><xref derivedContent="B.1.1.4" format="counter" sectionFormat="of" target="section-b.1.1.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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"><xref derivedContent="B.1.1.5" format="counter" sectionFormat="of" target="section-b.1.1.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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"><xref derivedContent="B.1.1.6" format="counter" sectionFormat="of" target="section-b.1.1.6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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"><xref derivedContent="B.1.1.7" format="counter" sectionFormat="of" target="section-b.1.1.7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-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="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t> </li> <li pn="section-toc.1-1.21"> <t indent="0" pn="section-toc.1-1.21.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</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 applicationsor usersneed togain safe and mutually exclusive or non-exclusive inputmanage the access tothe shared object or resource.</t> <t>Floor Control Server: A logical entity that maintains the statea set of shared resources, such as thefloor(s), including which floors exists, who the floor chairs are, who holdsright to send media to afloor, etc. Requestsparticular media session. Floor control enables such applications tomanipulateprovide 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 afloor are directed at theset of requirements that need to be met by floor controlserver.protocols. Thefloor control server of a conference may perform other logical roles (e.g., floor participant)Binary Floor Control Protocol (BFCP), which is specified inanother conference.</t> <t>Floor Participant: A logical entitythis document, meets these requirements.</t> <t indent="0" pn="section-1-3">In addition, BFCP has been designed so thatrequests floors, and possibly information about them, fromit can be used in low-bandwidth environments. The binary encoding used by BFCP achieves afloor control server. An entitysmall message size (when message signatures are not used) thatassumeskeeps thelogical role of a floor participant for a given transaction may assume a different role (e.g.,time it takes to transmit delay-sensitive BFCP messages to afloor chair) forminimum. Delay-sensitive BFCP messages include FloorRequest, FloorRelease, FloorRequestStatus, and ChairAction. It is expected that future extensions to these messages will not increase the size of these messages in adifferent transaction. The rolessignificant way.</t> <t indent="0" pn="section-1-4">The remainder offloor participantthis 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" sectionFormat="of" derivedContent="Section 3"/> discusses the scope of BFCP (i.e., which tasks fall within the scope of BFCP andfloor chairwhich ones aredefined onperformed using different mechanisms), <xref target="sec_overview" format="default" sectionFormat="of" derivedContent="Section 4"/> provides atransaction-by-transaction basis.non-normative overview of BFCPtransactionsoperation. The subsequent sections provide the normative specification of BFCP. <xref target="sec_changes" format="default" sectionFormat="of" derivedContent="Section 16"/> summarizes changes from <xref target="RFC4582" format="default" sectionFormat="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>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document aredefinedto be interpreted as described in BCP 14 <xreftarget="sec:transactions"/>.target="RFC2119" format="default" sectionFormat="of" derivedContent="1"/> <xref target="RFC8174" format="default" sectionFormat="of" 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 conferences, a givenfloormedia participant is typicallycolocatedco-located with amediafloor participant, but it does not need to be. Third-party floor requests consist of having a floor participant request a floor for a media participant when they are notcolocated.</t> <t>Participant: An entity that acts asco-located. The protocol between a floorparticipant, asparticipant and a mediaparticipant, or as both.</t> <t>BFCP Connection: A transport association between BFCP entities, used to exchange BFCP messages.</t> <t>Transaction Failure Window: When communicating over an unreliable transport, thisparticipant (that are not co-located) issome periodoutside the scope oftime less than or equal to T1*2^4 (see <xref target="timers"/>). For reliable transports,thisperiod of time is unbounded.</t> </section> <section title="Scope" anchor="sec:scope"> <t>As stated earlier, BFCP isdocument.</dd> <dt pn="section-2-2.3">Client:</dt> <dd pn="section-2-2.4">A floor participant or aprotocolfloor chair that communicates 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 tocoordinateaccesstoor manipulate a specific sharedresources inresource 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 aconference following the requirements defined in <xref target="RFC4376"/>. Floor control complements other functions defined infloor). An entity that assumes theXCON conferencing framework <xref target="RFC5239"/>. Thelogical role of a floorcontrol protocol BFCP defined in this document only specifieschair for ameans to arbitrate access to floors. The rules and constraintsgiven transaction may assume a different role (e.g., floor participant) for a different transaction. The roles of floorarbitrationchair andthe results offloorassignmentsparticipant areoutside the scope of this document anddefined on a transaction-by-transaction basis. BFCP transactions are definedby other protocolsin <xreftarget="RFC5239"/>.</t> <t><xref target="fig:arch"/> shows the taskstarget="sec_transactions" format="default" sectionFormat="of" derivedContent="Section 8"/>.</dd> <dt pn="section-2-2.9">Floor Control:</dt> <dd pn="section-2-2.10">A mechanism thatBFCP can perform.</t> <t><figure anchor="fig:arch" title="Functionality provided by BFCP"> <artwork><![CDATA[ +---------+ | Floor | | Chair | | | +---------+ ^ | | | Notification | | Decision | | | | Floor | v +-------------+ Request +---------+ +-------------+ | Floor |----------->| Floor | Notification | Floor | | Participant | | Control |------------->| Participant | | |<-----------| Server | | | +-------------+ Grantedenables applications or+---------+ +-------------+ Denied ]]></artwork> </figure></t> <t>BFCP provides a means:</t> <t><list style="symbols"> <t>for floor participants to send floor requests to floor control servers.</t> <t>for floor control serversusers tograntgain safe and mutually exclusive ordeny requests tonon-exclusive input accessa given resource from floor participants.</t> <t>forto the shared object 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 tosend floor control servers decisions regardingmanipulate a floorrequests.</t> <t>forare directed at the floor controlservers to keep floor participants andserver. The floorchairs informed about the statuscontrol server of agivenconference may perform other logical roles (e.g., floororparticipant) 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 possibly information about them, from agivenfloorrequest.</t> </list></t> <t>Even though taskscontrol server. An entity thatdo not belong to the previous list are outsideassumes thescopelogical role ofBFCP, somea floor participant for a given transaction may assume a different role (e.g., a floor chair) for a different transaction. The roles ofthese out-of-scope tasks relate tofloorcontrolparticipant and floor chair areessential for creating floors and establishingdefined on a transaction-by-transaction basis. BFCPconnections between different entities.transactions are defined in <xref target="sec_transactions" format="default" sectionFormat="of" derivedContent="Section 8"/>. Inthe following subsections, we discuss some of these tasks and mechanisms to perform them.</t> <section title="Floor Creation" anchor="sec:scope:creation"> <t>The association offloor-controlled conferences, a given floor participant is typically co-located with aresource or a setmedia participant, but it does not need to be. Third-party floor requests consist ofresources (e.g.,having a floor participant request a floor for a mediastreams)participant when they are not co-located.</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, used 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 isoutsome period ofthe scopetime 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, BFCPas describedis a protocol to coordinate access to shared resources in a conference following the requirements defined in <xreftarget="RFC5239"/>.target="RFC4376" format="default" sectionFormat="of" derivedContent="18"/>. Floorcreation and termination are also outside the scope of BFCP; these aspects are handled usingcontrol complements other functions defined in theconferenceCentralized Conferencing (XCON) Framework <xref target="RFC5239" format="default" sectionFormat="of" derivedContent="19"/>. The floor control protocolfor manipulating the conference object. Consequently, the floor control server needs to stay upBFCP defined in this document only specifies a means todate on changesarbitrate access tothe conference object (e.g., when a newfloors. The rules and constraints for flooris created).</t> <t>Conference control clients using CCMP <xref target="RFC6503"/> can specify such floor-related settings inarbitration and the<floor-information> element <xref target="RFC6501"/>results of floor assignments are outside theto-be created conference object provided in the bodyscope ofa CCMP confRequest/create message issued tothis document and are defined by other protocols <xref target="RFC5239" format="default" sectionFormat="of" derivedContent="19"/>.</t> <t indent="0" pn="section-3-2"><xref target="fig_arch" format="default" sectionFormat="of" derivedContent="Figure 1"/> shows theconference control server.</t> </section> <section title="Obtaining Information to Contact atasks that BFCP can perform.</t> <figure anchor="fig_arch" align="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-functionality-provided-by-b">Functionality provided by BFCP</name> <artwork name="" type="" align="left" alt="" pn="section-3-3.1"> +---------+ | Floor | | Chair | | | +---------+ ^ | | | Notification | | Decision | | | | Floor | v +-------------+ Request +---------+ +-------------+ | Floor |----------->| Floor | Notification | Floor | | Participant | | ControlServer" anchor="sec:scope:info"> <t>A client needs|------------->| Participant | | |<-----------| Server | | | +-------------+ Granted or +---------+ +-------------+ Denied </artwork> </figure> <t indent="0" pn="section-3-4">BFCP provides aset of data in ordermeans:</t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-5"> <li pn="section-3-5.1">for floor participants toestablish a BFCP connectionsend floor requests toafloor controlserver. This data includes the transport address of the server, the conference identifier, and a user identifier.</t> <t>Clients can obtain this information in different ways. One isservers.</li> <li pn="section-3-5.2">for floor control servers touse an SDP offer/answer <xref target="RFC3264"/> exchange, which is described in <xref target="I-D.ietf-bfcpbis-rfc4583bis"/>. Howgrant or deny requests toestablishaccess aconnectiongiven resource from floor participants.</li> <li pn="section-3-5.3">for floor chairs toa BFCPsend floor controlserver outsideservers decisions regarding floor requests.</li> <li pn="section-3-5.4">for floor control servers to keep floor participants and floor chairs informed about thecontextstatus of a given floor or a given floor request.</li> </ul> <t indent="0" pn="section-3-6">Even though tasks that do not belong to the previous list are outside the scope of BFCP, some of these out-of-scope tasks relate to floor control and are essential for creating floors and establishing BFCP connections between different entities. In the following subsections, we discuss some of these tasks and mechanisms to perform them.</t> <section anchor="sec_scope_creation" numbered="true" toc="include" removeInRFC="false" pn="section-3.1"> <name slugifiedName="name-floor-creation">Floor Creation</name> <t indent="0" pn="section-3.1-1">The association of a given floor with a resource or a set of resources (e.g., media streams) is out of the scope of BFCP as described in <xref target="RFC5239" format="default" sectionFormat="of" derivedContent="19"/>. Floor creation and termination are also outside the scope of BFCP; these aspects are handled using the conference control protocol for manipulating the conference object. Consequently, the floor control server needs to stay up to date on changes to the conference object (e.g., when a new floor is created).</t> <t indent="0" pn="section-3.1-2">Conference control clients using Centralized Conferencing Manipulation Protocol (CCMP) <xref target="RFC6503" format="default" sectionFormat="of" derivedContent="23"/> can specify such floor-related settings in the <floor-information> element <xref target="RFC6501" format="default" sectionFormat="of" derivedContent="22"/> of the to-be created conference object provided in the body of a CCMP confRequest/create message issued to the conference control server.</t> </section> <section anchor="sec_scope_info" numbered="true" toc="include" removeInRFC="false" pn="section-3.2"> <name slugifiedName="name-obtaining-information-to-co">Obtaining Information to Contact a Floor Control Server</name> <t indent="0" pn="section-3.2-1">A client needs a set of data in order to establish a BFCP connection to a floor control server. These data include the transport address of the server, the conference identifier, and a user identifier.</t> <t indent="0" pn="section-3.2-2">Clients can obtain this information in different ways. One is to use a Session Description Protocol (SDP) offer/answer <xref target="RFC3264" format="default" sectionFormat="of" derivedContent="17"/> exchange, which is described in <xref target="RFC8856" format="default" sectionFormat="of" derivedContent="12"/>. How to establish a connection to a BFCP floor control server is outside the context of an offer/answer exchange when using a reliable transport is described in <xreftarget="RFC5018"/>.target="RFC5018" format="default" sectionFormat="of" derivedContent="4"/>. Other mechanisms are described in the XCONframeworkFramework <xreftarget="RFC5239"/>target="RFC5239" format="default" sectionFormat="of" derivedContent="19"/> (and other related documents). For unreliable transports, the use of an SDP offer/answer exchange is the only specified mechanism.</t> </section> <sectiontitle="Obtaininganchor="sec_scope_associations" numbered="true" toc="include" removeInRFC="false" pn="section-3.3"> <name slugifiedName="name-obtaining-floor-resource-as">Obtaining Floor-ResourceAssociations" anchor="sec:scope:associations"> <t>FloorsAssociations</name> <t indent="0" pn="section-3.3-1">Floors are associated with resources. For example, a floor that controls who talks at a given time has a particular audio session as its associated resource. Associations between floors and resources are part of the conference object.</t><t>Floor<t indent="0" pn="section-3.3-2">Floor participants and floor chairs need to know which resources are associated with which floors. They can obtain this information by using different mechanisms, such as an SDP offer/answer <xreftarget="RFC3264"/>target="RFC3264" format="default" sectionFormat="of" derivedContent="17"/> exchange. How to use an SDP offer/answer exchange to obtain these associations is described in <xreftarget="I-D.ietf-bfcpbis-rfc4583bis"/>.</t> <t><list style="hanging"> <t>Notetarget="RFC8856" format="default" sectionFormat="of" derivedContent="12"/>.</t> <aside pn="section-3.3-3"> <t indent="0" pn="section-3.3-3.1">Note that floor participants perform SDP offer/answer exchanges with the conference focus of the conference. So, the conference focus needs to obtain information about associations between floors and resources in order to be able to provide this information to a floor participant in an SDP offer/answer exchange.</t></list></t> <t>Other</aside> <t indent="0" pn="section-3.3-4">Other mechanisms for obtaining this information, including discussion of how the information is made available to a (SIP)Focus,focus, are described in the XCONframeworkFramework <xreftarget="RFC5239"/>target="RFC5239" format="default" sectionFormat="of" derivedContent="19"/> (and other related documents). According to the conferencing system policies, conference control clients using CCMP <xreftarget="RFC6503"/>target="RFC6503" format="default" sectionFormat="of" derivedContent="23"/> can modify the floor settings of a conference by issuing CCMP confRequest/update messages providing the specific updates to the <floor-information> element of the target conference object. More information about CCMP and BFCP interaction can be found in <xreftarget="RFC6504"/>.</t> </section> <section title="Privileges of Floor Control" anchor="sec:scope:policy"> <t>Atarget="RFC6504" format="default" sectionFormat="of" derivedContent="24"/>.</t> </section> <section anchor="sec_scope_policy" numbered="true" toc="include" removeInRFC="false" pn="section-3.4"> <name slugifiedName="name-privileges-of-floor-control">Privileges of Floor Control</name> <t indent="0" pn="section-3.4-1">A participant whose floor request is granted has the right to use the resource or resources associated with the floor that was requested. For example, the participant may have the right to send media over a particular audio stream.</t><t>Nevertheless,<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 time, even if they do not have the right to do so. Determination of which media participants can actually use the resources in the conference is discussed in the XCON Framework <xreftarget="RFC5239"/>.</t>target="RFC5239" format="default" sectionFormat="of" derivedContent="19"/>.</t> </section> </section> <sectiontitle="Overview of Operation" anchor="sec:overview"> <t>Thisanchor="sec_overview" numbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-overview-of-operation">Overview of Operation</name> <t indent="0" pn="section-4-1">This section provides a non-normative description of BFCP operations. <xreftarget="sec:overview:user"/>target="sec_overview_user" format="default" sectionFormat="of" derivedContent="Section 4.1"/> describes the interface between floor participants and floor control servers, and <xreftarget="sec:overview:chair"/>target="sec_overview_chair" format="default" sectionFormat="of" derivedContent="Section 4.2"/> describes the interface between floor chairs and floor control servers.</t><t>BFCP<t indent="0" pn="section-4-2">BFCP messages, which use a TLV (Type-Length-Value) binary encoding, consist of acommon headerCOMMON-HEADER followed by a set of attributes. Thecommon headerCOMMON-HEADER contains, among other information, a 32-bit conference identifier. Floor participants, media participants, and floor chairs are identified by 16-bit user identifiers.</t><t>BFCP<t indent="0" pn="section-4-3">BFCP supports nested attributes (i.e., attributes that contain attributes). These are referred to as grouped attributes.</t><t>There<t indent="0" pn="section-4-4">There are two types of transactions in BFCP: client-initiated transactions and server-initiated transactions. <xreftarget="sec:transactions"/>target="sec_transactions" format="default" sectionFormat="of" derivedContent="Section 8"/> describes both types of transactions in detail.</t> <sectiontitle="Flooranchor="sec_overview_user" numbered="true" toc="include" removeInRFC="false" pn="section-4.1"> <name slugifiedName="name-floor-participant-to-floor-">Floor Participant to Floor Control ServerInterface" anchor="sec:overview:user"> <t>FloorInterface</name> <t indent="0" pn="section-4.1-1">Floor participants request a floor by sending a FloorRequest message to the floor control server. BFCP supports third-party floor requests. That is, the floor participant sending the floor request need not becolocatedco-located with the media participant that will get the floor once the floor request is granted. FloorRequest messages carry the identity of the requester in the User ID field of thecommon header,COMMON-HEADER, and the identity of the beneficiary of the floor (in third-party floor requests) in a BENEFICIARY-ID attribute.</t><t><list style="hanging"> <t>Third-party<aside pn="section-4.1-2"> <t indent="0" pn="section-4.1-2.1">Third-party floor requests can be sent, for example, by floor participants that have a BFCP connection to the floor control server but that are not media participants (i.e., they do not handle any media).</t></list></t> <t>FloorRequest</aside> <t indent="0" pn="section-4.1-3">FloorRequest messages identify the floor or floors being requested by carrying their 16-bit floor identifiers in FLOOR-ID attributes. If a FloorRequest message carries more than one floor identifier, the floor control server treats all the floor requests as an atomic package. That is, the floor control server either grants or denies all the floors in the FloorRequest message.</t><t>Floor<t indent="0" pn="section-4.1-4">Floor control servers respond to FloorRequest messages with FloorRequestStatus messages, which provide information about the status of the floor request. The first FloorRequestStatus message is the response to the FloorRequest message from the client, and therefore has the same Transaction ID as the FloorRequest.</t><t>Additionally,<t indent="0" pn="section-4.1-5">Additionally, the first FloorRequestStatus message carries the Floor Request ID in a FLOOR-REQUEST-INFORMATION attribute. Subsequent FloorRequestStatus messages related to the same floor request will carry the same Floor Request ID. This way, the floor participant can associate them with the appropriate floor request.</t><t>Messages<t indent="0" pn="section-4.1-6">Messages from the floor participant related to a particular floor request also use the same Floor Request ID as the first FloorRequestStatusMessagemessage from the floor control server.</t><t>Figures 2<t indent="0" pn="section-4.1-7"><xref target="fig_flow1" format="default" sectionFormat="of" derivedContent="Figure 2"/> and3 below<xref target="fig_flow2" format="default" sectionFormat="of" derivedContent="Figure 3"/> show examples of call flows where BFCP is used over a reliable transport. <xreftarget="app:unrelcallflow"/>target="app_unrelcallflow" format="default" sectionFormat="of" derivedContent="Appendix A"/> shows the same call flow examples using an unreliable transport.</t><t><xref target="fig:flow1"/><t indent="0" pn="section-4.1-8"><xref target="fig_flow1" format="default" sectionFormat="of" derivedContent="Figure 2"/> shows how a floor participant requests a floor, obtains it, and, at a later time, releases it. This figure illustrates the use, among other things, of the Transaction ID and the FLOOR-REQUEST-ID attribute.</t><t><figure anchor="fig:flow1" title="Requesting<figure anchor="fig_flow1" align="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-requesting-and-releasing-a-">Requesting and releasing afloor"> <artwork> <![CDATA[floor</name> <artwork name="" type="" align="left" alt="" pn="section-4.1-9.1"> Floor Participant Floor Control Server |(1) FloorRequest | |Transaction ID: 123 | |User ID: 234 | |FLOOR-ID: 543 ||---------------------------------------------->||---------------------------------------------->| | | |(2) FloorRequestStatus | |Transaction ID: 123 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Pending | | FLOOR-REQUEST-STATUS | | Floor ID: 543 ||<----------------------------------------------||<----------------------------------------------| | | |(3) FloorRequestStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 ||<----------------------------------------------||<----------------------------------------------| | | |(4) FloorRequestStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 ||<----------------------------------------------||<----------------------------------------------| | | |(5) FloorRelease | |Transaction ID: 154 | |User ID: 234 | |FLOOR-REQUEST-ID: 789 ||---------------------------------------------->||---------------------------------------------->| | | |(6) FloorRequestStatus | |Transaction ID: 154 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Released | | FLOOR-REQUEST-STATUS | | Floor ID: 543 ||<----------------------------------------------| ]]> </artwork> </figure></t> <t><xref target="fig:flow2"/>|<----------------------------------------------|</artwork> </figure> <t indent="0" pn="section-4.1-10"><xref target="fig_flow2" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows how a floor participant requests to be informed on the status of a floor. The first FloorStatus message from the floor control server is the response to the FloorQuery message and, as such, has the same Transaction ID as the FloorQuery message.</t><t>Subsequent<t indent="0" pn="section-4.1-11">Subsequent FloorStatus messages consist of server-initiated transactions, and therefore their Transaction ID is 0 given this example uses a reliable transport. FloorStatus message (2) indicates that there are currently two floor requests for the floor whose Floor ID is 543. FloorStatus message (3) indicates that the floor requests with Floor Request ID 764 has been granted, and the floor request with Floor Request ID 635 is the first in the queue. FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has been granted.</t><t><figure anchor="fig:flow2" title="Obtaining<figure anchor="fig_flow2" align="left" suppress-title="false" pn="figure-3"> <name slugifiedName="name-obtaining-status-informatio">Obtaining status information about afloor"> <artwork> <![CDATA[floor</name> <artwork name="" type="" align="left" alt="" pn="section-4.1-12.1"> Floor Participant Floor Control Server |(1) FloorQuery | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID: 543 ||---------------------------------------------->||---------------------------------------------->| | | |(2) FloorStatus | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 2nd | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 ||<----------------------------------------------||<----------------------------------------------| | | |(3) FloorStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 ||<----------------------------------------------||<----------------------------------------------| | | |(4) FloorStatus | |Transaction ID: 0 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 ||<----------------------------------------------| ]]> </artwork> </figure></t> <t>FloorStatus|<----------------------------------------------|</artwork> </figure> <t indent="0" pn="section-4.1-13">FloorStatus messages contain information about the floor requests they carry. For example, FloorStatus message (4) indicates that the floor request with Floor Request ID 635 has as the beneficiary (i.e., the participant that holds the floor when a particular floor request is granted) the participant whose User ID is 154. The floor request applies only to the floor whose Floor ID is 543. That is, this is not a multi-floor floor request.</t><t><list style="hanging"> <t>A<aside pn="section-4.1-14"> <t indent="0" pn="section-4.1-14.1">A multi-floor floor request applies to more than one floor (e.g., a participant wants to be able to speak and write on the whiteboard at the same time). The floor control server treats a multi-floor floor request as an atomic package. That is, the floor control server either grants the request for all floors or denies the request for all floors.</t></list></t></aside> </section> <sectiontitle="Flooranchor="sec_overview_chair" numbered="true" toc="include" removeInRFC="false" pn="section-4.2"> <name slugifiedName="name-floor-chair-to-floor-contro">Floor Chair to Floor Control ServerInterface" anchor="sec:overview:chair"> <t><xref target="fig:flow3"/>Interface</name> <t indent="0" pn="section-4.2-1"><xref target="fig_flow3" format="default" sectionFormat="of" derivedContent="Figure 4"/> shows a floor chair instructing a floor control server to grant a floor.</t><t><list style="empty"> <t>Note,<aside pn="section-4.2-2"> <t indent="0" pn="section-4.2-2.1">Note, however, that although the floor control server needs to take into consideration the instructions received in ChairAction messages (e.g., granting a floor), it does not necessarily need to perform them exactly 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></list></t> <t>For</aside> <t indent="0" pn="section-4.2-3">For example, a floor chair may send a ChairAction message granting a floor that was requested as part of an atomic floor request operation that involved several floors. Even if the chair responsible for one of the floors instructs the floor control server to grant the floor, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well. In another example, a floor chair may instruct the floor control server to grant a floor to a participant. The floor control server needs to revoke the floor from its current holder before granting it to the new participant.</t><t>So,<t indent="0" pn="section-4.2-4">So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state.</t><t><figure anchor="fig:flow3" title="Chair<figure anchor="fig_flow3" align="left" suppress-title="false" pn="figure-4"> <name slugifiedName="name-chair-instructing-the-floor">Chair instructing the floor controlserver"> <artwork> <![CDATA[server</name> <artwork name="" type="" align="left" alt="" pn="section-4.2-5.1"> Floor Chair Floor Control Server |(1) ChairAction | |Transaction ID: 769 | |User ID: 357 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | Request Status: Granted ||---------------------------------------------->||---------------------------------------------->| | | |(2) ChairActionAck | |Transaction ID: 769 | |User ID: 357 ||<----------------------------------------------| ]]> </artwork> </figure></t>|<----------------------------------------------|</artwork> </figure> </section> </section> <sectiontitle="Packet Format" anchor="sec:format"> <t>BFCPanchor="sec_format" numbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-packet-format">Packet Format</name> <t indent="0" pn="section-5-1">BFCP packets consist of a 12-octetcommon headerCOMMON-HEADER followed by attributes. All the protocol valuesMUST<bcp14>MUST</bcp14> be sent in network byte order.</t> <sectiontitle="COMMON-HEADER Format" anchor="sec:format:common"> <t>Theanchor="sec_format_common" numbered="true" toc="include" removeInRFC="false" pn="section-5.1"> <name slugifiedName="name-common-header-format">COMMON-HEADER Format</name> <t indent="0" pn="section-5.1-1">The following is the format of thecommon header.</t> <t><figure title="COMMON-HEADER format" anchor="fig:common"> <artwork><![CDATA[COMMON-HEADER.</t> <figure anchor="fig_common" align="left" suppress-title="false" pn="figure-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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Conference ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transaction ID | User ID |+>+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Fragment Offset (if F is set) | Fragment Length (if F is set) |+>+> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---- These fragment fields are never present when using reliabletransports ]]> </artwork> </figure></t> <t>Ver: Thistransports</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.1-3"> <dt pn="section-5.1-3.1">Ver:</dt> <dd pn="section-5.1-3.2">This 3-bit field defines the version of BFCPthatto which this messageadheres to.adheres. This specification defines two versions: 1 and 2. The version fieldMUST<bcp14>MUST</bcp14> be set to 1 when using BFCP over a reliable transport. The version fieldMUST<bcp14>MUST</bcp14> be set to 2 when using BFCP over an unreliable transport. If a floor control server receives a message with an unsupported version field value or a message with a version number that is not permitted with the transport over which it was received, the serverMUST<bcp14>MUST</bcp14> indicate it does not support the protocol version by sending an Error message with parameter value 12 (Unsupported Version). Note that BFCP entities supporting only the <xreftarget="RFC4582"/>target="RFC4582" format="default" sectionFormat="of" derivedContent="3"/> subset will not support this parametervalue.</t> <t>R: Thevalue.</dd> <dt pn="section-5.1-3.3">R:</dt> <dd pn="section-5.1-3.4">The Transaction Responder (R)flag-bitflag bit has relevance only for use of BFCP over an unreliable transport. When cleared, it indicates that this message is a request initiating a new transaction, and the Transaction ID that follows has been generated for this transaction. When set, it indicates that this message is a response to a previous request, and the Transaction ID that follows is the one associated with that request. When BFCP is used over a reliable transport, the flag has no significance andMUST<bcp14>MUST</bcp14> be cleared by the sender andMUST<bcp14>MUST</bcp14> be ignored by thereceiver.</t> <t>F: Thereceiver.</dd> <dt pn="section-5.1-3.5">F:</dt> <dd pn="section-5.1-3.6">The Fragmentation (F)flag-bitflag bit has relevance only for use of BFCP over an unreliable transport. When cleared, the message is not fragmented. When set, it indicates that the message is a fragment of alargelarge, fragmented BFCP message. (The optional fields Fragment Offset and Fragment Length described below are present only if the F flag is set). When BFCP is used over a reliable transport, the flag has no significance andMUST<bcp14>MUST</bcp14> be cleared by thesendersender, and the flagMUST<bcp14>MUST</bcp14> be ignored by the receiver. In the latter case, the receiver should alsoprocess the COMMON-HEADER as not havingignore the Fragment Offset and Fragment Length fieldspresent.</t> <t>Res: Thewhen processing the COMMON-HEADER. </dd> <dt pn="section-5.1-3.7">Res:</dt> <dd pn="section-5.1-3.8">The 3 bits in the reserved fieldMUST<bcp14>MUST</bcp14> be set to zero by the sender of the message andMUST<bcp14>MUST</bcp14> be ignored by thereceiver.</t> <t>Primitive: Thisreceiver.</dd> <dt pn="section-5.1-3.9">Primitive:</dt> <dd pn="section-5.1-3.10">This 8-bit field identifies the main purpose of the message. The following primitive values aredefined:</t> <texttable title="BFCP primitives" anchor="tab:primitives"> <ttcol align="center">Value</ttcol> <ttcol>Primitive</ttcol> <ttcol>Direction</ttcol> <c>1</c> <c>FloorRequest</c> <c><![CDATA[P -> S]]></c> <c>2</c> <c>FloorRelease</c> <c><![CDATA[P -> S]]></c> <c>3</c> <c>FloorRequestQuery</c> <c><![CDATA[P ->defined:</dd> </dl> <table anchor="tab_primitives" align="center" pn="table-1"> <name slugifiedName="name-bfcp-primitives">BFCP primitives</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">Primitive</th> <th align="left" colspan="1" rowspan="1">Direction</th> </tr> </thead> <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">P -> S</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">P -> S</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">P -> S ; Ch-> S]]></c> <c>4</c> <c>FloorRequestStatus</c> <c><![CDATA[P <--> S</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">P <- S ; Ch<- S]]></c> <c>5</c> <c>UserQuery</c> <c><![CDATA[P -><- S</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">P -> S ; Ch-> S]]></c> <c>6</c> <c>UserStatus</c> <c><![CDATA[P <--> S</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">P <- S ; Ch<- S]]></c> <c>7</c> <c>FloorQuery</c> <c><![CDATA[P -><- S</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">P -> S ; Ch-> S]]></c> <c>8</c> <c>FloorStatus</c> <c><![CDATA[P <--> S</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">P <- S ; Ch<- S]]></c> <c>9</c> <c>ChairAction</c> <c><![CDATA[<- S</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"> Ch-> S]]></c> <c>10</c> <c>ChairActionAck</c> <c><![CDATA[-> S</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"> Ch<- S]]></c> <c>11</c> <c>Hello</c> <c><![CDATA[P -><- S</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">P -> S ; Ch-> S]]></c> <c>12</c> <c>HelloAck</c> <c><![CDATA[P <--> S</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">P <- S ; Ch<- S]]></c> <c>13</c> <c>Error</c> <c><![CDATA[P <-<- S</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">P <- S ; Ch<- S]]></c> <c>14</c> <c>FloorRequestStatusAck</c> <c><![CDATA[P -><- 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 -> S ; Ch-> S]]></c> <c>15</c> <c>FloorStatusAck</c> <c><![CDATA[P ->-> 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 -> S ; Ch-> S]]></c> <c>16</c> <c>Goodbye</c> <c><![CDATA[P ->-> 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 -> S ; Ch->-> S ;]]></c> <c> </c> <c></c> <c><![CDATA[P <-P <- S ; Ch<- S]]></c> <c>17</c> <c>GoodbyeAck</c> <c><![CDATA[P -><- 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 -> S ; Ch->-> S ;]]></c> <c> </c> <c></c> <c><![CDATA[P <-P <- S ; Ch<- S]]></c> <postamble> S:<- 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 ControlServer / P:Server<br/>P: FloorParticipant / Ch:Participant<br/>Ch: FloorChair </postamble> </texttable> <t>Payload Length: ThisChair</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 thecommon header.COMMON-HEADER. If aFloor Control Serverfloor control server receives a message with an incorrect Payload Length field value, the receiving serverMUST<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 lengthMUST<bcp14>MUST</bcp14> discard themessage.</t> <t><list style="hanging"> <t>Note:message.</dd> </dl> <aside pn="section-5.1-7"> <t indent="0" pn="section-5.1-7.1">Note: BFCP is designed to achieve small message size, as explained in <xreftarget="sec:intro"/>,target="sec_intro" format="default" sectionFormat="of" derivedContent="Section 1"/>, and BFCP entities arerequired<bcp14>REQUIRED</bcp14> to keep the BFCP message size smaller than the size limited by the 16-bit Payload Length field. To convey information not strictly related to floor control, other protocols should beusedused, such as the XCONframework (cf. <xref target="sec:scope"/>).</t> </list></t> <t>Conference ID: ThisFramework (cf. <xref target="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 isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the conference identifier be randomly chosen. (Note that the use of predictable conference identifiers in conjunction with anon-securenonsecure transport protocol makes BFCP susceptible to off-path data injection attacks, where an attacker can forge a request or responsemessage.)</t> <t>Transaction ID: Thismessage.)</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 allows users to match a given message with its response (see <xreftarget="sec:transactions"/>).</t> <t>User ID: Thistarget="sec_transactions" 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 aconference.</t> <t><list style="hanging"> <t>Theconference.</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 identity 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 specification.</t></list></t> <t>Fragment Offset: This</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 units contained in previous fragments, excluding thecommon header.</t> <t>Fragment Length: ThisCOMMON-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 thecommon header.COMMON-HEADER. BFCP entities that receive message fragments that, individually or collectively, exceed the Payload Length valueMUST<bcp14>MUST</bcp14> discard the message. Additionally, if the receiver is aFloor Control Server,floor control server, itmust<bcp14>MUST</bcp14> also send an Error message with parameter value 13 (Incorrect MessageLength)</t>Length)</dd> </dl> </section> <sectiontitle="Attribute Format" anchor="sec:format:attributes"> <t>BFCPanchor="sec_format_attributes" numbered="true" toc="include" removeInRFC="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 (Type-Length-Value) format. Attributes are 32-bit aligned.</t><t><figure title="Attribute format" anchor="sec:format:tlv"> <artwork><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 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Attribute Contents / / / | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure></t> <t>Type: This<dl indent="3" newline="false" spacing="normal" pn="section-5.2-3"> <dt pn="section-5.2-3.1">Type:</dt> <dd pn="section-5.2-3.2"> <t indent="0" pn="section-5.2-3.2.1">This 7-bit field contains the type of the attribute. Each attribute, identified by its type, has a particular format. The attribute formats defined are:</t><t><list style="hanging"> <t>Unsigned16: The<dl indent="3" newline="false" spacing="normal" pn="section-5.2-3.2.2"> <dt pn="section-5.2-3.2.2.1">Unsigned16:</dt> <dd pn="section-5.2-3.2.2.2">The contents of the attribute consist of a 16-bit unsignedinteger.</t> <t>OctetString16: Theinteger.</dd> <dt pn="section-5.2-3.2.2.3">OctetString16:</dt> <dd pn="section-5.2-3.2.2.4">The contents of the attribute consist of 16 bits of arbitrarydata.</t> <t>OctetString: Thedata.</dd> <dt pn="section-5.2-3.2.2.5">OctetString:</dt> <dd pn="section-5.2-3.2.2.6">The contents of the attribute consist of arbitrary data of variablelength.</t> <t>Grouped: Thelength.</dd> <dt pn="section-5.2-3.2.2.7">Grouped:</dt> <dd pn="section-5.2-3.2.2.8">The contents of the attribute consist of a sequence ofattributes.</t> <t>Noteattributes.</dd> </dl> </dd> </dl> <aside pn="section-5.2-4"> <t indent="0" pn="section-5.2-4.1">Note that extension attributes defined in the future may define new attribute formats.</t></list></t> <t>The</aside> <t indent="0" pn="section-5.2-5">The following attribute types are defined:</t><texttable title="BFCP attributes" anchor="tab:attributes"> <ttcol align="center">Type</ttcol> <ttcol>Attribute</ttcol> <ttcol>Format</ttcol> <c>1</c> <c>BENEFICIARY-ID</c> <c>Unsigned16</c> <c>2</c> <c>FLOOR-ID</c> <c>Unsigned16</c> <c>3</c> <c>FLOOR-REQUEST-ID</c> <c>Unsigned16</c> <c>4</c> <c>PRIORITY</c> <c>OctetString16</c> <c>5</c> <c>REQUEST-STATUS</c> <c>OctetString16</c> <c>6</c> <c>ERROR-CODE</c> <c>OctetString</c> <c>7</c> <c>ERROR-INFO</c> <c>OctetString</c> <c>8</c> <c>PARTICIPANT-PROVIDED-INFO</c> <c>OctetString</c> <c>9</c> <c>STATUS-INFO</c> <c>OctetString</c> <c>10</c> <c>SUPPORTED-ATTRIBUTES</c> <c>OctetString</c> <c>11</c> <c>SUPPORTED-PRIMITIVES</c> <c>OctetString</c> <c>12</c> <c>USER-DISPLAY-NAME</c> <c>OctetString</c> <c>13</c> <c>USER-URI</c> <c>OctetString</c> <c>14</c> <c>BENEFICIARY-INFORMATION</c> <c>Grouped</c> <c>15</c> <c>FLOOR-REQUEST-INFORMATION</c> <c>Grouped</c> <c>16</c> <c>REQUESTED-BY-INFORMATION</c> <c>Grouped</c> <c>17</c> <c>FLOOR-REQUEST-STATUS</c> <c>Grouped</c> <c>18</c> <c>OVERALL-REQUEST-STATUS</c> <c>Grouped</c> </texttable> <t>M: The<table anchor="tab_attributes" align="center" pn="table-2"> <name slugifiedName="name-bfcp-attributes">BFCP attributes</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Type</th> <th align="left" colspan="1" rowspan="1">Attribute</th> <th align="left" colspan="1" rowspan="1">Format</th> </tr> </thead> <tbody> <tr> <td align="center" colspan="1" rowspan="1">1</td> <td align="left" colspan="1" rowspan="1">BENEFICIARY-ID</td> <td align="left" colspan="1" rowspan="1">Unsigned16</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="left" colspan="1" rowspan="1">FLOOR-ID</td> <td align="left" colspan="1" rowspan="1">Unsigned16</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">3</td> <td align="left" colspan="1" rowspan="1">FLOOR-REQUEST-ID</td> <td align="left" colspan="1" rowspan="1">Unsigned16</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">4</td> <td align="left" colspan="1" rowspan="1">PRIORITY</td> <td align="left" colspan="1" rowspan="1">OctetString16</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">5</td> <td align="left" colspan="1" rowspan="1">REQUEST-STATUS</td> <td align="left" colspan="1" rowspan="1">OctetString16</td> </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</td> <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, indicates whether support of the attribute isrequired.<bcp14>REQUIRED</bcp14>. If aFloor Control Serverfloor control server receives an unrecognized attribute with the 'M' bitsetset, the serverMUST<bcp14>MUST</bcp14> send an Error message with parameter value 4 (Unknown Mandatory Attribute) to indicate this. The 'M' bit is significant for extension attributes defined in other documents only. All attributes specified in this documentMUST<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 might be specified in future extensions, that do not have the"M"'M' bit set are ignored, but the message isprocessed.</t> <t>Length: Thisprocessed.</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 attribute 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 (including padding) of all the includedattributes.</t> <t>Attribute Contents: Theattributes.</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 followingsections.</t>sections.</dd> </dl> <sectiontitle="BENEFICIARY-ID" anchor="sec:format:attributes:beneficiaryid"> <t>Theanchor="sec_format_attributes_beneficiaryid" numbered="true" toc="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><t><figure title="BENEFICIARY-ID format" anchor="sec:format:beneficiary-id"> <artwork><figure anchor="sec_format_beneficiary-id" align="left" suppress-title="false" pn="figure-7"> <name slugifiedName="name-beneficiary-id-format">BENEFICIARY-ID format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.1-2.1"> 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 0 0 0 0 0 1|M|0 0 0 0 0 1 0 0| Beneficiary ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Beneficiary ID: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.1-3"> <dt pn="section-5.2.1-3.1">Beneficiary ID:</dt> <dd pn="section-5.2.1-3.2">This field contains a 16-bit value that uniquely identifies a user within aconference.</t> <t><list style="empty"> <t>Noteconference.</dd> </dl> <aside pn="section-5.2.1-4"> <t indent="0" pn="section-5.2.1-4.1">Note that although the formats of the Beneficiary ID and of the User ID field in thecommon headerCOMMON-HEADER are similar, their semantics are different. The Beneficiary ID is used in third-party floor requests and to request information about a particular participant.</t></list></t></aside> </section> <sectiontitle="FLOOR-ID" anchor="sec:format:attributes:floorid"> <t>Theanchor="sec_format_attributes_floorid" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2"> <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><t><figure title="FLOOR-ID format" anchor="sec:format:floor-id"> <artwork><figure anchor="sec_format_floor-id" align="left" suppress-title="false" 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 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Floor ID: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.2-3"> <dt pn="section-5.2.2-3.1">Floor ID:</dt> <dd pn="section-5.2.2-3.2">This field contains a 16-bit value that uniquely identifies a floor within aconference.</t>conference.</dd> </dl> </section> <sectiontitle="FLOOR-REQUEST-ID" anchor="sec:format:attributes:floorrequestid"> <t>Theanchor="sec_format_attributes_floorrequestid" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3"> <name slugifiedName="name-floor-request-id">FLOOR-REQUEST-ID</name> <t indent="0" pn="section-5.2.3-1">The following is the format of the FLOOR-REQUEST-ID attribute.</t><t><figure title="FLOOR-REQUEST-ID format" anchor="sec:format:floor-request-id"> <artwork><figure anchor="sec_format_floor-request-id" align="left" suppress-title="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 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Floor+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.3-3"> <dt pn="section-5.2.3-3.1">Floor RequestID: ThisID:</dt> <dd pn="section-5.2.3-3.2">This field contains a 16-bit value that identifies a floor request at the floor controlserver.</t>server.</dd> </dl> </section> <sectiontitle="PRIORITY" anchor="sec:format:attributes:priority"> <t>Theanchor="sec_format_attributes_priority" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.4"> <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><t><figure title="PRIORITY format" anchor="sec:format:priority"> <artwork><figure anchor="sec_format_priority" align="left" suppress-title="false" 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 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure></t> <t>Prio: This<dl indent="3" newline="false" spacing="normal" pn="section-5.2.4-3"> <dt pn="section-5.2.4-3.1">Prio:</dt> <dd pn="section-5.2.4-3.2">This field contains a 3-bitpriorityPriority value, as shown in <xreftarget="tab:priority"/>.target="tab_priority" format="default" sectionFormat="of" derivedContent="Table 3"/>. SendersSHOULD NOT<bcp14>SHOULD NOT</bcp14> use values higher than 4 in this field. ReceiversMUST<bcp14>MUST</bcp14> treat values higher than 4 as if the value received were 4 (Highest). The defaultpriorityPriority value when the PRIORITY attribute is missing is 2(Normal).</t> <texttable title="Priority values" anchor="tab:priority"> <ttcol align="center">Value</ttcol> <ttcol>Priority</ttcol> <c>0</c> <c>Lowest</c> <c>1</c> <c>Low</c> <c>2</c> <c>Normal</c> <c>3</c> <c>High</c> <c>4</c> <c>Highest</c> </texttable> <t>Reserved: The(Normal).</dd> </dl> <table anchor="tab_priority" align="center" pn="table-3"> <name slugifiedName="name-priority-values">Priority values</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">Priority</th> </tr> </thead> <tbody> <tr> <td align="center" colspan="1" rowspan="1">0</td> <td align="left" colspan="1" rowspan="1">Lowest</td> </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 fieldMUST<bcp14>MUST</bcp14> be set to zero by the sender of the message andMUST<bcp14>MUST</bcp14> be ignored by thereceiver.</t>receiver.</dd> </dl> </section> <sectiontitle="REQUEST-STATUS" anchor="sec:format:attributes:req-status"> <t>Theanchor="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><t><figure title="REQUEST-STATUS format" anchor="sec:format:request-status"> <artwork><figure anchor="sec_format_request-status" align="left" suppress-title="false" pn="figure-11"> <name slugifiedName="name-request-status-format">REQUEST-STATUS format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.5-2.1"> 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 0 0 0 1 0 1|M|0 0 0 0 0 1 0 0|Request Status |Queue Position |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Request Status: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.5-3"> <dt pn="section-5.2.5-3.1">Request Status:</dt> <dd pn="section-5.2.5-3.2">This 8-bit field contains the status of the request, as described in the followingtable.</t> <texttable title="Requesttable.</dd> </dl> <table anchor="tab_requeststatusvalues" align="center" pn="table-4"> <name slugifiedName="name-request-status-values">Request Statusvalues" anchor="tab:requeststatusvalues"> <ttcol align="center">Value</ttcol> <ttcol>Status</ttcol> <c>1</c> <c>Pending</c> <c>2</c> <c>Accepted</c> <c>3</c> <c>Granted</c> <c>4</c> <c>Denied</c> <c>5</c> <c>Cancelled</c> <c>6</c> <c>Released</c> <c>7</c> <c>Revoked</c> </texttable> <t>Queue Position: Thisvalues</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">Status</th> </tr> </thead> <tbody> <tr> <td align="center" colspan="1" rowspan="1">1</td> <td align="left" colspan="1" rowspan="1">Pending</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="left" colspan="1" rowspan="1">Accepted</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">3</td> <td align="left" colspan="1" rowspan="1">Granted</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">4</td> <td align="left" colspan="1" rowspan="1">Denied</td> </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 fieldSHOULD<bcp14>SHOULD</bcp14> be set tozero.</t> <t>Azero.</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 the 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> <sectiontitle="ERROR-CODE" anchor="sec:format:attributes:error-code"> <t>Theanchor="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><t><figure title="ERROR-CODE format" anchor="sec:format:error"> <artwork><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 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Error Specific Details | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Error Code: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.6-3"> <dt pn="section-5.2.6-3.1">Error Code:</dt> <dd pn="section-5.2.6-3.2">This 8-bit field contains an error code from the following table. If an error code is not recognized by the receiver, then the receiverMUST<bcp14>MUST</bcp14> assume that an error exists, and therefore that the original message that triggered the Error message to be sent is processed, but the nature of the error isunclear.</t> <texttable title="Errorunclear.</dd> </dl> <table anchor="tab_errorcode" align="center" pn="table-5"> <name slugifiedName="name-error-code-meaning">Error Codemeaning" anchor="tab:errorcode"> <ttcol align="center">Value</ttcol> <ttcol>Meaning</ttcol> <c>1</c> <c>Conference does not Exist</c> <c>2</c> <c>User does not Exist</c> <c>3</c> <c>Unknown Primitive</c> <c>4</c> <c>Unknownmeaning</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">Meaning</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> </tr> <tr> <td align="center" colspan="1" rowspan="1">2</td> <td align="left" colspan="1" rowspan="1">User Does Not Exist</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">3</td> <td align="left" colspan="1" rowspan="1">Unknown Primitive</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">4</td> <td align="left" colspan="1" rowspan="1">Unknown MandatoryAttribute</c> <c>5</c> <c>Unauthorized Operation</c> <c>6</c> <c>Invalid Floor ID</c> <c>7</c> <c>FloorAttribute</td> </tr> <tr> <td align="center" colspan="1" rowspan="1">5</td> <td align="left" colspan="1" rowspan="1">Unauthorized Operation</td> </tr> <tr> <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 NotExist</c> <c>8</c> <c>YouExist</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 forthis Floor</c> <c>9</c> <c>Use TLS</c> <c>10</c> <c>UnableThis 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 ParseMessage</c> <c>11</c> <c>Use DTLS</c> <c>12</c> <c>Unsupported Version</c> <c>13</c> <c>IncorrectMessage</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 MessageLength</c> <c>14</c> <c>Generic Error</c> </texttable> <t><list style="empty"> <t>Note:Length</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 code is intended to be used when an error occurs and the other specific error codes do not apply.</t></list></t> <t>Error</aside> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.6-6"> <dt pn="section-5.2.6-6.1">Error SpecificDetails: PresentDetails:</dt> <dd pn="section-5.2.6-6.2">Present only for certainError Codes.error codes. In this document, this field is present only for Error Code 4 (Unknown Mandatory Attribute). See <xreftarget="sec:format:attributes:error-code:specific-4"/>target="sec_format_attributes_error-code_specific-4" format="default" sectionFormat="of" derivedContent="Section 5.2.6.1"/> for itsdefinition.</t> <t>Padding: One,definition.</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 of padding added so that the contents of the ERROR-CODE attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.</t><t>The<t indent="0" pn="section-5.2.6-6.4.2">The Padding bitsMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> </dd> </dl> <sectiontitle="Error-Specificanchor="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 Specific Details for Error Code4" anchor="sec:format:attributes:error-code:specific-4"> <t>The4</name> <t indent="0" pn="section-5.2.6.1-1">The following is the format of theError-SpecificError Specific Details field for Error Code 4.</t><t><figure title="Unknown<figure anchor="sec_format_unknown-tlvs" align="left" suppress-title="false" pn="figure-13"> <name slugifiedName="name-unknown-attributes-format">Unknown attributesformat" anchor="sec:format:unknown-tlvs"> <artwork>format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.6.1-2.1"> 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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> </figure></t> <t>Unknown Type: These+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.6.1-3"> <dt pn="section-5.2.6.1-3.1">Unknown Type:</dt> <dd pn="section-5.2.6.1-3.2">These 7-bit fields contain the Types of the attributes (which were present in the message that triggered the Error message) that were unknown to thereceiver.</t> <t>R: Thisreceiver.</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. ItMUST<bcp14>MUST</bcp14> be set to zero by the sender of the message andMUST<bcp14>MUST</bcp14> be ignored by thereceiver.</t>receiver.</dd> </dl> </section> </section> <sectiontitle="ERROR-INFO" anchor="sec:format:attributes:error-info"> <t>Theanchor="sec_format_attributes_error-info" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.7"> <name slugifiedName="name-error-info">ERROR-INFO</name> <t indent="0" pn="section-5.2.7-1">The following is the format of the ERROR-INFO attribute.</t><t><figure title="ERROR-INFO format" anchor="sec:format:error-info"> <artwork><figure anchor="sec_format_error-info" align="left" suppress-title="false" 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 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Text: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.7-3"> <dt pn="section-5.2.7-3.1">Text:</dt> <dd pn="section-5.2.7-3.2"> <t indent="0" pn="section-5.2.7-3.2.1">This field contains UTF-8<xref target="RFC3629"/>encodedtext.</t> <t>Intext <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="9"/>.</t> <t indent="0" pn="section-5.2.7-3.2.2">In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular ERROR-INFO attribute, itMAY<bcp14>MAY</bcp14> use this language to generate the Text field.</t><t>Padding: One,</dd> <dt pn="section-5.2.7-3.3">Padding:</dt> <dd pn="section-5.2.7-3.4">One, two, or three octets of padding added so that the contents of the ERROR-INFO attribute is 32-bit aligned. The Padding bitsMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is already 32-bit aligned, no padding isneeded.</t>needed.</dd> </dl> </section> <sectiontitle="PARTICIPANT-PROVIDED-INFO" anchor="sec:format:attributes:human-read-info"> <t>Theanchor="sec_format_attributes_human-read-info" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.8"> <name slugifiedName="name-participant-provided-info">PARTICIPANT-PROVIDED-INFO</name> <t indent="0" pn="section-5.2.8-1">The following is the format of the PARTICIPANT-PROVIDED-INFO attribute.</t><t><figure title="PARTICIPANT-PROVIDED-INFO format" anchor="sec:format:human"> <artwork><figure anchor="sec_format_human" align="left" suppress-title="false" pn="figure-15"> <name slugifiedName="name-participant-provided-info-f">PARTICIPANT-PROVIDED-INFO format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.8-2.1"> 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 0 0 1 0 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Text: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.8-3"> <dt pn="section-5.2.8-3.1">Text:</dt> <dd pn="section-5.2.8-3.2">This field contains UTF-8<xref target="RFC3629"/>encodedtext.</t> <t>Padding: One,text <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="9"/>.</dd> <dt pn="section-5.2.8-3.3">Padding:</dt> <dd pn="section-5.2.8-3.4">One, two, or three octets of padding added so that the contents of the PARTICIPANT-PROVIDED-INFO attribute is 32-bit aligned. The Padding bitsMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is already 32-bit aligned, no padding isneeded.</t>needed.</dd> </dl> </section> <sectiontitle="STATUS-INFO" anchor="sec:format:attributes:status-info"> <t>Theanchor="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><t><figure title="STATUS-INFO format" anchor="sec:format:status"> <artwork><figure anchor="sec_format_status" align="left" suppress-title="false" pn="figure-16"> <name slugifiedName="name-status-info-format">STATUS-INFO format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.9-2.1"> 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 0 0 1 0 0 1|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Text: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.9-3"> <dt pn="section-5.2.9-3.1">Text:</dt> <dd pn="section-5.2.9-3.2"> <t indent="0" pn="section-5.2.9-3.2.1">This field contains UTF-8<xref target="RFC3629"/>encodedtext.</t> <t>Intext <xref target="RFC3629" format="default" sectionFormat="of" derivedContent="9"/>.</t> <t indent="0" pn="section-5.2.9-3.2.2">In some situations, the contents of the Text field may be generated by an automaton. If this automaton has information about the preferred language of the receiver of a particular STATUS-INFO attribute, itMAY<bcp14>MAY</bcp14> use this language to generate the Text field.</t><t>Padding: One,</dd> <dt pn="section-5.2.9-3.3">Padding:</dt> <dd pn="section-5.2.9-3.4">One, two, or three octets of padding added so that the contents of the STATUS-INFO attribute is 32-bit aligned. The Padding bitsMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is already 32-bit aligned, no padding isneeded.</t>needed.</dd> </dl> </section> <sectiontitle="SUPPORTED-ATTRIBUTES" anchor="sec:format:attributes:supported-tlvs"> <t>Theanchor="sec_format_attributes_supported-tlvs" numbered="true" toc="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><t><figure title="SUPPORTED-ATTRIBUTES format" anchor="fig:format:supported-tlvs"> <artwork><figure anchor="fig_format_supported-tlvs" align="left" suppress-title="false" pn="figure-17"> <name slugifiedName="name-supported-attributes-format">SUPPORTED-ATTRIBUTES format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.10-2.1"> 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 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Supp. Attr.: These+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.10-3"> <dt pn="section-5.2.10-3.1">Supp. Attr.:</dt> <dd pn="section-5.2.10-3.2">These fields contain theTypes of the attributesBFCP attribute types that are supported by the floor controlserver inserver. See <xref target="tab_attributes" format="default" sectionFormat="of" derivedContent="Table 2"/> for thefollowing format:</t> <t>R: Reserved: Thislist of BFCP attributes.</dd> <dt pn="section-5.2.10-3.3">Reserved (R):</dt> <dd pn="section-5.2.10-3.4">This bitMUST<bcp14>MUST</bcp14> be set to zero upon transmission andMUST<bcp14>MUST</bcp14> be ignored uponreception.</t> <t>Padding: One,reception.</dd> <dt pn="section-5.2.10-3.5">Padding:</dt> <dd pn="section-5.2.10-3.6"> <t indent="0" pn="section-5.2.10-3.6.1">One, two, or three octets of padding added so that the contents of the SUPPORTED-ATTRIBUTES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.</t><t>The<t indent="0" pn="section-5.2.10-3.6.2">The Padding bitsMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> </dd> </dl> </section> <sectiontitle="SUPPORTED-PRIMITIVES" anchor="sec:format:attributes:supported-reqs"> <t>Theanchor="sec_format_attributes_supported-reqs" numbered="true" toc="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><t><figure title="SUPPORTED-PRIMITIVES format" anchor="fig:format:supported-reqs"> <artwork><figure anchor="fig_format_supported-reqs" align="left" suppress-title="false" pn="figure-18"> <name slugifiedName="name-supported-primitives-format">SUPPORTED-PRIMITIVES format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.11-2.1"> 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 0 0 1 0 1 1|M| Length | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primitive | Primitive | Primitive | Primitive | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Primitive: These+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.11-3"> <dt pn="section-5.2.11-3.1">Primitive:</dt> <dd pn="section-5.2.11-3.2">These fields contain the types of the BFCP messages that are supported by the floor control server. See <xreftarget="tab:primitives"/>target="tab_primitives" format="default" sectionFormat="of" derivedContent="Table 1"/> for the list of BFCPprimitives.</t> <t>Padding: One,primitives.</dd> <dt pn="section-5.2.11-3.3">Padding:</dt> <dd pn="section-5.2.11-3.4"> <t indent="0" pn="section-5.2.11-3.4.1">One, two, or three octets of padding added so that the contents of the SUPPORTED-PRIMITIVES attribute is 32-bit aligned. If the attribute is already 32-bit aligned, no padding is needed.</t><t>The<t indent="0" pn="section-5.2.11-3.4.2">The Padding bitsMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver.</t> </dd> </dl> </section> <sectiontitle="USER-DISPLAY-NAME" anchor="sec:format:attributes:user-display-name"> <t>Theanchor="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><t><figure title="USER-DISPLAY-NAME format" anchor="sec:format:user-display"> <artwork><figure anchor="sec_format_user-display" align="left" suppress-title="false" pn="figure-19"> <name slugifiedName="name-user-display-name-format">USER-DISPLAY-NAME format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.12-2.1"> 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 0 0 1 1 0 0|M| Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Text: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.12-3"> <dt pn="section-5.2.12-3.1">Text:</dt> <dd pn="section-5.2.12-3.2">This field contains the UTF-8 encoded name of theuser.</t> <t>Padding: One,user.</dd> <dt pn="section-5.2.12-3.3">Padding:</dt> <dd pn="section-5.2.12-3.4">One, two, or three octets of padding added so that the contents of the USER-DISPLAY-NAME attribute is 32-bit aligned. The Padding bitsMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is already 32-bit aligned, no padding isneeded.</t>needed.</dd> </dl> </section> <sectiontitle="USER-URI" anchor="sec:format:attributes:user-uri"> <t>Theanchor="sec_format_attributes_user-uri" numbered="true" toc="include" 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><t><figure title="USER-URI format" anchor="sec:format:user-uri"> <artwork><figure anchor="sec_format_user-uri" align="left" suppress-title="false" 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 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Text / / +-+-+-+-+-+-+-+-+ | | Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Text: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.13-3"> <dt pn="section-5.2.13-3.1">Text:</dt> <dd pn="section-5.2.13-3.2">This field contains the UTF-8 encoded user's contact URI, that is, the URI used by the user to set up the resources (e.g., media streams) that are controlled by BFCP. For example, in the context of a conference set up by SIP, the USER-URI attribute would carry the SIP URI of theuser.</t> <t><list style="hanging"> <t>Messagesuser.</dd> </dl> <aside pn="section-5.2.13-4"> <t indent="0" pn="section-5.2.13-4.1">Messages containing a user's URI in a USER-URI attribute also contain the user's User ID. This way, a client receiving such a message can correlate the user's URI (e.g., the SIP URI the user used to join a conference) with the user's User ID.</t></list></t> <t>Padding: One,</aside> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.13-5"> <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 added so that the contents of the USER-URI attribute is 32-bit aligned. The Padding bitsMUST<bcp14>MUST</bcp14> be set to zero by the sender andMUST<bcp14>MUST</bcp14> be ignored by the receiver. If the attribute is already 32-bit aligned, no padding isneeded.</t>needed.</dd> </dl> </section> <sectiontitle="BENEFICIARY-INFORMATION" anchor="sec:format:attributes:ben-info"> <t>Theanchor="sec_format_attributes_ben-info" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.14"> <name slugifiedName="name-beneficiary-information">BENEFICIARY-INFORMATION</name> <t indent="0" pn="section-5.2.14-1">The BENEFICIARY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as BENEFICIARY-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the BENEFICIARY-INFORMATION-HEADER:</t><t><figure title="BENEFICIARY-INFORMATION-HEADER format" anchor="fig:format:ben-information-header"> <artwork><figure anchor="fig_format_ben-information-header" align="left" suppress-title="false" pn="figure-21"> <name slugifiedName="name-beneficiary-information-hea">BENEFICIARY-INFORMATION-HEADER format</name> <artwork name="" type="" align="left" alt="" pn="section-5.2.14-2.1"> 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 0 0 1 1 1 0|M| Length | Beneficiary ID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Beneficiary ID: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.14-3"> <dt pn="section-5.2.14-3.1">Beneficiary ID:</dt> <dd pn="section-5.2.14-3.2">This field contains a 16-bit value that uniquely identifies a user within aconference.</t> <t>Theconference.</dd> </dl> <t indent="0" pn="section-5.2.14-4">The following is the ABNF (Augmented Backus-Naur Form) <xreftarget="RFC5234"/>target="RFC5234" format="default" sectionFormat="of" derivedContent="5"/> of the BENEFICIARY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)</t><t><figure title="BENEFICIARY-INFORMATION format" anchor="fig:ben-information"> <artwork><figure anchor="fig_ben-information" align="left" suppress-title="false" pn="figure-22"> <name slugifiedName="name-beneficiary-information-for">BENEFICIARY-INFORMATION format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.2.14-5.1"> BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI]*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FLOOR-REQUEST-INFORMATION" anchor="sec:format:attributes:floor-req-info"> <t>Theanchor="sec_format_attributes_floor-req-info" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.15"> <name slugifiedName="name-floor-request-information">FLOOR-REQUEST-INFORMATION</name> <t indent="0" pn="section-5.2.15-1">The FLOOR-REQUEST-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as FLOOR-REQUEST-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the FLOOR-REQUEST-INFORMATION-HEADER:</t><t><figure title="FLOOR-REQUEST-INFORMATION-HEADER format" anchor="fig:format:request-information-header"> <artwork><figure anchor="fig_format_request-information-header" align="left" suppress-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 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Floor+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.15-3"> <dt pn="section-5.2.15-3.1">Floor RequestID: ThisID:</dt> <dd pn="section-5.2.15-3.2">This field contains a 16-bit value that identifies a floor request at the floor controlserver.</t> <t>Theserver.</dd> </dl> <t indent="0" pn="section-5.2.15-4">The following is the ABNF of the FLOOR-REQUEST-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)</t><t><figure title="FLOOR-REQUEST-INFORMATION format" anchor="fig:floor-request-information"> <artwork><figure anchor="fig_floor-request-information" align="left" suppress-title="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 [OVERALL-REQUEST-STATUS] 1*FLOOR-REQUEST-STATUS [BENEFICIARY-INFORMATION] [REQUESTED-BY-INFORMATION] [PRIORITY] [PARTICIPANT-PROVIDED-INFO]*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="REQUESTED-BY-INFORMATION" anchor="sec:format:attributes:req-by-info"> <t>Theanchor="sec_format_attributes_req-by-info" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.16"> <name slugifiedName="name-requested-by-information">REQUESTED-BY-INFORMATION</name> <t indent="0" pn="section-5.2.16-1">The REQUESTED-BY-INFORMATION attribute is a grouped attribute that consists of a header, which is referred to as REQUESTED-BY-INFORMATION-HEADER, followed by a sequence of attributes. The following is the format of the REQUESTED-BY-INFORMATION-HEADER:</t><t><figure title="REQUESTED-BY-INFORMATION-HEADER format" anchor="fig:format:req-by-information-header"> <artwork><figure anchor="fig_format_req-by-information-header" align="left" suppress-title="false" pn="figure-25"> <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 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Requested-by ID: This+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.16-3"> <dt pn="section-5.2.16-3.1">Requested-by ID:</dt> <dd pn="section-5.2.16-3.2">This field contains a 16-bit value that uniquely identifies a user within aconference.</t> <t>Theconference.</dd> </dl> <t indent="0" pn="section-5.2.16-4">The following is the ABNF of the REQUESTED-BY-INFORMATION grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)</t><t><figure title="REQUESTED-BY-INFORMATION format" anchor="fig:reqby-information"> <artwork><figure anchor="fig_reqby-information" align="left" suppress-title="false" pn="figure-26"> <name slugifiedName="name-requested-by-information-fo">REQUESTED-BY-INFORMATION format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.2.16-5.1"> REQUESTED-BY-INFORMATION = REQUESTED-BY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI]*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FLOOR-REQUEST-STATUS" anchor="sec:format:attributes:floor-req-status"> <t>Theanchor="sec_format_attributes_floor-req-status" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.17"> <name slugifiedName="name-floor-request-status">FLOOR-REQUEST-STATUS</name> <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 the format of the FLOOR-REQUEST-STATUS-HEADER:</t><t><figure title="FLOOR-REQUEST-STATUS-HEADER format" anchor="fig:format:floor-req-status-header"> <artwork><figure anchor="fig_format_floor-req-status-header" align="left" suppress-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 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Floor ID: this+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.17-3"> <dt pn="section-5.2.17-3.1">Floor ID:</dt> <dd pn="section-5.2.17-3.2">this field contains a 16-bit value that uniquely identifies a floor within aconference.</t> <t>Theconference.</dd> </dl> <t indent="0" pn="section-5.2.17-4">The following is the ABNF of the FLOOR-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)</t><t><figure title="FLOOR-REQUEST-STATUS format" anchor="fig:floor-req-status"> <artwork><figure anchor="fig_floor-req-status" align="left" suppress-title="false" pn="figure-28"> <name slugifiedName="name-floor-request-status-format">FLOOR-REQUEST-STATUS format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.2.17-5.1"> FLOOR-REQUEST-STATUS = FLOOR-REQUEST-STATUS-HEADER [REQUEST-STATUS] [STATUS-INFO]*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="OVERALL-REQUEST-STATUS" anchor="sec:format:attributes:overall-req-status"> <t>Theanchor="sec_format_attributes_overall-req-status" numbered="true" toc="include" removeInRFC="false" pn="section-5.2.18"> <name slugifiedName="name-overall-request-status">OVERALL-REQUEST-STATUS</name> <t indent="0" pn="section-5.2.18-1">The OVERALL-REQUEST-STATUS attribute is a grouped attribute that consists of a header, which is referred to as OVERALL-REQUEST-STATUS-HEADER, followed by a sequence of attributes. The following is the format of the OVERALL-REQUEST-STATUS-HEADER:</t><t><figure title="OVERALL-REQUEST-STATUS-HEADER format" anchor="fig:format:overall-req-status-header"> <artwork><figure anchor="fig_format_overall-req-status-header" align="left" suppress-title="false" pn="figure-29"> <name slugifiedName="name-overall-request-status-head">OVERALL-REQUEST-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 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure></t> <t>Floor+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> </figure> <dl indent="3" newline="false" spacing="normal" pn="section-5.2.18-3"> <dt pn="section-5.2.18-3.1">Floor RequestID: thisID:</dt> <dd pn="section-5.2.18-3.2">This field contains a 16-bit value that identifies a floor request at the floor controlserver.</t> <t>Theserver.</dd> </dl> <t indent="0" pn="section-5.2.18-4">The following is the ABNF of the OVERALL-REQUEST-STATUS grouped attribute. (EXTENSION-ATTRIBUTE refers to extension attributes that may be defined in the future.)</t><t><figure title="OVERALL-REQUEST-STATUS format" anchor="fig:overall-req-status"> <artwork><figure anchor="fig_overall-req-status" align="left" suppress-title="false" pn="figure-30"> <name slugifiedName="name-overall-request-status-form">OVERALL-REQUEST-STATUS format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.2.18-5.1"> OVERALL-REQUEST-STATUS = OVERALL-REQUEST-STATUS-HEADER [REQUEST-STATUS] [STATUS-INFO]*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> </section> <sectiontitle="Message Format" anchor="sec:msg_format"> <t>Thisanchor="sec_msg_format" numbered="true" toc="include" removeInRFC="false" pn="section-5.3"> <name slugifiedName="name-message-format">Message Format</name> <t indent="0" pn="section-5.3-1">This section contains the normative ABNF (Augmented Backus-Naur Form) <xreftarget="RFC5234"/>target="RFC5234" format="default" sectionFormat="of" derivedContent="5"/> of the BFCP messages. Extension attributes that may be defined in the future are referred to as EXTENSION-ATTRIBUTE in the ABNF.</t> <sectiontitle="FloorRequest" anchor="sec:msg_format:FloorRequest"> <t>Flooranchor="sec_msg_format_FloorRequest" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.1"> <name slugifiedName="name-floorrequest">FloorRequest</name> <t indent="0" pn="section-5.3.1-1">Floor participants request a floor by sending a FloorRequest message to the floor control server. The following is the format of the FloorRequest message:</t><t><figure title="FloorRequest format" anchor="fig:floorequest"> <artwork><figure anchor="fig_floorequest" align="left" suppress-title="false" pn="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 1*FLOOR-ID [BENEFICIARY-ID] [PARTICIPANT-PROVIDED-INFO] [PRIORITY]*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FloorRelease" anchor="sec:msg_format:FloorRelease"> <t>Flooranchor="sec_msg_format_FloorRelease" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.2"> <name slugifiedName="name-floorrelease">FloorRelease</name> <t indent="0" pn="section-5.3.2-1">Floor participants release a floor by sending a FloorRelease message to the floor control server. Floor participants also use the FloorRelease message to cancel pending floor requests. The following is the format of the FloorRelease message:</t><t><figure title="FloorRelease format" anchor="fig:floorelease"> <artwork><figure anchor="fig_floorelease" align="left" suppress-title="false" pn="figure-32"> <name slugifiedName="name-floorrelease-format">FloorRelease format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.2-2.1"> FloorRelease = COMMON-HEADER FLOOR-REQUEST-ID*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FloorRequestQuery" anchor="sec:msg_format:FloorRequestQuery"> <t>Flooranchor="sec_msg_format_FloorRequestQuery" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.3"> <name slugifiedName="name-floorrequestquery">FloorRequestQuery</name> <t indent="0" pn="section-5.3.3-1">Floor participants and floor chairs request information about a floor request by sending a FloorRequestQuery message to the floor control server. The following is the format of the FloorRequestQuery message:</t><t><figure title="FloorRequestQuery format" anchor="fig:floorrequestinfo"> <artwork><figure anchor="fig_floorrequestinfo" align="left" suppress-title="false" pn="figure-33"> <name slugifiedName="name-floorrequestquery-format">FloorRequestQuery format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.3-2.1"> FloorRequestQuery = COMMON-HEADER FLOOR-REQUEST-ID*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FloorRequestStatus" anchor="sec:msg_format:FloorRequestStatus"> <t>Theanchor="sec_msg_format_FloorRequestStatus" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.4"> <name slugifiedName="name-floorrequeststatus">FloorRequestStatus</name> <t indent="0" pn="section-5.3.4-1">The floor control server informs floor participants and floor chairs about the status of their floor requests by sending them FloorRequestStatus messages. The following is the format of the FloorRequestStatus message:</t><t><figure title="FloorRequestStatus format" anchor="fig:floorrequeststatus"> <artwork><figure anchor="fig_floorrequeststatus" align="left" suppress-title="false" pn="figure-34"> <name slugifiedName="name-floorrequeststatus-format">FloorRequestStatus format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.4-2.1"> FloorRequestStatus = COMMON-HEADER FLOOR-REQUEST-INFORMATION*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="UserQuery" anchor="sec:msg_format:UserQuery"> <t>Flooranchor="sec_msg_format_UserQuery" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.5"> <name slugifiedName="name-userquery">UserQuery</name> <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 participant by sending a UserQuery message to the floor control server. The following is the format of the UserQuery message:</t><t><figure title="UserQuery format" anchor="fig:userinfowanted"> <artwork><figure anchor="fig_userinfowanted" align="left" suppress-title="false" pn="figure-35"> <name slugifiedName="name-userquery-format">UserQuery format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.5-2.1"> UserQuery = COMMON-HEADER [BENEFICIARY-ID]*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="UserStatus" anchor="sec:msg_format:UserStatus"> <t>Theanchor="sec_msg_format_UserStatus" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.6"> <name slugifiedName="name-userstatus">UserStatus</name> <t indent="0" pn="section-5.3.6-1">The floor control server provides information about participants and their related floor requests to floor participants and floor chairs by sending them UserStatus messages. The following is the format of the UserStatus message:</t><t><figure title="UserStatus format" anchor="fig:userstatus"> <artwork><figure anchor="fig_userstatus" align="left" suppress-title="false" pn="figure-36"> <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 </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FloorQuery" anchor="sec:msg_format:FloorQuery"> <t>Flooranchor="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><t><figure title="FloorQuery format" anchor="fig:floorinfo"> <artwork><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 </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FloorStatus" anchor="sec:msg_format:FloorStatus"> <t>Theanchor="sec_msg_format_FloorStatus" numbered="true" toc="include" 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 floor 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 the FloorStatus message:</t><t><figure title="FloorStatus format" anchor="fig:floorstatus"> <artwork><figure anchor="fig_floorstatus" align="left" suppress-title="false" pn="figure-38"> <name slugifiedName="name-floorstatus-format">FloorStatus format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.8-2.1"> FloorStatus = COMMON-HEADER *FLOOR-ID *FLOOR-REQUEST-INFORMATION*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="ChairAction" anchor="sec:msg_format:ChairAction"> <t>Flooranchor="sec_msg_format_ChairAction" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.9"> <name slugifiedName="name-chairaction">ChairAction</name> <t indent="0" pn="section-5.3.9-1">Floor chairs send instructions to floor control servers by sending them ChairAction messages. The following is the format of the ChairAction message:</t><t><figure title="ChairAction format" anchor="fig:chairaction"> <artwork><figure anchor="fig_chairaction" align="left" suppress-title="false" pn="figure-39"> <name slugifiedName="name-chairaction-format">ChairAction format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.9-2.1"> ChairAction = COMMON-HEADER FLOOR-REQUEST-INFORMATION*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="ChairActionAck" anchor="sec:msg_format:ChairActionAck"> <t>Flooranchor="sec_msg_format_ChairActionAck" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.10"> <name slugifiedName="name-chairactionack">ChairActionAck</name> <t indent="0" pn="section-5.3.10-1">Floor control servers confirm that they have accepted a ChairAction message by sending a ChairActionAck message. The following is the format of the ChairActionAck message:</t><t><figure title="ChairActionAck format" anchor="fig:chairactionack"> <artwork><figure anchor="fig_chairactionack" align="left" suppress-title="false" pn="figure-40"> <name slugifiedName="name-chairactionack-format">ChairActionAck format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.10-2.1"> ChairActionAck = COMMON-HEADER*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="Hello" anchor="sec:msg_format:Hello"> <t>Flooranchor="sec_msg_format_Hello" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.11"> <name slugifiedName="name-hello">Hello</name> <t indent="0" pn="section-5.3.11-1">Floor participants and floor chairsMAY<bcp14>MAY</bcp14> check thelivelinessliveness of floor control servers by sending a Hello message. Additionally, clients communicating with a floor control server overaan unreliable transport use the Hello message to initiate communication with the server. The following is the format of the Hello message:</t><t><figure title="Hello format" anchor="fig:hello"> <artwork><figure anchor="fig_hello" align="left" suppress-title="false" pn="figure-41"> <name slugifiedName="name-hello-format">Hello format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.11-2.1"> Hello = COMMON-HEADER*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="HelloAck" anchor="sec:msg_format:HelloAck"> <t>Flooranchor="sec_msg_format_HelloAck" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.12"> <name slugifiedName="name-helloack">HelloAck</name> <t indent="0" pn="section-5.3.12-1">Floor control servers confirm that they are alive on reception of a Hello message by sending a HelloAck message. The following is the format of the HelloAck message:</t><t><figure title="HelloAck format" anchor="fig:helloack"> <artwork><figure anchor="fig_helloack" align="left" suppress-title="false" pn="figure-42"> <name slugifiedName="name-helloack-format">HelloAck format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.12-2.1"> HelloAck = COMMON-HEADER SUPPORTED-PRIMITIVES SUPPORTED-ATTRIBUTES*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="Error" anchor="sec:msg_format:Error"> <t>Flooranchor="sec_msg_format_Error" numbered="true" toc="include" removeInRFC="false" pn="section-5.3.13"> <name slugifiedName="name-error">Error</name> <t indent="0" pn="section-5.3.13-1">Floor control servers inform floor participants and floor chairs about errors processing requests by sending them Error messages. The following is the format of the Error message:</t><t><figure title="Error format" anchor="fig:error"> <artwork><figure anchor="fig_error" align="left" suppress-title="false" pn="figure-43"> <name slugifiedName="name-error-format">Error format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.13-2.1"> Error = COMMON-HEADER ERROR-CODE [ERROR-INFO]*EXTENSION-ATTRIBUTE </artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FloorRequestStatusAck"> <t>Whennumbered="true" toc="include" removeInRFC="false" pn="section-5.3.14"> <name slugifiedName="name-floorrequeststatusack">FloorRequestStatusAck</name> <t indent="0" pn="section-5.3.14-1">When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorRequestStatus message from the floor control server(cf. <xref target="sec:server:request:subsequent"/>)(cf. <xref target="sec_server_request_subsequent" format="default" sectionFormat="of" derivedContent="Section 13.1.2"/>) by sending a FloorRequestStatusAck message. The following is the format of the FloorRequestStatusAck message:</t><t><figure align="left"<figure anchor="FloorRequestStatusAck"title="FloorRequestStatusAck format"> <artwork align="left"><![CDATA[align="left" suppress-title="false" pn="figure-44"> <name slugifiedName="name-floorrequeststatusack-forma">FloorRequestStatusAck format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.14-2.1"> FloorRequestStatusAck = (COMMON-HEADER)*EXTENSION-ATTRIBUTE ]]></artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="FloorStatusAck"> <t>Whennumbered="true" toc="include" removeInRFC="false" pn="section-5.3.15"> <name slugifiedName="name-floorstatusack">FloorStatusAck</name> <t indent="0" pn="section-5.3.15-1">When communicating over an unreliable transport, floor participants and chairs acknowledge the receipt of a subsequent FloorStatus message from the floor control server(cf. <xref target="sec:server:floorinfo:subsequent"/>)(cf. <xref target="sec_server_floorinfo_subsequent" format="default" sectionFormat="of" derivedContent="Section 13.5.2"/>) by sending a FloorStatusAck message. The following is the format of the FloorStatusAck message:</t><t><figure align="left"<figure anchor="FloorStatusAck"title="FloorStatusAck format"> <artwork align="left"><![CDATA[align="left" suppress-title="false" pn="figure-45"> <name slugifiedName="name-floorstatusack-format">FloorStatusAck format</name> <sourcecode name="" type="abnf" markers="false" pn="section-5.3.15-2.1"> FloorStatusAck = (COMMON-HEADER)*EXTENSION-ATTRIBUTE ]]></artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="Goodbye"> <t>BFCPnumbered="true" toc="include" removeInRFC="false" pn="section-5.3.16"> <name slugifiedName="name-goodbye">Goodbye</name> <t indent="0" pn="section-5.3.16-1">BFCP entities communicating over an unreliable transport that wish to dissociate themselves from their remote participant do so through the transmission of a Goodbye. The following is the format of the Goodbye message:</t><t><figure align="left"<figure anchor="Goodbye"title="Goodbye format"> <artwork align="left"><![CDATA[align="left" suppress-title="false" pn="figure-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 ]]></artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> <sectiontitle="GoodbyeAck"> <t>BFCPnumbered="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 an unreliable transport acknowledge the receipt of a Goodbye message from a peer. The following is the format of the GoodbyeAck message:</t><t><figure align="left"<figure anchor="GoodbyeAck"title="GoodbyeAck format"> <artwork align="left"><![CDATA[align="left" suppress-title="false" pn="figure-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 ]]></artwork> </figure></t>*EXTENSION-ATTRIBUTE</sourcecode> </figure> </section> </section> </section> <sectiontitle="Transport" anchor="sec:transport"> <t>Theanchor="sec_transport" numbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-transport">Transport</name> <t indent="0" pn="section-6-1">The transport over which BFCP entities exchange messages depends on the information the clients obtain forhow to to contactcontacting the floor control server, as described in <xreftarget="sec:scope:info"/>.target="sec_scope_info" format="default" sectionFormat="of" derivedContent="Section 3.2"/>. Two transports are supported: TCP, which is appropriate where connectivity is not impeded by network elements such as NAT devices or media relays; and UDP for those deployments where TCP may not be applicable or appropriate.</t><t><list style="empty"> <t>Informational note:<aside pn="section-6-2"> <t indent="0" pn="section-6-2.1">Note: In practice, products are configured to try one transport first and then use the other transport as a fallback. Whether TCP or UDP is chosen as underlying transport depends on the type of product and the deployment environment. See <xreftarget="app:motivation"/>target="app_motivation" format="default" sectionFormat="of" derivedContent="Appendix B"/> for additional considerations.</t></list></t></aside> <section anchor="tcp_transport"title="Reliable Transport"> <t>BFCPnumbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-reliable-transport">Reliable Transport</name> <t indent="0" pn="section-6.1-1">BFCP entities may elect to exchange BFCP messages using TCP connections. TCP provides an in-order reliable delivery of a stream of bytes. Consequently, message framing needs to be implemented in the application layer. BFCP implements application-layer framing using TLV-encoded attributes.</t><t>A<t indent="0" pn="section-6.1-2">A clientMUST NOT<bcp14>MUST NOT</bcp14> use more than one TCP connection to communicate with a given floor control server within a conference. Nevertheless, if the same physical box handles different clients (e.g., a floor chair and a floor participant), which are identified by different User IDs, a separate connection per client is allowed.</t><t>If<t indent="0" pn="section-6.1-3">If a BFCP entity (a client or a floor control server) receives data that cannot be parsed, the entityMUST<bcp14>MUST</bcp14> close the TCP connection, and the connectionSHOULD<bcp14>SHOULD</bcp14> be reestablished. Similarly, if a TCP connection cannot deliver a BFCP message and times out or receives an ICMP port unreachable message mid-connection, the TCP connectionSHOULD<bcp14>SHOULD</bcp14> be reestablished.</t><t>The<t indent="0" pn="section-6.1-4">The way connection reestablishment is handled depends on how the client obtains information to contact the floor control server. Once the TCP connection is reestablished, the clientMAY<bcp14>MAY</bcp14> resend those messages for which it did not get a response from the floor control server.</t><t>If<t indent="0" pn="section-6.1-5">If a floor control server detects that the TCP connection towards one of the floor participants is lost, it is up to the local policy of the floor control server what to do with the pending floor requests of the floor participant. In any case, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the floor control server keep the floor requests (i.e., that it does not cancel them) while the TCP connection is reestablished.</t><t>If<t indent="0" pn="section-6.1-6">If a client wishes to end its BFCP connection with a floor control server, the client closes (i.e., a graceful close) the TCP connection towards the floor control server. If a floor control server wishes to end its BFCP connection with a client (e.g., theFocusfocus of the conference informs the floor control server that the client has been kicked outfromof the conference), the floor control server closes (i.e., a graceful close) the TCP connection towards the client.</t><t>In<t indent="0" pn="section-6.1-7">In cases where a BFCP entity reestablishes a connection due to protocol errors as described above, the entitySHOULD NOT<bcp14>SHOULD NOT</bcp14> repeatedly reestablish the connection. Rather, if the same protocol errors persist, the entityMUST<bcp14>MUST</bcp14> cease attempts andSHOULD<bcp14>SHOULD</bcp14> report the error to the human user and/or log the event. This does not preclude the entity from reestablishing a connection when facing a different set of errors. That said, entitiesMUST<bcp14>MUST</bcp14> avoid overloading the server with reestablishment requests. A connectionMUST NOT<bcp14>MUST NOT</bcp14> be reestablished too frequently. The frequency is a matter of implementation, butSHOULD NOT<bcp14>SHOULD NOT</bcp14> be attempted more than once in a 30 second period of time.</t> </section> <section anchor="udp_transport"title="Unreliable Transport"> <t>BFCPnumbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-unreliable-transport">Unreliable Transport</name> <t indent="0" pn="section-6.2-1">BFCP entities may elect to exchange BFCP messages using UDP datagrams. UDP is an unreliable transport where neither delivery nor ordering is assured. Each BFCP UDP datagramMUST<bcp14>MUST</bcp14> contain exactly one BFCP message or message fragment. To keep large BFCP messages from being fragmented at the IP layer, the fragmentation of BFCP messages that exceed the path MTU size is performed at the BFCP level. Considerations related to fragmentation are covered in <xreftarget="fragmentation_handling"/>.target="fragmentation_handling" format="default" sectionFormat="of" derivedContent="Section 6.2.3"/>. 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<t indent="0" pn="section-6.2-2">Clients <bcp14>MUST</bcp14> announce their presence to the floor control server by sending a Hello message. The floor control server responds to the Hello message with a HelloAck message. The client considers the floor controlserviceserver 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 <xreftarget="timers"/>.</t> <t>Astarget="timers" format="default" sectionFormat="of" derivedContent="Section 8.3"/>.</t> <t indent="0" pn="section-6.2-3">As described in <xreftarget="sec:transactions"/>,target="sec_transactions" format="default" sectionFormat="of" derivedContent="Section 8"/>, each request sent by a floor participant or chair forms a client transaction that expects an acknowledgement messagebackfrom 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 subscription) require acknowledgement messages from the floor participant and chair entities to which they were sent.</t><t>If<t indent="0" pn="section-6.2-4">If aFloor Control Serverfloor control server receives data that cannot be parsed, the receiving serverMUST<bcp14>MUST</bcp14> send an Error message with parameter value 10 (Unable toparse message)Parse Message) indicating receipt of a malformed message, given that it is possible to parse the received message to such an extent that an Error message may be built.</t><t>Entities MUST<t indent="0" pn="section-6.2-5">Entities <bcp14>MUST</bcp14> have at most one outstanding request transaction per peer at any one time. Implicit subscriptions 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 potentially multiple responses from the floor control server as it processes intermediate states until a terminal state (e.g., Granted or Denied) is attained. The subsequent changes in state for the request are new transactions whose Transaction ID is determined by the floor control server and whose receipt by the client participant is acknowledged with a FloorRequestStatusAck message.</t><t>By<t indent="0" pn="section-6.2-6">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 possibility for congestion are mitigated. Additional details regarding congestion control are provided in <xreftarget="congestion"/>. Atarget="congestion" format="default" sectionFormat="of" derivedContent="Section 6.2.1"/>. If a participant receives a server-initiated request (e.g., a FloorStatuswith an updatefrom the floor control server)received bywhile waiting for a response to aparticipant before the initial FloorRequestStatus message that closes theclient-initiated transactionthat was instigated by(e.g., the participant sent a FloorRequestMUST be treatedand is waiting for a FloorRequestStatus response), then the participant <bcp14>MUST</bcp14> treat the server-initiated request as supersedingthe information conveyed inanysuch late arriving response.response to its client-initiated transaction. As the floor control server cannot send a second update to the implicit floor status subscription until the first is acknowledged, ordinality is maintained.</t><t>If<t indent="0" pn="section-6.2-7">If a client wishes to end its BFCP connection with a floor control server, it isREQUIRED<bcp14>REQUIRED</bcp14> that the client 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., theFocusfocus of the conference informs the floor control server that the client has been kicked out from the conference), it isREQUIRED<bcp14>REQUIRED</bcp14> that the floor control server send a Goodbye message towards the client.</t><!-- Commented out. RFC 5018 behaviour<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 generating "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 are used forunreliable transportBFCP over UDP. As described in <xref target="udp_transport" format="default" sectionFormat="of" derivedContent="Section 6.2"/>, within the same BFCP connection, every entity -- client or server -- is only allowed to send one request at a time, and await the acknowledging response. This way, at most one datagram is sent per RTT given the message isexplicitlynotsupported, cf. anchor="sec:scope:info". Inlost during transmission. If theunlikely case we need UDP/DTLS support outside offer/answer, a RFC5018bismessage isneeded. <t>RFC 5018lost, the request retransmission timer T1 specified in <xreftarget="RFC5018"/> specifies howtarget="timers_retrans" format="default" sectionFormat="of" derivedContent="Section 8.3.1"/> will fire, and the message is retransmitted up toestablish a TCP connectionthree times, in addition toa floor control server outsidethecontextoriginal transmission ofan offer/answer exchange. When using UDPthesamemessage. The default initial interval <bcp14>MUST</bcp14> be setof datato 500 ms, but isneeded for a BFCP connectionadjusted dynamically aslisteddescribed in <xreftarget="RFC5018"/>, Section 3, i.e. transport address of the server, the conference identifier, and the user identifier. The procedures and considerations 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 when 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 control server that is configured to require DTLS MUST request the use of DTLS this way. The recommendations for authentication in <xref target="RFC5018"/>, Section 5 and the security considerations in <xref target="RFC5018"/>, Section 6 also apply when an unreliable transport is used, both for certificate-based server authentication and for client authentication based on a pre-shared secret.</t> --> <section anchor="congestion" 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 over UDP. As described in <xref target="udp_transport"/>, within the same BFCP connection, every entity - client or server - is only allowed to send one request at 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 message is lost, the request retransmission timer T1 specified in <xref target="timers_retrans"/> will fire and the message is retransmitted up to three times, in addition to the original transmission of the message. The default initial interval MUST be set to 500ms, but is adjusted dynamically as described in <xref target="timers_retrans"/>.target="timers_retrans" format="default" sectionFormat="of" derivedContent="Section 8.3.1"/>. The intervalMUST<bcp14>MUST</bcp14> be doubled after each retransmission attempt. This is similar to the specification of the timer A and its initial value T1 in SIP as described inSection 17.1.1.2 of<xreftarget="RFC3261"/>,target="RFC3261" section="17.1.1.2" sectionFormat="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 protocol is not fixed from one transaction to another.</t> </section> <section anchor="icmp"title="ICMPnumbered="true" toc="include" removeInRFC="false" pn="section-6.2.2"> <name slugifiedName="name-icmp-error-handling">ICMP ErrorHandling"> <t>ICMPHandling</name> <t indent="0" pn="section-6.2.2-1">ICMP is not usable when BFCP is running over an unreliable transport due to risks associated with off-path attacks. Any ICMP messages associated with BFCP running over an unreliable transportMUST<bcp14>MUST</bcp14> be ignored.</t> </section> <section anchor="fragmentation_handling"title="Fragmentation Handling"> <t>Whennumbered="true" toc="include" removeInRFC="false" pn="section-6.2.3"> <name slugifiedName="name-fragmentation-handling">Fragmentation Handling</name> <t indent="0" pn="section-6.2.3-1">When using UDP, a single BFCP message could be fragmented at the IP layer if its overall size exceeds the path MTU of the network. To avoid this happening at the IP layer, a fragmentation scheme for BFCP is defined below.</t><t>BFCP<t indent="0" pn="section-6.2.3-2">BFCP is designed for achieving small message size, due to the binary encoding as described in <xreftarget="sec:intro"/>.target="sec_intro" format="default" sectionFormat="of" derivedContent="Section 1"/>. The fragmentation scheme is therefore deliberately kept simple and straightforward, since the probability of fragmentation of BFCP messagesbeing requiredis small. By design, the fragmentation scheme does not acknowledge individual BFCP message fragments. The whole BFCP message is acknowledged if received completely.</t><t>BFCP<t indent="0" pn="section-6.2.3-3">BFCP entitiesSHOULD<bcp14>SHOULD</bcp14> consider the path MTU size available between the sender and the receiver andMAY<bcp14>MAY</bcp14> run MTU discovery, such as<xref target="RFC1191"/><xref target="RFC1981"/><xref target="RFC4821"/>,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>When<t indent="0" pn="section-6.2.3-4">When transmitting a BFCP message with a size greater than the path MTU, the senderMUST<bcp14>MUST</bcp14> fragment the message into a series of N contiguous data ranges. The size of each of these N messagesMUST<bcp14>MUST</bcp14> be smaller than the path MTU to help prevent fragmentation overlap attacks. The value for N is defined as ceil((message size--- COMMON-HEADER size) / (path MTU size--- COMMON-HEADER size)), where ceil is the integer ceilingfunctionfunction, and the COMMON-HEADER size includes the Fragment Offset and Fragment Length fields. The sender then creates N BFCP fragment messages (one for each data range) with the same Transaction ID. The size of each of these N messages, with the COMMON-HEADER included,MUST<bcp14>MUST</bcp14> be smaller than the path MTU. The F flag in the COMMON-HEADER in all the fragments is set to indicate fragmentation of the BFCP message.</t><t>For<t indent="0" pn="section-6.2.3-5">For each of thesefragmentsfragments, the Fragment 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 previous fragments, excluding thecommon header.COMMON-HEADER. The Fragment Length contains the length of the fragment itself, also excluding thecommon header.COMMON-HEADER. Note that the Payload Length field contains the length of the entire, unfragmented message.</t><t>When<t indent="0" pn="section-6.2.3-6">When a BFCP implementation receives a BFCP message fragment, itMUST<bcp14>MUST</bcp14> buffer the fragment until either 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 the fragmentsforof the message have been received.</t><t>If<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 <xreftarget="timers"/>.target="timers" format="default" sectionFormat="of" derivedContent="Section 8.3"/>. If the acknowledgement message sent by the receiver is lost, then the entire message will be resent by the sender. The receiverMUST<bcp14>MUST</bcp14> then retransmit the acknowledgement. The receiverMAY<bcp14>MAY</bcp14> discard an incomplete buffer utilizing the Response Retransmission Timer, starting the timer after the receipt of the first fragment.</t><t><list style="empty"> <t>A<aside pn="section-6.2.3-8"> <t indent="0" pn="section-6.2.3-8.1">A Denial of Service (DoS) attack utilizing the fragmentation scheme described above is mitigated by the fact that 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 they arrive. To make DoS attacks with spoofed IP addresses difficult, BFCP entitiesSHOULD<bcp14>SHOULD</bcp14> use the cookie exchange mechanism in DTLS <xreftarget="RFC6347"/>.</t> </list></t> <t>Whentarget="RFC6347" format="default" sectionFormat="of" derivedContent="8"/>.</t> </aside> <t indent="0" pn="section-6.2.3-9">When deciding the size of the message fragmentsizebased on path MTU, the BFCP fragmentation handling should take into account how the DTLS record framing expands the datagram size as described inSection 4.1.1.1 of<xreftarget="RFC6347"/>.</t>target="RFC6347" section="4.1.1.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6347#section-4.1.1.1" derivedContent="8"/>.</t> </section> <section anchor="nat_traversal"title="NAT Traversal"> <t>Onenumbered="true" toc="include" removeInRFC="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 benefitswhenof using UDP for BFCP communication is the ability to leverage the existing NAT traversal infrastructure and strategies deployed to facilitate transport of the media associated with the video conferencing sessions. Depending on the given deployment, this infrastructure typically includes some subset ofICE <xref target="RFC5245"/>.</t> <t>InInteractive Connectivity Establishment (ICE) <xref target="RFC8445" format="default" sectionFormat="of" derivedContent="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 areRECOMMENDED<bcp14>RECOMMENDED</bcp14> to use STUN <xreftarget="RFC5389"/>target="RFC5389" format="default" sectionFormat="of" derivedContent="14"/> Binding Indication forkeep-alives,keepalives, as described for ICE <xreftarget="RFC5245"/>. Section 6.7 of <xref target="RFC5763"/>target="RFC8445" 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 recommendations for middlebox interaction when DTLS is used.</t><t><list style="empty"> <t>Informational note:<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. thecf. the Ver field in <xreftarget="sec:format:common"/>,target="sec_format_common" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, it isstraight forwardstraightforward to distinguish between STUN and BFCP packets even without checking the STUN magic cookie <xreftarget="RFC5389"/>.</t> </list></t> <t>Intarget="RFC5389" format="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 areRECOMMENDED<bcp14>RECOMMENDED</bcp14> to use symmetric ports for sending and receiving BFCP packets, as recommended forRTP/RTCPRTP/RTP Control Protocol (RTCP) <xreftarget="RFC4961"/>.</t>target="RFC4961" format="default" sectionFormat="of" derivedContent="13"/>.</t> </section> </section> </section> <sectiontitle="Lower-Layer Security" anchor="sec:lower-security"> <t>BFCPanchor="sec_lower-security" numbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-lower-layer-security">Lower-Layer Security</name> <t indent="0" pn="section-7-1">BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs)MUST<bcp14>MUST</bcp14> support TLS for transport over TCP <xreftarget="RFC5246"/>target="RFC8446" format="default" sectionFormat="of" derivedContent="11"/> andMUST<bcp14>MUST</bcp14> support DTLS <xreftarget="RFC6347"/>target="RFC6347" format="default" sectionFormat="of" derivedContent="8"/> for transport over UDP. Any BFCP entityMAY<bcp14>MAY</bcp14> support other security mechanisms.</t><t>BFCP<t indent="0" pn="section-7-2">BFCP entitiesMUST<bcp14>MUST</bcp14> support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite <xreftarget="RFC5246"/>target="RFC5246" format="default" sectionFormat="of" derivedContent="7"/> for backwards compatibility with existing implementations of RFC 4582. In accordance with the recommendations and guidelines in <xreftarget="RFC7525"/>,target="RFC7525" format="default" sectionFormat="of" derivedContent="30"/>, BFCP entitiesSHOULD<bcp14>SHOULD</bcp14> support the following cipher suites:</t><t><list style="symbols"> <t>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</t> <t>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</t> <t>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</t> <t>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</t> </list></t> </section> <section title="Protocol Transactions" anchor="sec:transactions"> <t>In<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-3"> <li pn="section-7-3.1">TLS_DHE_RSA_WITH_AES_128_GCM_SHA256</li> <li pn="section-7-3.2">TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</li> <li pn="section-7-3.3">TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</li> <li pn="section-7-3.4">TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</li> </ul> </section> <section anchor="sec_transactions" numbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-protocol-transactions">Protocol Transactions</name> <t indent="0" pn="section-8-1">In BFCP, there are two types of transactions: client-initiated transactions and server-initiated transactions.</t><t>Client-initiated<t indent="0" pn="section-8-2">Client-initiated transactions consist of a request from a client to a floor control server and a response from the floor control server to the client.</t><t>Server-initiated<t indent="0" pn="section-8-3">Server-initiated transactions have different requirements and behavior depending on underlying transport:</t><t><list style="hanging"> <t>When<ul empty="true" spacing="normal" bare="false" indent="3" pn="section-8-4"> <li pn="section-8-4.1">When using a reliable transport, server-initiated transactions consist of a single message from a floor control server to a client (notifications). They do not trigger anyresponse.</t> <t>Whenresponse.</li> <li pn="section-8-4.2">When using an unreliable transport, server-initiated transactions consist of a request from a floor control server to a client and a response from the client to the floor controlserver.</t> </list></t> <t>Whenserver.</li> </ul> <t indent="0" pn="section-8-5">When using BFCP over an unreliable transport, retransmission timer T1 (see <xreftarget="timers"/>) MUSTtarget="timers" format="default" sectionFormat="of" derivedContent="Section 8.3"/>) <bcp14>MUST</bcp14> be used for all requests until the transaction is completed. Note that while T1 varies over time, it remains constant for the duration of a given transaction and is only updated at the completion of a transaction.</t> <sectiontitle="Client Behavior" anchor="sec:transactions:client"> <t>Aanchor="sec_transactions_client" numbered="true" toc="include" removeInRFC="false" pn="section-8.1"> <name slugifiedName="name-client-behavior">Client Behavior</name> <t indent="0" pn="section-8.1-1">A client starting a client-initiated transactionMUST<bcp14>MUST</bcp14> set the Conference ID in thecommon headerCOMMON-HEADER of the message to the Conference ID for the conference that the client obtained previously.</t><t>The<t indent="0" pn="section-8.1-2">The clientMUST<bcp14>MUST</bcp14> set the Transaction ID value in thecommon headerCOMMON-HEADER to a number that is different from 0 and thatMUST NOT<bcp14>MUST NOT</bcp14> be reused in another message from the client until a response from the server is received for the transaction. The client uses the Transaction ID value to match this message with the response from the floor control server. When using BFCP over an unreliable transport, it is importantto chooseto choose a Transaction ID value that lets the receiver distinguish thereception ofreception of the next message in a sequence of BFCP messages from aretransmission ofretransmission of a previous message.Therefore,Therefore, BFCP entities using an unreliable transportMUST use<bcp14>MUST</bcp14> use monotonically increasing Transaction ID values (except for wrap-around).</t><t>A<t indent="0" pn="section-8.1-3">A client receiving a server-initiated transaction over an unreliabletransport MUSTtransport <bcp14>MUST</bcp14> copy the Transaction ID from the request received from the server intothe response.</t>the response.</t> </section> <sectiontitle="Server Behavior" anchor="sec:transactions:server"> <t>Aanchor="sec_transactions_server" numbered="true" toc="include" removeInRFC="false" pn="section-8.2"> <name slugifiedName="name-server-behavior">Server Behavior</name> <t indent="0" pn="section-8.2-1">A floor control server sending a response within a client-initiated transactionMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the request received from the client into the response.</t><t>Server-initiated<t indent="0" pn="section-8.2-2">Server-initiated transactionsMUST<bcp14>MUST</bcp14> contain a Transaction ID equal to0zero when BFCP is used over a reliable transport. Over an unreliable transport, the Transaction ID shall have the same properties as for client-initiated transactions. The server uses the Transaction ID value to match this message with the response from the floor participant or floor chair.</t> </section> <section anchor="timers"title="Timers"> <t>Whennumbered="true" toc="include" removeInRFC="false" pn="section-8.3"> <name slugifiedName="name-timers">Timers</name> <t indent="0" pn="section-8.3-1">When BFCP entities are communicating over an unreliable transport, two retransmission timers are employed to help mitigateagainstthe loss of datagrams. Retransmission and response caching are not required when BFCP entities communicate over a reliable transport.</t> <section anchor="timers_retrans"title="Requestnumbered="true" toc="include" removeInRFC="false" pn="section-8.3.1"> <name slugifiedName="name-request-retransmission-time">Request Retransmission Timer,T1"> <t>T1T1</name> <t indent="0" pn="section-8.3.1-1">T1 is a timer that schedules retransmission of a request until an appropriate response is received or until the maximum number of retransmissionshavehas occurred. The timer is computed using the smoothed round-trip time algorithmdefinddefined in <xreftarget="RFC2988"/>target="RFC6298" format="default" sectionFormat="of" derivedContent="2"/> with an initial retransmission timeout (RTO) value of500ms500 ms and clock granularity (G) of100ms.100 ms. In contrast to step 2.4 ofSection 2 of<xreftarget="RFC2988"/>,target="RFC6298" section="2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6298#section-2" derivedContent="2"/>, if the computed value of RTO is less than500ms,500 ms, then RTO shall be set to500ms.500 ms. Timer T1MUST<bcp14>MUST</bcp14> be adjusted with the reception of a response to each request transmitted in order to compute an accurate RTO value, which is the effective T1 value. The RTT value R is the time in milliseconds from thepointtime when a request is transmitted to the time the initial response to that request is received. Responses to retransmitted packetsMUST NOT<bcp14>MUST NOT</bcp14> be used to recompute the RTO value, as one cannot determine if a response is to an initial or retransmitted request. If T1 always expires on the initial transmission of a new request, this would suggest the recommended initial T1 (and RTO) value is too low andSHOULD<bcp14>SHOULD</bcp14> be increased by doubling the initial values of T1 (and RTO) until T1 does not expire when sending a new request.</t><t>When<t indent="0" pn="section-8.3.1-2">When retransmitting a request, timer T1 is doubled with each retransmission, failing after three unacknowledged retransmission attempts.</t><t>If<t indent="0" pn="section-8.3.1-3">If a valid response is not received for a client- or server-initiated transaction, the implementationMUST<bcp14>MUST</bcp14> consider the BFCP connection as broken. ImplementationsSHOULD<bcp14>SHOULD</bcp14> follow the reestablishment procedure described insection 6.</t><xref target="sec_transport" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t> </section> <section anchor="timers_cache"title="Responsenumbered="true" toc="include" removeInRFC="false" pn="section-8.3.2"> <name slugifiedName="name-response-retransmission-tim">Response Retransmission Timer,T2"> <t>T2T2</name> <t indent="0" pn="section-8.3.2-1">T2 is a timer that, when fired, signals 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 request 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 by replaying the cached response,whilstwhile that value is retained until the timer has fired. Refer to <xreftarget="fragmentation_handling"/>target="fragmentation_handling" format="default" sectionFormat="of" derivedContent="Section 6.2.3"/> forthe rolethistimer hastimer's role in the fragmentation handling scheme.</t> </section> <section anchor="timers_values"title="Timer Values"> <t>Thenumbered="true" toc="include" removeInRFC="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 different timers required when BFCP entities communicate over an unreliable transport.</t><texttable<table anchor="timertable"title="Timers"> <ttcol align='center'>Timer</ttcol> <ttcol align='left'>Description</ttcol> <ttcol align='center'>Value/s</ttcol> <c>T1</c> <c>Initialalign="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 retransmissiontimer</c> <c>0.5s (initial)</c> <c>T2</c> <c>Responsetimer</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 retransmissiontimer</c> <c>(T1*2^4)*1.25</c> </texttable> <t></t> <t>Thetimer</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 is500ms,500 ms, which is an estimate of the RTT for completing the transaction. Computation of this value follows the procedures described in <xreftarget="timers_retrans"/>,target="timers_retrans" format="default" sectionFormat="of" derivedContent="Section 8.3.1"/>, which includes exponential backoffs on retransmissions.</t><t>T2 MUST<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 accommodate network latency between BFCP entities, processing delays, etc.</t> </section> </section> </section> <sectiontitle="Authentication and Authorization" anchor="sec:auth"> <t>BFCPanchor="sec_auth" numbered="true" toc="include" removeInRFC="false" pn="section-9"> <name slugifiedName="name-authentication-and-authoriz">Authentication and Authorization</name> <t indent="0" pn="section-9-1">BFCP clientsSHOULD<bcp14>SHOULD</bcp14> authenticate the floor control server before sending any BFCP message to it or accepting any BFCP message from it. Similarly, floor control serversSHOULD<bcp14>SHOULD</bcp14> authenticate a client before accepting any BFCP message from it or sending any BFCP message to it.</t><t>If<t indent="0" pn="section-9-2">If the signaling or control protocol traffic used to set up the conference is authenticated and confidentiality and integrity protected, and the extensions in this document are supported, the BFCP clientsMUST<bcp14>MUST</bcp14> authenticate the floor controlserverserver, and the floor control serversMUST<bcp14>MUST</bcp14> authenticate the client before communicating as described above. Note that BFCP entities supporting only the <xreftarget="RFC4582"/>target="RFC4582" format="default" sectionFormat="of" derivedContent="3"/> subset may not comply with this mandatory authentication requirement.</t><t>BFCP<t indent="0" pn="section-9-3">BFCP supports TLS/DTLS mutual authentication between clients and floor control servers, as specified in <xreftarget="sec:auth:tls"/>.target="sec_auth_tls" format="default" sectionFormat="of" derivedContent="Section 9.1"/>. This is theRECOMMENDED<bcp14>RECOMMENDED</bcp14> authentication mechanism in BFCP.</t><t>Note<t indent="0" pn="section-9-4">Note that future extensions may define additional authentication mechanisms.</t><t>In<t indent="0" pn="section-9-5">In addition to authenticating BFCP messages, floor control servers need to authorize them. On receiving an authenticated BFCP message, the floor control server checks whether the client sending the message is authorized. If the client is not authorized to perform the operation being requested, the floor control server generates an Error message, as described in <xreftarget="sec:server:error"/>,target="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>, with anErrorerror code with a value of 5 (Unauthorized Operation). Messages from a client that cannot be authorizedMUST NOT<bcp14>MUST NOT</bcp14> be processed further.</t> <sectiontitle="TLS/DTLSanchor="sec_auth_tls" numbered="true" toc="include" removeInRFC="false" pn="section-9.1"> <name slugifiedName="name-tls-dtls-based-mutual-authe">TLS/DTLS Based MutualAuthentication" anchor="sec:auth:tls"> <t>BFCPAuthentication</name> <t indent="0" pn="section-9.1-1">BFCP supports TLS/DTLS based mutual authentication between clients and floor control servers. If TLS/DTLS is used, an initial integrity-protected channel isREQUIRED<bcp14>REQUIRED</bcp14> between the client and the floor control server that can be used to exchange their certificates (whichMAY<bcp14>MAY</bcp14> be self-signed certificates) or, more commonly, the fingerprints of these certificates. These certificates are used at TLS/DTLS establishment time.</t><t><list style="hanging"> <t>The<aside pn="section-9.1-2"> <t indent="0" pn="section-9.1-2.1">The implementation of such an integrity-protected channel using SIP and the SDP offer/answer model is described in <xreftarget="I-D.ietf-bfcpbis-rfc4583bis"/>.</t> </list></t> <t>BFCPtarget="RFC8856" format="default" sectionFormat="of" derivedContent="12"/>.</t> </aside> <t indent="0" pn="section-9.1-3">BFCP messages received over an authenticated TLS/DTLS connection are considered authenticated. A floor control server that receives a BFCP message over TCP/UDP (no TLS/DTLS)MAY<bcp14>MAY</bcp14> request the use of TLS/DTLS by generating an Error message, as described in <xreftarget="sec:server:error"/>,target="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>, with anErrorerror code with a value of 9 (Use TLS) or a value of 11 (Use DTLS) respectively. Clients configured to require the use of TLS/DTLSMUST<bcp14>MUST</bcp14> ignore unauthenticated messages.</t><t>Note<t indent="0" pn="section-9.1-4">Note that future extensions may define additional authentication mechanisms that may not require an initial integrity-protected channel (e.g., authentication based on certificates signed by a certificate authority).</t><t>As<t indent="0" pn="section-9.1-5">As described in <xreftarget="sec:auth"/>,target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/>, floor control servers need to perform authorization before processing any message. In particular, the floor control serverMUST<bcp14>MUST</bcp14> check that messages arriving over a given authenticated TLS/DTLS connection use an authorized User ID (i.e., a User ID that the user that established the authenticated TLS/DTLS connection is allowed to use).</t> </section> </section> <sectiontitle="Flooranchor="sec_participant" numbered="true" toc="include" removeInRFC="false" pn="section-10"> <name slugifiedName="name-floor-participant-operation">Floor ParticipantOperations" anchor="sec:participant"> <t>ThisOperations</name> <t indent="0" pn="section-10-1">This section specifies how floor participants can perform different operations, such as requesting a floor, using the protocol elements described in earlier sections. <xreftarget="sec:chair"/>target="sec_chair" format="default" sectionFormat="of" derivedContent="Section 11"/> specifies operations that are specific to floor chairs, such as instructing the floor control server to grant or revoke a floor, and <xreftarget="sec:client"/>target="sec_client" format="default" sectionFormat="of" derivedContent="Section 12"/> specifies operations that can be performed by any client (i.e., both floor participants and floor chairs).</t> <sectiontitle="Requesting a Floor" anchor="sec:participant:request"> <t>Aanchor="sec_participant_request" numbered="true" toc="include" removeInRFC="false" pn="section-10.1"> <name slugifiedName="name-requesting-a-floor">Requesting a Floor</name> <t indent="0" pn="section-10.1-1">A floor participant that wishes to request one or more floors does so by sending a FloorRequest message to the floor control server.</t> <sectiontitle="Sendinganchor="sec_participant_request_send" numbered="true" toc="include" removeInRFC="false" pn="section-10.1.1"> <name slugifiedName="name-sending-a-floorrequest-mess">Sending a FloorRequestMessage" anchor="sec:participant:request:send"> <t>TheMessage</name> <t indent="0" pn="section-10.1.1-1">The ABNF in <xreftarget="sec:msg_format:FloorRequest"/>target="sec_msg_format_FloorRequest" format="default" sectionFormat="of" derivedContent="Section 5.3.1"/> describes the attributes that a FloorRequest message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.</t><t>The<t indent="0" pn="section-10.1.1-2">The floor participant sets the Conference ID and the Transaction ID in thecommon headerCOMMON-HEADER following the rules given in <xreftarget="sec:transactions:client"/>.</t> <t>Thetarget="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>.</t> <t indent="0" pn="section-10.1.1-3">The floor participant sets the User ID in thecommon headerCOMMON-HEADER to the floor participant's identifier. If the sender of the FloorRequest message (identified by the User ID) is not the participant that would eventually get the floor (i.e., a third-party floor request), the senderSHOULD<bcp14>SHOULD</bcp14> add a BENEFICIARY-ID attribute to the message identifying the beneficiary of the floor.</t><t><list style="hanging"> <t>Note<aside pn="section-10.1.1-4"> <t indent="0" pn="section-10.1.1-4.1">Note that thename spacenamespace for both the User ID and the Beneficiary ID is the same. That is, a given participant is identified by a single 16-bit value that can be used in the User ID in thecommon headerCOMMON-HEADER and in several attributes: BENEFICIARY-ID, BENEFICIARY-INFORMATION, and REQUESTED-BY-INFORMATION.</t></list></t> <t>The</aside> <t indent="0" pn="section-10.1.1-5">The floor participantMUST<bcp14>MUST</bcp14> 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 package. That is, the floor control server will either grant or deny all the floors in the FloorRequest message.</t><t>The<t indent="0" pn="section-10.1.1-6">The floor participant may use a PARTICIPANT-PROVIDED-INFO attribute to state the reason why the floor or floors are being requested. The Text field in the PARTICIPANT-PROVIDED-INFO attribute is intended for human consumption.</t><t>The<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 PRIORITY attribute.</t> </section> <sectiontitle="Receiving a Response" anchor="sec:client:request:response"> <t>Aanchor="sec_client_request_response" numbered="true" toc="include" 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 server is considered a response to the FloorRequest message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequest message, as described in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving such a response, the floor participant follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor control server authentication.</t><t>The<t indent="0" pn="section-10.1.2-2">The successful processing of a FloorRequest message at the floor control server involves generating one or several FloorRequestStatus messages. The floor participant obtains a Floor Request ID in the Floor Request ID field of a FLOOR-REQUEST-INFORMATION attribute in the first FloorRequestStatus message from the floor control server. Subsequent FloorRequestStatus messages from the floor control server regarding the same floor request 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>The<t indent="0" pn="section-10.1.2-3">The floor participant obtains information about the status of the floor request in the FLOOR-REQUEST-INFORMATION attribute of each of the FloorRequestStatus messages received from the floor control server. This attribute is a grouped attribute, and as such it includes a number of attributes that provide information about the floor request.</t><t>The<t indent="0" pn="section-10.1.2-4">The OVERALL-REQUEST-STATUS attribute provides information about the overall status of the floor request. If the Request Status value is Granted, all the floors that were requested in the FloorRequest message have been granted. If the Request Status value is Denied, all the floors that were requested in the FloorRequest message have been denied. A floor request is considered to be ongoing while it is in the Pending, Accepted, or Granted 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>The<t indent="0" pn="section-10.1.2-5">The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user.</t><t>The<t indent="0" pn="section-10.1.2-6">The FLOOR-REQUEST-STATUS attributes provide information about the status of the floor request as it relates to a particular floor. The STATUS-INFO attribute, if present, provides extra information that the floor participant can display to the user.</t><t>The<t indent="0" pn="section-10.1.2-7">The BENEFICIARY-INFORMATION attribute identifies the beneficiary of the floor request in third-party floor requests. The REQUESTED-BY-INFORMATION attribute need not be present in FloorRequestStatus messages received by the floor participant that requested the floor, as this floor participant is already identified by the User ID in thecommon header.</t> <t>TheCOMMON-HEADER.</t> <t indent="0" pn="section-10.1.2-8">The PRIORITY attribute, when present, contains the priority that was requested by the generator of the FloorRequest message.</t><t>If<t indent="0" pn="section-10.1.2-9">If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.</t> </section> <sectiontitle="Receptionanchor="sec_recept_frsm" numbered="true" toc="include" removeInRFC="false" pn="section-10.1.3"> <name slugifiedName="name-reception-of-a-subsequent-f">Reception of a Subsequent FloorRequestStatusMessage" anchor="sec:recept:frsm"> <t>WhenMessage</name> <t indent="0" pn="section-10.1.3-1">When communicating over an unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participantMUST<bcp14>MUST</bcp14> respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction.</t> </section> </section> <sectiontitle="Cancellinganchor="sec_participant_cancel" numbered="true" toc="include" removeInRFC="false" pn="section-10.2"> <name slugifiedName="name-cancelling-a-floor-request-">Cancelling a Floor Request and Releasing aFloor" anchor="sec:participant:cancel"> <t>AFloor</name> <t indent="0" pn="section-10.2-1">A floor participant that wishes to cancel an ongoing floor request does so by sending a FloorRelease message to the floor control server. The FloorRelease message is also used by floor participants that hold a floor and would like to release it.</t> <sectiontitle="Sendinganchor="sec_participant_cancel_send" numbered="true" toc="include" removeInRFC="false" pn="section-10.2.1"> <name slugifiedName="name-sending-a-floorrelease-mess">Sending a FloorReleaseMessage" anchor="sec:participant:cancel:send"> <t>TheMessage</name> <t indent="0" pn="section-10.2.1-1">The ABNF in <xreftarget="sec:msg_format:FloorRelease"/>target="sec_msg_format_FloorRelease" format="default" sectionFormat="of" derivedContent="Section 5.3.2"/> describes the attributes that a FloorRelease message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.</t><t>The<t indent="0" pn="section-10.2.1-2">The floor participant sets the Conference ID and the Transaction ID in thecommon headerCOMMON-HEADER following the rules given in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. The floor participant sets the User ID in thecommon headerCOMMON-HEADER to the floor participant's identifier.</t><t><list style="empty"> <t>Note<aside pn="section-10.2.1-3"> <t indent="0" pn="section-10.2.1-3.1">Note that the FloorRelease message is used to release a floor or floors that were granted and to cancel ongoing floor requests (from the protocol perspective, both are ongoing floor requests). Using the same message in both situations helps resolve the race condition that occurs when the FloorRelease message and the FloorGrant message cross each other on the wire.</t></list></t> <t>The</aside> <t indent="0" pn="section-10.2.1-4">The floor participant uses the FLOOR-REQUEST-ID that was received in the response to the FloorRequest message that the FloorRelease message is cancelling.</t><t><list style="empty"> <t>Note<aside pn="section-10.2.1-5"> <t indent="0" pn="section-10.2.1-5.1">Note that if the floor participant requested several floors as an atomic operation (i.e., in a single FloorRequest message), all the floors are released as an atomic operation as well (i.e., all are released at the same time).</t></list></t></aside> </section> <sectiontitle="Receiving a Response" anchor="sec:participant:cancel:response"> <t>Aanchor="sec_participant_cancel_response" numbered="true" toc="include" 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 server is considered a response to the FloorRelease message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRelease message, as described in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving such a response, the floor participant follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor control server authentication.</t><t>If<t indent="0" pn="section-10.2.2-2">If the response is a FloorRequestStatus message, the Request Status value in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) will be Cancelled or Released.</t><t>If<t indent="0" pn="section-10.2.2-3">If the response is an Error message, the floor control server could not process the FloorRequest message for some reason, which is described in the Error message.</t><t>It<t indent="0" pn="section-10.2.2-4">It is possible that the FloorRelease 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> <sectiontitle="Chair Operations" anchor="sec:chair"> <t>Thisanchor="sec_chair" numbered="true" toc="include" removeInRFC="false" pn="section-11"> <name slugifiedName="name-chair-operations">Chair Operations</name> <t indent="0" pn="section-11-1">This section specifies how floor chairs can instruct the floor control server to grant or revoke a floor using the protocol elements described in earlier sections.</t><t>Floor<t indent="0" pn="section-11-2">Floor chairs that wish to send instructions to a floor control server do so by sending a ChairAction message.</t> <sectiontitle="Sendinganchor="sec_chair_send" numbered="true" toc="include" removeInRFC="false" pn="section-11.1"> <name slugifiedName="name-sending-a-chairaction-messa">Sending a ChairActionMessage" anchor="sec:chair:send"> <t>TheMessage</name> <t indent="0" pn="section-11.1-1">The ABNF in <xreftarget="sec:msg_format:ChairAction"/>target="sec_msg_format_ChairAction" format="default" sectionFormat="of" derivedContent="Section 5.3.9"/> describes the attributes that a ChairAction message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.</t><t>The<t indent="0" pn="section-11.1-2">The floor chair sets the Conference ID and the Transaction ID in thecommon headerCOMMON-HEADER following the rules given in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. The floor chair sets the User ID in thecommon headerCOMMON-HEADER to the floor chair's identifier.</t><t>The<t indent="0" pn="section-11.1-3">The ChairAction message contains instructions that apply to one or more floors within a particular floor request. The floor or floors are identified by the FLOOR-REQUEST-STATUS attributes and the floor request is identified by the FLOOR-REQUEST-INFORMATION-HEADER, which are carried in the ChairAction message.</t><t>For<t indent="0" pn="section-11.1-4">For example, if a floor request consists of two floors that depend on different floor chairs, each floor chair will grant its floor within the floor request. Once both chairs have granted their floor, the floor control server will grant the floor request as a whole. On the other hand, if one of the floor chairs denies its floor, the floor control server will deny the floor request as a whole, regardless of the other floor chair's decision.</t><t>The<t indent="0" pn="section-11.1-5">The floor chair provides the new status 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 chairMAY<bcp14>MAY</bcp14> use the Queue Position field to provide a queue position for the floor request. If the floor chair does not wish to provide a queue position, all the bits of the Queue Position fieldMUST<bcp14>MUST</bcp14> be set to zero. The floor chairMUST<bcp14>MUST</bcp14> use the Status Revoked to revoke a floor that was granted (i.e., Granted status) andMUST<bcp14>MUST</bcp14> use the Status Denied to reject floor requests in any other status (e.g., Pending and Accepted).</t><t>The<t indent="0" pn="section-11.1-6">The floor chairMAY<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 request is Accepted, the floor chair can use the Queue Position field to provide a queue position for the floor request.</t><t><list style="hanging"> <t>Note<aside pn="section-11.1-7"> <t indent="0" pn="section-11.1-7.1">Note that a particular floor control server can implement a different queue for each floor containing all the floor requests that relate to that particular floor, a general queue for all floor requests, or both. Also note that a floor request can involve several floors and that a ChairAction message can only deal with a subset of these floors (e.g., if a single floor chair is not authorized to manage all the floors). In this case, the floor control server will combine the instructions received from the different floor chairs in FLOOR-REQUEST-STATUS attributes to come up with the overall status of the floor request.</t><t>Note<t indent="0" pn="section-11.1-7.2">Note that, while the action of a floor chair may communicate information in the OVERALL-REQUEST-STATUS attribute, the floor control server may override, modify, or ignore this field's content.</t></list></t> <t>The</aside> <t indent="0" pn="section-11.1-8">The floor chairMAY<bcp14>MAY</bcp14> include STATUS-INFO attributes to state the reason why the floor or floors are being accepted, granted, or revoked. The Text in the STATUS-INFO attribute is intended for human consumption.</t> </section> <sectiontitle="Receiving a Response" anchor="sec:chair:instruct:response"> <t>Aanchor="sec_chair_instruct_response" numbered="true" toc="include" removeInRFC="false" pn="section-11.2"> <name slugifiedName="name-receiving-a-response-3">Receiving a Response</name> <t indent="0" pn="section-11.2-1">A message from the floor control server is considered a response to the ChairAction message if the message from the server has the same Conference ID, Transaction ID, and User ID as the ChairAction message, as described in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving such a response, the floor chair follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor control server authentication.</t><t>A<t indent="0" pn="section-11.2-2">A ChairActionAck message from the floor control server confirms that the floor control server has accepted the ChairAction message. An Error message indicates that the floor control server could not process the ChairAction message for some reason, which is described in the Error message.</t> </section> </section> <sectiontitle="Generalanchor="sec_client" numbered="true" toc="include" removeInRFC="false" pn="section-12"> <name slugifiedName="name-general-client-operations">General ClientOperations" anchor="sec:client"> <t>ThisOperations</name> <t indent="0" pn="section-12-1">This section specifies operations that can be performed by any client. That is, they are not specific to floor participants or floor chairs. They can be performed by both.</t> <sectiontitle="Requestinganchor="sec_client_floorinfo" numbered="true" toc="include" removeInRFC="false" pn="section-12.1"> <name slugifiedName="name-requesting-information-abou">Requesting Information aboutFloors" anchor="sec:client:floorinfo"> <t>AFloors</name> <t indent="0" pn="section-12.1-1">A client can obtain information about the status of a floor or floors in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section. </t><t>Clients<t indent="0" pn="section-12.1-2">Clients request information about the status of one or several floors by sending a FloorQuery message to the floor control server.</t> <sectiontitle="Sendinganchor="sec_client_floorinfo_send" numbered="true" toc="include" removeInRFC="false" pn="section-12.1.1"> <name slugifiedName="name-sending-a-floorquery-messag">Sending a FloorQueryMessage" anchor="sec:client:floorinfo:send"> <t>TheMessage</name> <t indent="0" pn="section-12.1.1-1">The ABNF in <xreftarget="sec:msg_format:FloorQuery"/>target="sec_msg_format_FloorQuery" format="default" sectionFormat="of" derivedContent="Section 5.3.7"/> describes the attributes that a FloorQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.</t><t>The<t indent="0" pn="section-12.1.1-2">The client sets the Conference ID and the Transaction ID in thecommon headerCOMMON-HEADER following the rules given in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. The client sets the User ID in thecommon headerCOMMON-HEADER to the client's identifier.</t><t>The<t indent="0" pn="section-12.1.1-3">The client inserts in the message all the Floor IDs it wants to receive information about. The floor control server will send periodic information about all of these floors. If the client does not want to receive information about 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> <sectiontitle="Receiving a Response" anchor="sec:client:floorinfo:response"> <t>Aanchor="sec_client_floorinfo_response" numbered="true" toc="include" removeInRFC="false" pn="section-12.1.2"> <name slugifiedName="name-receiving-a-response-4">Receiving a Response</name> <t indent="0" pn="section-12.1.2-1">A message from the floor control server is considered a response to the FloorQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorQuery message, as described in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving such a response, the client follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor control server authentication.</t><t>On<t indent="0" pn="section-12.1.2-2">On reception of the FloorQuery message, the floor control serverMUST<bcp14>MUST</bcp14> respond with a FloorStatus message or with an Error message. If the response is a FloorStatus message, it will contain information about one of the floors the client requested information about. If the client did not include any FLOOR-ID attribute in its FloorQuery message (i.e., the client does not want to receive information about any floor any longer), the FloorStatus message from the floor control server will not include any FLOOR-ID attribute either. </t><t>FloorStatus<t indent="0" pn="section-12.1.2-3">FloorStatus messages that carry information about a floor contain a FLOOR-ID attribute that identifies the floor. After this attribute, FloorStatus messages contain information about existing (one or more) floor requests that relate to that floor. The information about each particular floor request is encoded in a FLOOR-REQUEST-INFORMATION attribute. This grouped attribute carries a Floor Request ID that identifies the floor request, followed by a set of attributes that provide information about the floor request.</t><t>After<t indent="0" pn="section-12.1.2-4">After the first FloorStatus, the floor control server will continue sending FloorStatus messages, periodically informing the client about changes on the floors the client requested information about.</t> </section> <sectiontitle="Receptionanchor="sec_recept_fsm" numbered="true" toc="include" removeInRFC="false" pn="section-12.1.3"> <name slugifiedName="name-reception-of-a-subsequent-fl">Reception of a Subsequent FloorStatusMessage" anchor="sec:recept:fsm"> <t>WhenMessage</name> <t indent="0" pn="section-12.1.3-1">When communicating over an unreliable transport and upon receiving a FloorStatus message from a floor control server, the participantMUST<bcp14>MUST</bcp14> respond with a FloorStatusAck message within the transaction failure window to complete the transaction.</t> </section> </section> <sectiontitle="Requestinganchor="sec_client_info" numbered="true" toc="include" removeInRFC="false" pn="section-12.2"> <name slugifiedName="name-requesting-information-about">Requesting Information about FloorRequests" anchor="sec:client:info"> <t>ARequests</name> <t indent="0" pn="section-12.2-1">A client can obtain information about the status of one or several floor requests in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.</t><t>Clients<t indent="0" pn="section-12.2-2">Clients request information about the current status of a floor request by sending a FloorRequestQuery message to the floor control server.</t><t>Requesting<t indent="0" pn="section-12.2-3">Requesting information about a particular floor request is useful in a number of situations. For example, on reception of a FloorRequest message, a floor control server may choose to return FloorRequestStatus messages only when the floor request changes its state (e.g., from Accepted to Granted), but not when the floor request advances in its queue. In this situation, if the user requests it, the floor participant can use a FloorRequestQuery message to poll the floor control server for the status of the floor request.</t> <sectiontitle="Sendinganchor="sec_client_info_send" numbered="true" toc="include" removeInRFC="false" pn="section-12.2.1"> <name slugifiedName="name-sending-a-floorrequestquery">Sending a FloorRequestQueryMessage" anchor="sec:client:info:send"> <t>TheMessage</name> <t indent="0" pn="section-12.2.1-1">The ABNF in <xreftarget="sec:msg_format:FloorRequestQuery"/>target="sec_msg_format_FloorRequestQuery" format="default" sectionFormat="of" derivedContent="Section 5.3.3"/> describes the attributes that a FloorRequestQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.</t><t>The<t indent="0" pn="section-12.2.1-2">The client sets the Conference ID and the Transaction ID in thecommon headerCOMMON-HEADER following the rules given in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. The client sets the User ID in thecommon headerCOMMON-HEADER to the client's identifier.</t><t>The<t indent="0" pn="section-12.2.1-3">The clientMUST<bcp14>MUST</bcp14> insert a FLOOR-REQUEST-ID attribute that identifies the floor request at the floor control server.</t> </section> <sectiontitle="Receiving a Response" anchor="sec:client:info:response"> <t>Aanchor="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 server is considered a response to the FloorRequestQuery message if the message from the floor control server has the same Conference ID, Transaction ID, and User ID as the FloorRequestQuery message, as described in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving such a response, the client follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor control server authentication.</t><t>If<t indent="0" pn="section-12.2.2-2">If the response is a FloorRequestStatus message, the client obtains information about the status of the FloorRequest the client requested information about in a FLOOR-REQUEST-INFORMATION attribute.</t><t>If<t indent="0" pn="section-12.2.2-3">If the response is an Error message, the floor control server could not process the FloorRequestQuery message for some reason, which is described in the Error message.</t> </section> </section> <sectiontitle="Requestinganchor="sec_client_user" numbered="true" toc="include" removeInRFC="false" pn="section-12.3"> <name slugifiedName="name-requesting-information-about-">Requesting Information about aUser" anchor="sec:client:user"> <t>AUser</name> <t indent="0" pn="section-12.3-1">A client can obtain information about a participant and the floor requests related to this participant in different ways, which include using BFCP and using out-of-band mechanisms. Clients using BFCP to obtain such information use the procedures described in this section.</t><t>Clients<t indent="0" pn="section-12.3-2">Clients request information about a participant and the floor requests related to this participant by sending a UserQuery message to the floor control server.</t><t>This<t indent="0" pn="section-12.3-3">This functionality may be useful for floor 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 useful to request information about itself. For example, a floor participant, after experiencing connectivity problems (e.g., its TCP connection with the floor control server was down for a while and eventually was re-established), may need to request information about all the floor requests associated to itself that still exist.</t> <sectiontitle="Sendinganchor="sec_client_user_send" numbered="true" toc="include" removeInRFC="false" pn="section-12.3.1"> <name slugifiedName="name-sending-a-userquery-message">Sending a UserQueryMessage" anchor="sec:client:user:send"> <t>TheMessage</name> <t indent="0" pn="section-12.3.1-1">The ABNF in <xreftarget="sec:msg_format:UserQuery"/>target="sec_msg_format_UserQuery" format="default" sectionFormat="of" derivedContent="Section 5.3.5"/> describes the attributes that a UserQuery message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory, and which ones are optional.</t><t>The<t indent="0" pn="section-12.3.1-2">The client sets the Conference ID and the Transaction ID in thecommon headerCOMMON-HEADER following the rules given in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. The client sets the User ID in thecommon headerCOMMON-HEADER to the client's identifier.</t><t>If<t indent="0" pn="section-12.3.1-3">If the floor participant the client is requesting information about is not the client issuing the UserQuery message (which is identified by the User ID in thecommon headerCOMMON-HEADER of the message), the clientMUST<bcp14>MUST</bcp14> insert a BENEFICIARY-ID attribute.</t> </section> <sectiontitle="Receiving a Response" anchor="sec:client:user:response"> <t>Aanchor="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 server 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 <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving such a response, the client follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor control server authentication.</t><t>If<t indent="0" pn="section-12.3.2-2">If the response is a UserStatus message, the client obtains information about the floor participant in a BENEFICIARY-INFORMATION grouped attribute and about the status of the floor requests associated with the floor participant in FLOOR-REQUEST-INFORMATION attributes.</t><t>If<t indent="0" pn="section-12.3.2-3">If the response is an Error message, the floor control server could not process the UserQuery message for some reason, which is described in the Error message.</t> </section> </section> <sectiontitle="Obtaininganchor="sec_client_hello" numbered="true" toc="include" removeInRFC="false" pn="section-12.4"> <name slugifiedName="name-obtaining-the-capabilities-">Obtaining the Capabilities of a Floor ControlServer" anchor="sec:client:hello"> <t>AServer</name> <t indent="0" pn="section-12.4-1">A client that wishes to obtain the capabilities of a floor control server does so by sending a Hello message to the floor control server.</t> <sectiontitle="Sendinganchor="sec_client_hello_send" numbered="true" toc="include" removeInRFC="false" pn="section-12.4.1"> <name slugifiedName="name-sending-a-hello-message">Sending a HelloMessage" anchor="sec:client:hello:send"> <t>TheMessage</name> <t indent="0" pn="section-12.4.1-1">The ABNF in <xreftarget="sec:msg_format:Hello"/>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 ones are optional.</t><t>The<t indent="0" pn="section-12.4.1-2">The client sets the Conference ID and the Transaction ID in thecommon headerCOMMON-HEADER following the rules given in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. The client sets the User ID in thecommon headerCOMMON-HEADER to the client's identifier.</t> </section> <sectiontitle="Receiving Responses" anchor="sec:client:hello:responses"> <t>Aanchor="sec_client_hello_responses" numbered="true" toc="include" removeInRFC="false" pn="section-12.4.2"> <name slugifiedName="name-receiving-responses">Receiving Responses</name> <t indent="0" pn="section-12.4.2-1">A message from the floor control server 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 User ID as the Hello message, as described in <xreftarget="sec:transactions:client"/>.target="sec_transactions_client" format="default" sectionFormat="of" derivedContent="Section 8.1"/>. On receiving such a response, the client follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to floor control server authentication.</t><t>If<t indent="0" pn="section-12.4.2-2">If the response is a HelloAck message, the floor control server could process the Hello message successfully. The SUPPORTED-PRIMITIVES and SUPPORTED-ATTRIBUTES attributes indicate which primitives and attributes, respectively, are supported by the server.</t><t>If<t indent="0" pn="section-12.4.2-3">If the response is an Error message, the floor control server could not process the Hello message for some reason, which is described in the Error message.</t> </section> </section> </section> <sectiontitle="Flooranchor="sec_server" numbered="true" toc="include" removeInRFC="false" pn="section-13"> <name slugifiedName="name-floor-control-server-operat">Floor Control ServerOperations" anchor="sec:server"> <t>ThisOperations</name> <t indent="0" pn="section-13-1">This section specifies how floor control servers can perform different operations, such as granting a floor, using the protocol elements described in earlier sections.</t><t>On<t indent="0" pn="section-13-2">On reception of a message from a client, the floor control serverMUST<bcp14>MUST</bcp14> check whether the value of thePrimitiveprimitive is supported. If it is not, the floor control serverMUST<bcp14>MUST</bcp14> send an Error message, as described in <xreftarget="sec:server:error"/>,target="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>, with ErrorcodeCode 3 (Unknown Primitive).</t><t>On<t indent="0" pn="section-13-3">On reception of a message from a client, the floor control serverMUST<bcp14>MUST</bcp14> check whether the value of the Conference ID matched an existing conference. If it does not, the floor control serverMUST<bcp14>MUST</bcp14> send an Error message, as described in <xreftarget="sec:server:error"/>,target="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>, with ErrorcodeCode 1 (Conferencedoes notDoes Not Exist).</t><t>On<t indent="0" pn="section-13-4">On reception of a message from a client, the floor control server follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to the authentication of the message.</t><t>On<t indent="0" pn="section-13-5">On reception of a message from a client, the floor control serverMUST<bcp14>MUST</bcp14> check whether it understands all the mandatory ('M' bit set) attributes in the message. If the floor control server does not understand all of them, the floor control serverMUST<bcp14>MUST</bcp14> send an Error message, as described in <xreftarget="sec:server:error"/>,target="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>, with ErrorcodeCode 4 (Unknown Mandatory Attribute). The Error messageSHOULD<bcp14>SHOULD</bcp14> list the attributes that were not understood.</t> <sectiontitle="Receptionanchor="sec_server_request" numbered="true" toc="include" removeInRFC="false" pn="section-13.1"> <name slugifiedName="name-reception-of-a-floorrequest">Reception of a FloorRequestMessage" anchor="sec:server:request"> <t>OnMessage</name> <t indent="0" pn="section-13.1-1">On reception of a FloorRequest message, the floor control server follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to client authentication and authorization. If while processing the FloorRequest message, the floor control server encounters an error, itMUST<bcp14>MUST</bcp14> generate an Error response following the procedures described in <xreftarget="sec:server:error"/>.</t> <t><list style="hanging"> <t>BFCPtarget="sec_server_error" 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 participant 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 per floor participant (e.g., one) can use Error Code 8 (You have Already Reached the Maximum Number of Ongoing Floor Requests forthisThis Floor) to inform the floor participant.</t></list></t> <t>When</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 control serverMUST<bcp14>MUST</bcp14> respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.</t> <sectiontitle="Generatinganchor="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 FloorRequestStatusMessage" anchor="sec:server:request:first"> <t>TheMessage</name> <t indent="0" pn="section-13.1.1-1">The successful processing of a FloorRequest message by a floor control server involves generating one or several FloorRequestStatus messages, the first of whichSHOULD<bcp14>SHOULD</bcp14> 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 from a chair is needed), itSHOULD<bcp14>SHOULD</bcp14> use a Request Status value of Pending in the OVERALL-REQUEST-STATUS attribute (within the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message it generates.</t><t><list style="hanging"> <t>The<aside pn="section-13.1.1-2"> <t indent="0" pn="section-13.1.1-2.1">The policy that a floor control 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 another may contact a human acting as a chair every time a decision needs to be made.</t></list></t> <t>The</aside> <t indent="0" pn="section-13.1.1-3">The floor control serverMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the FloorRequest into the FloorRequestStatus, as described in <xreftarget="sec:transactions:server"/>.target="sec_transactions_server" format="default" sectionFormat="of" derivedContent="Section 8.2"/>. Additionally, the floor control serverMUST<bcp14>MUST</bcp14> add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.</t><t>The<t indent="0" pn="section-13.1.1-4">The floor control serverMUST<bcp14>MUST</bcp14> assign an identifier that is unique within the conference to this floor request, andMUST<bcp14>MUST</bcp14> insert it in the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute. This identifier will be used by the floor participant (or by a chair or chairs) to refer to this specific floor request in the future.</t><t>The<t indent="0" pn="section-13.1.1-5">The floor control serverMUST<bcp14>MUST</bcp14> copy the Floor IDs in the FLOOR-ID attributes of the FloorRequest into the FLOOR-REQUEST-STATUS attributes in the FLOOR-REQUEST-INFORMATION grouped attribute. These Floor IDs identify the floors being requested (i.e., the floors associated with this particular floor request).</t><t>The<t indent="0" pn="section-13.1.1-6">The floor control serverSHOULD<bcp14>SHOULD</bcp14> copy (if present) the contents of the BENEFICIARY-ID attribute from the FloorRequest into a BENEFICIARY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute. Additionally, the floor control serverMAY<bcp14>MAY</bcp14> provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.1.1-7">The floor control serverMAY<bcp14>MAY</bcp14> provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.</t><t>The<t indent="0" pn="section-13.1.1-8">The floor control serverMAY<bcp14>MAY</bcp14> 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 attr/ --> <t><list style="empty"> <t>Note<aside pn="section-13.1.1-9"> <t indent="0" pn="section-13.1.1-9.1">Note that this attribute carries the priority requested by the participant. The priority that the floor control server assigns to the floor request depends on the priority requested by the participant and the rights the participant has according to the policy of the conference. For example, a participant that is only allowed to use the Normal priority may request Highest priority for a floor request. In that case, the floor control server would ignore the priority requested by the participant.</t></list></t> <t>The</aside> <t indent="0" pn="section-13.1.1-10">The floor control serverMAY<bcp14>MAY</bcp14> copy (if present) the PARTICIPANT-PROVIDED-INFO attribute from the FloorRequest into the FLOOR-REQUEST-INFORMATION grouped attribute.</t> </section> <sectiontitle="Generationanchor="sec_server_request_subsequent" numbered="true" toc="include" removeInRFC="false" pn="section-13.1.2"> <name slugifiedName="name-generation-of-subsequent-fl">Generation of Subsequent FloorRequestStatusMessages" anchor="sec:server:request:subsequent"> <t>AMessages</name> <t indent="0" pn="section-13.1.2-1">A floor request is considered to be ongoing as long as it is not in the Cancelled, Released, or Revoked states. If the OVERALL-REQUEST-STATUS attribute (inside the FLOOR-REQUEST-INFORMATION grouped attribute) of the first FloorRequestStatus message generated by the floor control server did not indicate any of these states, the floor control server will need to send subsequent FloorRequestStatus messages.</t><t>When<t indent="0" pn="section-13.1.2-2">When the status of the floor request changes, the floor control serverSHOULD<bcp14>SHOULD</bcp14> send new FloorRequestStatus messages with the appropriate Request Status. The floor control serverMUST<bcp14>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 FloorRequestStatus related to the same floor request. (The Floor Request ID identifies the floor request to which the FloorRequestStatus applies.)</t><t>When<t indent="0" pn="section-13.1.2-3">When using BFCP over a reliable transport, the floor control serverMUST<bcp14>MUST</bcp14> set the Transaction ID of subsequent FloorRequestStatus messages to0.zero. When using BFCP over an unreliable transport, the Transaction IDMUST<bcp14>MUST</bcp14> be non-zero and unique in the context of outstanding transactions over an unreliable transport as described in <xreftarget="sec:transactions"/>.</t> <t><list style="hanging"> <t>Thetarget="sec_transactions" format="default" sectionFormat="of" derivedContent="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 control server sends FloorRequestStatus messages is a matter of local policy. A floor control server may choose to send a new FloorRequestStatus message every time the floor request moves in the floor request queue, while another may choose only to send a new FloorRequestStatus message when the floor request is Granted or Denied.</t></list></t> <t>The</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><t><list style="hanging"> <t>Floor<aside pn="section-13.1.2-6"> <t indent="0" pn="section-13.1.2-6.1">Floor participants and floor chairs may request to be informed about the status of a floor following the procedures in <xreftarget="sec:client:floorinfo"/>.target="sec_client_floorinfo" format="default" sectionFormat="of" derivedContent="Section 12.1"/>. 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 <xreftarget="sec:server:floorinfo"/>target="sec_server_floorinfo" format="default" sectionFormat="of" derivedContent="Section 13.5"/> to inform the clients that have requested that information.</t></list></t> <t>The common header</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>The<t indent="0" pn="section-13.1.2-8">The floor control server can discard the state information about a particular floor request when this reaches a status of Cancelled, Released, or Revoked.</t><t>When<t indent="0" pn="section-13.1.2-9">When communicating over an unreliable transport and a FloorRequestStatusAck message is not received within the transaction failure window, the floor control serverMUST<bcp14>MUST</bcp14> retransmit the FloorRequestStatus message according to <xreftarget="udp_transport"/>.</t>target="udp_transport" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.</t> </section> </section> <sectiontitle="Receptionanchor="sec_server_requestinfo" numbered="true" toc="include" removeInRFC="false" pn="section-13.2"> <name slugifiedName="name-reception-of-a-floorrequestq">Reception of a FloorRequestQueryMessage" anchor="sec:server:requestinfo"> <t>OnMessage</name> <t indent="0" pn="section-13.2-1">On reception of a FloorRequestQuery message, the floor control server follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to client authentication and authorization. If while processing the FloorRequestQuery message, the floor control server encounters an error, itMUST<bcp14>MUST</bcp14> generate an Error response following the procedures described in <xreftarget="sec:server:error"/>.</t> <t>Thetarget="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t> <t indent="0" pn="section-13.2-2">The successful processing of a FloorRequestQuery message by a floor control server involves generating a FloorRequestStatus message, whichSHOULD<bcp14>SHOULD</bcp14> be generated as soon as possible.</t><t>When<t indent="0" pn="section-13.2-3">When communicating over an unreliable transport and upon receiving a FloorRequestQuery from a participant, the floor control serverMUST<bcp14>MUST</bcp14> respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.</t><t>The<t indent="0" pn="section-13.2-4">The floor control serverMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the FloorRequestQuery message into the FloorRequestStatus message, as described in <xreftarget="sec:transactions:server"/>.target="sec_transactions_server" format="default" sectionFormat="of" derivedContent="Section 8.2"/>. Additionally, the floor control serverMUST<bcp14>MUST</bcp14> include information about the floor request in the FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus.</t><t>The<t indent="0" pn="section-13.2-5">The floor control serverMUST<bcp14>MUST</bcp14> copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRequestQuery message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.2-6">The floor control serverMUST<bcp14>MUST</bcp14> add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).</t><t>The<t indent="0" pn="section-13.2-7">The floor control serverSHOULD<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 serverMAY<bcp14>MAY</bcp14> provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.2-8">The floor control serverMAY<bcp14>MAY</bcp14> provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.</t><t>The<t indent="0" pn="section-13.2-9">The floor control serverMAY<bcp14>MAY</bcp14> provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.</t><t>The<t indent="0" pn="section-13.2-10">The floor control serverMAY<bcp14>MAY</bcp14> also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request and a STATUS-INFO attribute with extra information about the floor request.</t><t>The<t indent="0" pn="section-13.2-11">The floor control serverMUST<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 control serverMAY<bcp14>MAY</bcp14> provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.</t> </section> <sectiontitle="Receptionanchor="sec_server_userinfo" numbered="true" toc="include" removeInRFC="false" pn="section-13.3"> <name slugifiedName="name-reception-of-a-userquery-me">Reception of a UserQueryMessage" anchor="sec:server:userinfo"> <t>OnMessage</name> <t indent="0" pn="section-13.3-1">On reception of a UserQuery message, the floor control server follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to client authentication and authorization. If while processing the UserQuery message, the floor control server encounters an error, itMUST<bcp14>MUST</bcp14> generate an Error response following the procedures described in <xreftarget="sec:server:error"/>.</t> <t>Thetarget="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t> <t indent="0" pn="section-13.3-2">The successful processing of a UserQuery message by a floor control server involves generating a UserStatus message, whichSHOULD<bcp14>SHOULD</bcp14> be generated as soon as possible.</t><t>When<t indent="0" pn="section-13.3-3">When communicating over an unreliable transport and upon receiving a UserQuery from a participant, the floor control serverMUST<bcp14>MUST</bcp14> respond with a UserStatus message within the transaction failure window to complete the transaction.</t><t>The<t indent="0" pn="section-13.3-4">The floor control serverMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the UserQuery message into the UserStatus message, as described in <xreftarget="sec:transactions:server"/>.</t> <t>Thetarget="sec_transactions_server" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</t> <t indent="0" pn="section-13.3-5">The sender of the UserQuery message is requesting information about all the floor requests associated with a given participant (i.e., the floor requests where the participant is either the beneficiary or the requester). This participant is identified by a BENEFICIARY-ID attribute or, in the absence of a BENEFICIARY-ID attribute, by a the User ID in thecommon headerCOMMON-HEADER of the UserQuery message.</t><t>The<t indent="0" pn="section-13.3-6">The floor control serverMUST<bcp14>MUST</bcp14> copy, if present, the contents of the BENEFICIARY-ID attribute from the UserQuery message into a BENEFICIARY-INFORMATION attribute in the UserStatus message. Additionally, the floor control serverMAY<bcp14>MAY</bcp14> provide the display name and the URI of the participant about which the UserStatus message provides information in this BENEFICIARY-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.3-7">The floor control serverSHOULD<bcp14>SHOULD</bcp14> add to the UserStatus message a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request related to the participant about which the message provides information (i.e., the floor requests where the participant is either the beneficiary or the requester). For each FLOOR-REQUEST-INFORMATION attribute, the floor control server follows the following steps.</t><t>The<t indent="0" pn="section-13.3-8">The floor control serverMUST<bcp14>MUST</bcp14> identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.3-9">The floor control serverMUST<bcp14>MUST</bcp14> add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).</t><t>The<t indent="0" pn="section-13.3-10">The floor control serverSHOULD<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 serverMAY<bcp14>MAY</bcp14> provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.3-11">The floor control serverMAY<bcp14>MAY</bcp14> provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.</t><t>The<t indent="0" pn="section-13.3-12">The floor control serverMAY<bcp14>MAY</bcp14> provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.</t><t>The<t indent="0" pn="section-13.3-13">The floor control serverMAY<bcp14>MAY</bcp14> also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request.</t><t>The<t indent="0" pn="section-13.3-14">The floor control serverMUST<bcp14>MUST</bcp14> include the current status of the floor request in an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The floor control serverMAY<bcp14>MAY</bcp14> add a STATUS-INFO attribute with extra information about the floor request.</t><t>The<t indent="0" pn="section-13.3-15">The floor control serverMAY<bcp14>MAY</bcp14> provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.</t> </section> <sectiontitle="Receptionanchor="sec_server_release" numbered="true" toc="include" removeInRFC="false" pn="section-13.4"> <name slugifiedName="name-reception-of-a-floorrelease">Reception of a FloorReleaseMessage" anchor="sec:server:release"> <t>OnMessage</name> <t indent="0" pn="section-13.4-1">On reception of a FloorRelease message, the floor control server follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to client authentication and authorization. If while processing the FloorRelease message, the floor control server encounters an error, itMUST<bcp14>MUST</bcp14> generate an Error response following the procedures described in <xreftarget="sec:server:error"/>.</t> <t>Thetarget="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t> <t indent="0" pn="section-13.4-2">The successful processing of a FloorRelease message by a floor control server involves generating a FloorRequestStatus message, whichSHOULD<bcp14>SHOULD</bcp14> be generated as soon as possible.</t><t>When<t indent="0" pn="section-13.4-3">When communicating over an unreliable transport and upon receiving a FloorRelease from a participant, the floor control serverMUST<bcp14>MUST</bcp14> respond with a FloorRequestStatus message within the transaction failure window to complete the transaction.</t><t>The<t indent="0" pn="section-13.4-4">The floor control serverMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the FloorRelease message into the FloorRequestStatus message, as described in <xreftarget="sec:transactions:server"/>.</t> <t>Thetarget="sec_transactions_server" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</t> <t indent="0" pn="section-13.4-5">The floor control serverMUST<bcp14>MUST</bcp14> add a FLOOR-REQUEST-INFORMATION grouped attribute to the FloorRequestStatus. The attributes contained in this grouped attribute carry information about the floor request.</t><t>The<t indent="0" pn="section-13.4-6">The FloorRelease message identifies the floor request it applies to using a FLOOR-REQUEST-ID. The floor control serverMUST<bcp14>MUST</bcp14> copy the contents of the FLOOR-REQUEST-ID attribute from the FloorRelease message into the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.4-7">The floor control serverMUST<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-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute.</t><t>The<t indent="0" pn="section-13.4-8">The floor control serverMUST<bcp14>MUST</bcp14> add an OVERALL-REQUEST-STATUS attribute to the FLOOR-REQUEST-INFORMATION grouped attribute. The Request Status valueSHOULD<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 serverMAY<bcp14>MAY</bcp14> add a STATUS-INFO attribute with extra information about the floor request.</t> </section> <sectiontitle="Receptionanchor="sec_server_floorinfo" numbered="true" toc="include" removeInRFC="false" pn="section-13.5"> <name slugifiedName="name-reception-of-a-floorquery-m">Reception of a FloorQueryMessage" anchor="sec:server:floorinfo"> <t>OnMessage</name> <t indent="0" pn="section-13.5-1">On reception of a FloorQuery message, the floor control server follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to client authentication. If while processing the FloorQuery message, the floor control server encounters an error, itMUST<bcp14>MUST</bcp14> generate an Error response following the procedures described in <xreftarget="sec:server:error"/>.</t> <t>Whentarget="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t> <t indent="0" pn="section-13.5-2">When communicating over an unreliable transport and upon receiving a FloorQuery from a participant, the floor control serverMUST<bcp14>MUST</bcp14> respond with a FloorStatus message within the transaction failure window to complete the transaction.</t><t>A<t indent="0" pn="section-13.5-3">A floor control server receiving a FloorQuery message from a clientSHOULD<bcp14>SHOULD</bcp14> keep this client informed about the status of the floors identified by FLOOR-ID attributes in the FloorQuery message. FloorControl Serverscontrol servers keep clients informed by using FloorStatus messages.</t><t>An<t indent="0" pn="section-13.5-4">An individual FloorStatus message carries information about a single floor. So, when a FloorQuery message requests information about more than one floor, the floor control server needs to send separate FloorStatus messages for different floors.</t><t>The<t indent="0" pn="section-13.5-5">The information FloorQuery messages carry 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> <sectiontitle="Generationanchor="sec_server_floorinfo_first" numbered="true" toc="include" removeInRFC="false" pn="section-13.5.1"> <name slugifiedName="name-generation-of-the-first-flo">Generation of the First FloorStatusMessage" anchor="sec:server:floorinfo:first"> <t>TheMessage</name> <t indent="0" pn="section-13.5.1-1">The successful processing of a FloorQuery message by a floor control server involves generating one or several FloorStatus messages, the first of whichSHOULD<bcp14>SHOULD</bcp14> be generated as soon as possible.</t><t>The<t indent="0" pn="section-13.5.1-2">The floor control serverMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the FloorQuery message into the FloorStatus message, as described in <xreftarget="sec:transactions:server"/>.</t> <t>Iftarget="sec_transactions_server" format="default" sectionFormat="of" derivedContent="Section 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 message without adding any additional attribute and does not send any subsequent FloorStatus message to the floor participant.</t><t>If<t indent="0" pn="section-13.5.1-4">If the FloorQuery message contained one or more FLOOR-ID attributes, the floor control server chooses one from among them and adds this FLOOR-ID attribute to the FloorStatus message. The floor control serverSHOULD<bcp14>SHOULD</bcp14> add a FLOOR-REQUEST-INFORMATION grouped attribute for each floor request associated to the floor. Each FLOOR-REQUEST-INFORMATION 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>The<t indent="0" pn="section-13.5.1-5">The floor control serverMUST<bcp14>MUST</bcp14> identify the floor request the FLOOR-REQUEST-INFORMATION attribute applies to by filling the Floor Request ID field of the FLOOR-REQUEST-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.5.1-6">The floor control serverMUST<bcp14>MUST</bcp14> add FLOOR-REQUEST-STATUS attributes to the FLOOR-REQUEST-INFORMATION grouped attribute identifying the floors being requested (i.e., the floors associated with the floor request identified by the FLOOR-REQUEST-ID attribute).</t><t>The<t indent="0" pn="section-13.5.1-7">The floor control serverSHOULD<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 serverMAY<bcp14>MAY</bcp14> provide the display name and the URI of the beneficiary in this BENEFICIARY-INFORMATION attribute.</t><t>The<t indent="0" pn="section-13.5.1-8">The floor control serverMAY<bcp14>MAY</bcp14> provide information about the requester of the floor in a REQUESTED-BY-INFORMATION attribute inside the FLOOR-REQUEST-INFORMATION grouped attribute.</t><t>The<t indent="0" pn="section-13.5.1-9">The floor control serverMAY<bcp14>MAY</bcp14> provide the reason why the floor participant requested the floor in a PARTICIPANT-PROVIDED-INFO.</t><t>The<t indent="0" pn="section-13.5.1-10">The floor control serverMAY<bcp14>MAY</bcp14> also add to the FLOOR-REQUEST-INFORMATION grouped attribute a PRIORITY attribute with the Priority value requested for the floor request.</t><t>The<t indent="0" pn="section-13.5.1-11">The floor control serverMUST<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 control serverMAY<bcp14>MAY</bcp14> add a STATUS-INFO attribute with extra information about the floor request.</t><t>The<t indent="0" pn="section-13.5.1-12">The floor control serverMAY<bcp14>MAY</bcp14> provide information about the status of the floor request as it relates to each of the floors being requested in the FLOOR-REQUEST-STATUS attributes.</t> </section> <sectiontitle="Generationanchor="sec_server_floorinfo_subsequent" numbered="true" toc="include" removeInRFC="false" pn="section-13.5.2"> <name slugifiedName="name-generation-of-subsequent-flo">Generation of Subsequent FloorStatusMessages" anchor="sec:server:floorinfo:subsequent"> <t>IfMessages</name> <t indent="0" pn="section-13.5.2-1">If the FloorQuery message carried more than one FLOOR-ID attribute, the floor control serverSHOULD<bcp14>SHOULD</bcp14> generate a FloorStatus message for each of them (except for the FLOOR-ID attribute chosen for the first FloorStatus message) as soon as possible. These FloorStatus messages are generated following the same rules as those for the first FloorStatus message (see <xreftarget="sec:server:floorinfo:first"/>),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 outstanding transactions when using an unreliable transport(cf. <xref target="sec:transactions"/>).</t> <t>After(cf. <xref target="sec_transactions" format="default" sectionFormat="of" derivedContent="Section 8"/>).</t> <t indent="0" pn="section-13.5.2-2">After generating these messages, the floor control server sends FloorStatus messages, periodically keeping the client informed about all the floors for which the client requested information. The Transaction ID of these messagesMUST<bcp14>MUST</bcp14> be 0 when using a reliable transport and non-zero and unique in the context of outstanding transactions when using an unreliable transport(cf. <xref target="sec:transactions"/>).</t> <t><list style="hanging"> <t>The(cf. <xref target="sec_transactions" format="default" 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 control server sends FloorStatus messages is a matter of local policy. A floor control 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></list></t> <t>When</aside> <t indent="0" pn="section-13.5.2-4">When communicating over an unreliable transport and a FloorStatusAck message is not received within the transaction failure window, the floor control serverMUST<bcp14>MUST</bcp14> retransmit the FloorStatus message according to <xreftarget="udp_transport"/>.</t>target="udp_transport" format="default" sectionFormat="of" derivedContent="Section 6.2"/>.</t> </section> </section> <sectiontitle="Receptionanchor="sec_server_chairaction" numbered="true" toc="include" removeInRFC="false" pn="section-13.6"> <name slugifiedName="name-reception-of-a-chairaction-">Reception of a ChairActionMessage" anchor="sec:server:chairaction"> <t>OnMessage</name> <t indent="0" pn="section-13.6-1">On reception of a ChairAction message, the floor control server follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to client authentication and authorization. If while processing the ChairAction message, the floor control server encounters an error, itMUST<bcp14>MUST</bcp14> generate an Error response following the procedures described in <xreftarget="sec:server:error"/>.</t> <t>Thetarget="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t> <t indent="0" pn="section-13.6-2">The successful processing of a ChairAction message by a floor control server involves generating a ChairActionAck message, whichSHOULD<bcp14>SHOULD</bcp14> be generated as soon as possible.</t><t>When<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 serverMUST<bcp14>MUST</bcp14> respond with a ChairActionAck message within the transaction failure window to complete the transaction.</t><t>The<t indent="0" pn="section-13.6-4">The floor control serverMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the ChairAction message into the ChairActionAck message, as described in <xreftarget="sec:transactions:server"/>.</t> <t>Thetarget="sec_transactions_server" format="default" sectionFormat="of" derivedContent="Section 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., granting 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>For<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 floor 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, the floor control server will not grant it until the chairs responsible for the other floors agree to grant them as well.</t><t>So,<t indent="0" pn="section-13.6-7">So, the floor control server is ultimately responsible for keeping a coherent floor state using instructions from floor chairs as input to this state.</t><t>If<t indent="0" pn="section-13.6-8">If the new Status in the ChairAction message is Accepted and all the bits of the Queue Position field are zero, the floor chair is requesting that 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 the floor control server. (Of course, such a request only applies if the floor control server implements a queue.)</t> </section> <sectiontitle="Receptionanchor="sec_server_helloack" numbered="true" toc="include" removeInRFC="false" pn="section-13.7"> <name slugifiedName="name-reception-of-a-hello-messag">Reception of a HelloMessage" anchor="sec:server:helloack"> <t>OnMessage</name> <t indent="0" pn="section-13.7-1">On reception of a Hello message, the floor control server follows the rules in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/> that relate to client authentication. If while processing the Hello message, the floor control server encounters an error, itMUST<bcp14>MUST</bcp14> generate an Error response following the procedures described in <xreftarget="sec:server:error"/>.</t> <t>Iftarget="sec_server_error" format="default" sectionFormat="of" derivedContent="Section 13.8"/>.</t> <t indent="0" pn="section-13.7-2">If the version of BFCP specified in theVersionversion field of the COMMON-HEADER is supported by the floor control server, itMUST<bcp14>MUST</bcp14> respond with the same version number in the HelloAck; this defines the version for all subsequent BFCP messages within this BFCP Connection.</t><t>When<t indent="0" pn="section-13.7-3">When communicating over an unreliable transport and upon receiving a Hello from a participant, the floor control serverMUST<bcp14>MUST</bcp14> respond with a HelloAck message within the transaction failure window to complete the transaction.</t><t>The<t indent="0" pn="section-13.7-4">The successful processing of a Hello message by a floor control server involves generating a HelloAck message, whichSHOULD<bcp14>SHOULD</bcp14> be generated as soon as possible. The floor control serverMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the Hello into the HelloAck, as described in <xreftarget="sec:transactions:server"/>.</t> <t>Thetarget="sec_transactions_server" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</t> <t indent="0" pn="section-13.7-5">The floor control serverMUST<bcp14>MUST</bcp14> add a SUPPORTED-PRIMITIVES attribute to the HelloAck message listing all the primitives (i.e., BFCP messages) supported by the floor control server.</t><t>The<t indent="0" pn="section-13.7-6">The floor control serverMUST<bcp14>MUST</bcp14> add a SUPPORTED-ATTRIBUTES attribute to the HelloAck message listing all the attributes supported by the floor control server.</t> </section> <sectiontitle="Erroranchor="sec_server_error" numbered="true" toc="include" removeInRFC="false" pn="section-13.8"> <name slugifiedName="name-error-message-generation">Error MessageGeneration" anchor="sec:server:error"> <t>ErrorGeneration</name> <t indent="0" pn="section-13.8-1">Error messages are always sent in response to a previous message from the client as part of a client-initiated transaction. The ABNF in <xreftarget="sec:msg_format:Error"/>target="sec_msg_format_Error" format="default" sectionFormat="of" derivedContent="Section 5.3.13"/> describes the attributes that an Error message can contain. In addition, the ABNF specifies normatively which of these attributes are mandatory and which ones are optional.</t><t>The<t indent="0" pn="section-13.8-2">The floor control serverMUST<bcp14>MUST</bcp14> copy the Conference ID, the Transaction ID, and the User ID from the message from the client into the Error message, as described in <xreftarget="sec:transactions:server"/>.</t> <t>Thetarget="sec_transactions_server" format="default" sectionFormat="of" derivedContent="Section 8.2"/>.</t> <t indent="0" pn="section-13.8-3">The floor control serverMUST<bcp14>MUST</bcp14> add an ERROR-CODE attribute to the Error message. The ERROR-CODE attribute contains anError Codeerror code from <xreftarget="tab:errorcode"/>.target="tab_errorcode" format="default" sectionFormat="of" derivedContent="Table 5"/>. Additionally, the floor control server may add an ERROR-INFO attribute with extra information about the error.</t> </section> </section> <sectiontitle="Security Considerations" anchor="sec:security"> <t>BFCPanchor="sec_security" numbered="true" toc="include" removeInRFC="false" pn="section-14"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-14-1">BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that TLS/DTLS with an encryption algorithm according to <xreftarget="sec:lower-security"/>target="sec_lower-security" format="default" sectionFormat="of" derivedContent="Section 7"/> always be used. In cases where signaling/control traffic is properly protected, as described in <xreftarget="sec:auth"/>target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/>, it isREQUIRED<bcp14>REQUIRED</bcp14> to use a mandated encryption algorithm. BFCP entitiesMAY<bcp14>MAY</bcp14> use other security mechanisms to interwork with legacy implementation that do not use TLS/DTLS as long as these mechanisms provide similar security properties. An example of other mechanismsis IPSec <xref target="RFC4301"/>to effectively secure anon-securenonsecure BFCPconnection.</t> <t>Theconnection is IPsec <xref target="RFC4301" format="default" sectionFormat="of" derivedContent="21"/>.</t> <t indent="0" pn="section-14-2">The remainder of this section analyzes some of the threats against BFCP and how they are addressed.</t><t>An<t indent="0" pn="section-14-3">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 existing floor requests. Client impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections. The floor control server assumes that attackers cannot hijack the TLS/DTLS connection and, therefore, that messages over the TLS/DTLS connection come from the client that was initially authenticated.</t><t>An<t indent="0" pn="section-14-4">An attacker may attempt to impersonate a floor control server. A successful attacker would be able to make clients think that they hold a particular floor so that they would try to access a resource (e.g., sending media) without having legitimate rights to access it. Floor control server impersonation is avoided by having servers only accept BFCP messages over authenticated TLS/DTLS connections, as well as ensuring clients only send and accept messages over authenticated TLS/DTLS connections.</t><t>Attackers<t indent="0" pn="section-14-5">Attackers may attempt to modify messages exchanged by a client and a floor control server. The integrity protection provided by TLS/DTLS connections prevents this attack.</t><t>An<t indent="0" pn="section-14-6">An attacker may attempt to fetch a valid message sent by a client to a floor 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 check that messages arriving over a given authenticated TLS/DTLS connection use an authorized user ID (i.e., a user ID that the user that established the authenticated TLS/DTLS connection is allowed to use).</t><t>Attackers<t indent="0" pn="section-14-7">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., why a floor request was denied). TLS/DTLS confidentiality prevents this attack. Therefore, it isREQUIRED<bcp14>REQUIRED</bcp14> that TLS/DTLS be used with an encryption algorithm according to <xreftarget="sec:lower-security"/>.</t> </section> <section title="IANA Considerations" anchor="sec:iana"> <t><list style="empty"> <t>[Note to IANA: Muchtarget="sec_lower-security" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t> </section> <section anchor="sec_iana" numbered="true" toc="include" removeInRFC="false" pn="section-15"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-15-1">The IANA has created a registry for BFCP parameters called "The Binary Floor Control Protocol (BFCP) Parameters". This registry has a number ofthis text exists fromsubregistries, which are described in theprevious version of this document. Whilefollowing sections.</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-15.1"> <name slugifiedName="name-attributes-subregistry">Attributes Subregistry</name> <t indent="0" pn="section-15.1-1">This section establishes theold and new additions to"Attributes" subregistry under theregistries are presented here,BFCP Parameters registry. As per theitems for which IANA needs to take action with respect to this draft are highlighted with "Note to IANA", as with this note and the one immediately following. Throughout this document, though, RFC XXXX needs to be replaced with this 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 entries in the BFCP Primitive subregistry in <xref target="sec:iana:primitive"/> and for 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 Parameters registry. As per the terminology in RFC 5226 <xref target="RFC5226"/>, the registration policyterminology in RFC 8126 <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="6"/>, the registration policy for BFCP attributesshall beis "Specification Required". For the purposes of this subregistry, the BFCP attributes for which IANA registration is requestedMUST<bcp14>MUST</bcp14> be defined by astandards-trackStandards Track RFC. Such an RFCMUST<bcp14>MUST</bcp14> specify the attribute's type, name, format, and semantics.</t><t>For<t indent="0" pn="section-15.1-2">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 contains the initial values of this subregistry.</t><texttable title="Initial<table anchor="tab_iana-attributes" align="center" pn="table-7"> <name slugifiedName="name-initial-values-of-the-bfcp-">Initial values of the BFCPAttribute 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 following new values for the BFCP Primitive subregistry: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.]</t> </list></t> <t>ThisAttributes subregistry</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Type</th> <th align="left" colspan="1" rowspan="1">Attribute</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">BENEFICIARY-ID</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">FLOOR-ID</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">FLOOR-REQUEST-ID</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">PRIORITY</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">REQUEST-STATUS</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">ERROR-CODE</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">ERROR-INFO</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">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</td> <td align="left" colspan="1" rowspan="1">RFC 8855</td> </tr> </tbody> </table> </section> <section anchor="sec_iana_primitive" numbered="true" toc="include" removeInRFC="false" pn="section-15.2"> <name slugifiedName="name-primitives-subregistry">Primitives Subregistry</name> <t indent="0" pn="section-15.2-1">This section establishes thePrimitive"Primitives" subregistry under the BFCP Parameters registry. As per the terminology in RFC52268126 <xreftarget="RFC5226"/>,target="RFC8126" format="default" sectionFormat="of" derivedContent="6"/>, the registration policy for BFCP primitivesshall beis "Specification Required". For the purposes of this subregistry, the BFCP primitives for which IANA registration is requestedMUST<bcp14>MUST</bcp14> be defined by astandards-trackStandards Track RFC. Such an RFCMUST<bcp14>MUST</bcp14> specify the primitive's value, name, format, and semantics.</t><t>For<t indent="0" pn="section-15.2-2">For each BFCP primitive, the IANA registers its value, its name, and the reference to the RFC where the primitive is defined. The following table contains the initial values of this subregistry.</t><texttable title="Initial<table anchor="tab_iana-primitives" align="center" pn="table-8"> <name slugifiedName="name-initial-values-of-the-bfcp-p">Initial values of the BFCPprimitive 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>ThisPrimitives subregistry</name> <thead> <tr> <th align="center" colspan="1" rowspan="1">Value</th> <th align="left" colspan="1" rowspan="1">Primitive</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">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 theRequest Status"Request Statuses" subregistry under the BFCP Parameters registry. As per the terminology in RFC52268126 <xreftarget="RFC5226"/>,target="RFC8126" format="default" sectionFormat="of" derivedContent="6"/>, the registration policy for BFCP requeststatus shall bestatuses is "Specification Required". For the purposes of this subregistry, the BFCP requeststatusstatuses for which IANA registration is requestedMUST<bcp14>MUST</bcp14> be defined by astandards-trackStandards Track RFC. Such an RFCMUST<bcp14>MUST</bcp14> specify the value and the semantics of the request status.</t><t>For<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 request status is defined. The following table contains the initial values of this subregistry.</t><texttable title="Initial<table anchor="tab_iana-requeststatusvalues" align="center" pn="table-9"> <name slugifiedName="name-initial-values-of-the-reque">Initial values of the RequestStatus 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: ThisStatuses 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" removeInRFC="false" pn="section-15.4"> <name slugifiedName="name-error-codes-subregistry">Error Codes Subregistry</name> <t indent="0" pn="section-15.4-1">This sectioninstructs the IANA to registerestablishes thefollowing 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"Error Codes" subregistry under the BFCP Parameters registry. As per the terminology in RFC52268126 <xreftarget="RFC5226"/>,target="RFC8126" format="default" sectionFormat="of" derivedContent="6"/>, the registration policy for BFCP error codesshall beis "Specification Required". For the purposes of this subregistry, the BFCP error codes for which IANA registration is requestedMUST<bcp14>MUST</bcp14> be defined by astandards-trackStandards Track RFC. Such an RFCMUST<bcp14>MUST</bcp14> specify the value and the semantics of the error code, and any Error Specific Details that apply to it.</t><t>For<t indent="0" pn="section-15.4-2">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 contains the initial values of this subregistry.</t><texttable title="Initial Values<table anchor="tab_iana-errorcode" align="center" pn="table-10"> <name slugifiedName="name-initial-values-of-the-error">Initial values of the ErrorCode subregistry" anchor="tab: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>UnknownCodes 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 MandatoryAttribute</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>FloorAttribute</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</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">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 NotExist</c> <c>[RFC XXXX]</c> <c>8</c> <c>YouExist</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 theMaximum</c> <c>[RFC XXXX]</c> <c></c> <c>Maximum Number of Ongoing Floor Requestsfor</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>Unablefor 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 toparse 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>IncorrectParse 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 MessageLength</c> <c>[RFC XXXX]</c> <c>14</c> <c>Generic Error</c> <c>[RFC XXXX]</c> </texttable>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> <sectiontitle="Changesanchor="sec_changes" numbered="true" toc="include" removeInRFC="false" pn="section-16"> <name slugifiedName="name-changes-from-rfc-4582">Changes from RFC4582" anchor="sec:changes"> <t>Following4582</name> <t indent="0" pn="section-16-1">The following is the list of technical changes and other non-trivial fixes from <xreftarget="RFC4582"/>.</t> <section title="Extensionstarget="RFC4582" format="default" sectionFormat="of" derivedContent="3"/>.</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-16.1"> <name slugifiedName="name-extensions-for-an-unreliabl">Extensions for anunreliable transport"> <t>MainUnreliable Transport</name> <t indent="0" pn="section-16.1-1">The main purpose of this work was to revise the specification to support BFCP over an unreliable transport, resulting in the following changes:</t><t><list style="numbers"> <t>Overview<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-16.1-2"> <li pn="section-16.1-2.1" derivedCounter="1."> <t indent="0" pn="section-16.1-2.1.1">Overview of Operation (<xreftarget="sec:overview"/>):<vspace/>target="sec_overview" format="default" sectionFormat="of" derivedContent="Section 4"/>):</t> <t indent="0" pn="section-16.1-2.1.2"> Changed the description of client-initiated and server-initiated transactions, referring to <xreftarget="sec:transactions"/>.</t> <t>COMMON-HEADERtarget="sec_transactions" format="default" sectionFormat="of" derivedContent="Section 8"/>.</t> </li> <li pn="section-16.1-2.2" derivedCounter="2."> <t indent="0" pn="section-16.1-2.2.1">COMMON-HEADER Format (<xreftarget="sec:format:common"/>):<vspace/>target="sec_format_common" format="default" sectionFormat="of" derivedContent="Section 5.1"/>):</t> <t indent="0" pn="section-16.1-2.2.2"> Ver(sion) field, where the value 2 is used for the extensions for an unreliable transport. Added new R and Fflag-bitsflag bits for an unreliable transport. Res(erved) field is now 3 bit. New optional Fragment Offset and Fragment Length fields.</t><t>New</li> <li pn="section-16.1-2.3" derivedCounter="3."> <t indent="0" pn="section-16.1-2.3.1">New primitives (<xreftarget="sec:format:common"/>):<vspace/>target="sec_format_common" format="default" sectionFormat="of" derivedContent="Section 5.1"/>):</t> <t indent="0" pn="section-16.1-2.3.2"> Added four new primitives: FloorRequestStatusAck, FloorStatusAck, Goodbye, and GoodbyeAck.</t><t>New</li> <li pn="section-16.1-2.4" derivedCounter="4."> <t indent="0" pn="section-16.1-2.4.1">New error codes (<xreftarget="sec:format:attributes:error-code"/>):<vspace/>target="sec_format_attributes_error-code" format="default" sectionFormat="of" derivedContent="Section 5.2.6"/>):</t> <t indent="0" pn="section-16.1-2.4.2"> Added three new error codes: "Unable to Parse Message", "Use DTLS" and "Unsupported Version". Note that two additional error codes were added, see <xreftarget="sec:changes:other"/>.</t> <t>ABNFtarget="sec_changes_other" format="default" sectionFormat="of" derivedContent="Section 16.2"/>.</t> </li> <li pn="section-16.1-2.5" derivedCounter="5."> <t indent="0" pn="section-16.1-2.5.1">ABNF for new primitives (<xreftarget="sec:msg_format"/>):<vspace/> Newtarget="sec_msg_format" format="default" sectionFormat="of" derivedContent="Section 5.3"/>):</t> <t indent="0" pn="section-16.1-2.5.2"> Added new subsections with normative ABNF for the new primitives.</t><t>Transport</li> <li pn="section-16.1-2.6" derivedCounter="6."> <t indent="0" pn="section-16.1-2.6.1">Transport split in two (<xreftarget="sec:transport"/>):<vspace/> <xref target="sec:transport"/>target="sec_transport" format="default" sectionFormat="of" derivedContent="Section 6"/>):</t> <t indent="0" pn="section-16.1-2.6.2"><xref target="sec_transport" format="default" sectionFormat="of" derivedContent="Section 6"/> specifying the transport was split in two subsections; <xreftarget="tcp_transport"/>target="tcp_transport" format="default" sectionFormat="of" derivedContent="Section 6.1"/> for a reliable transport and <xreftarget="udp_transport"/>target="udp_transport" format="default" sectionFormat="of" derivedContent="Section 6.2"/> for an unreliable transport.Where theThe specification for an unreliabletransport amongsttransport, among otherissuesissues, deals with reliability, congestion control, fragmentation and ICMP.</t><t>Mandate</li> <li pn="section-16.1-2.7" derivedCounter="7."> <t indent="0" pn="section-16.1-2.7.1">Mandated DTLS (<xreftarget="sec:lower-security"/> and <xref target="sec:auth"/>):<vspace/> Mandatetarget="sec_lower-security" format="default" sectionFormat="of" derivedContent="Section 7"/> and <xref target="sec_auth" format="default" sectionFormat="of" derivedContent="Section 9"/>):</t> <t indent="0" pn="section-16.1-2.7.2"> Mandated DTLS support when transport over UDP is used.</t><t>Transaction</li> <li pn="section-16.1-2.8" derivedCounter="8."> <t indent="0" pn="section-16.1-2.8.1">Transaction changes (<xreftarget="sec:transactions"/>):<vspace/>target="sec_transactions" format="default" sectionFormat="of" derivedContent="Section 8"/>):</t> <t indent="0" pn="section-16.1-2.8.2"> Server-initiated transactions over an unreliable transporthashave non-zero and unique TransactionID.IDs. Over an unreliable transport, the retransmit timers T1 and T2 described in <xreftarget="timers"/>target="timers" format="default" sectionFormat="of" derivedContent="Section 8.3"/> apply.</t><t>Requiring timely</li> <li pn="section-16.1-2.9" derivedCounter="9."> <t indent="0" pn="section-16.1-2.9.1">Timely response required (<xreftarget="timers"/>, <xref target="sec:client:request:response"/>, <xref target="sec:participant:cancel:response"/>, <xref target="sec:chair:instruct:response"/>, <xref target="sec:client:floorinfo:response"/>, <xref target="sec:client:info:response"/>, <xref target="sec:client:user:response"/>, <xref target="sec:client:hello:responses"/>, <xref target="sec:recept:frsm"/> and <xref target="sec:recept:fsm"/>):<vspace/> Describingtarget="timers" format="default" sectionFormat="of" derivedContent="Section 8.3"/>, <xref target="sec_client_request_response" format="default" sectionFormat="of" derivedContent="Section 10.1.2"/>, <xref target="sec_participant_cancel_response" format="default" sectionFormat="of" derivedContent="Section 10.2.2"/>, <xref target="sec_chair_instruct_response" format="default" sectionFormat="of" derivedContent="Section 11.2"/>, <xref target="sec_client_floorinfo_response" format="default" sectionFormat="of" derivedContent="Section 12.1.2"/>, <xref target="sec_client_info_response" format="default" sectionFormat="of" derivedContent="Section 12.2.2"/>, <xref target="sec_client_user_response" format="default" sectionFormat="of" derivedContent="Section 12.3.2"/>, <xref target="sec_client_hello_responses" format="default" sectionFormat="of" derivedContent="Section 12.4.2"/>, <xref target="sec_recept_frsm" format="default" sectionFormat="of" derivedContent="Section 10.1.3"/> and <xref target="sec_recept_fsm" format="default" sectionFormat="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><t>Updated</li> <li pn="section-16.1-2.10" derivedCounter="10."> <t indent="0" pn="section-16.1-2.10.1">Updated IANA Considerations (<xreftarget="sec:iana"/>):<vspace/>target="sec_iana" format="default" sectionFormat="of" derivedContent="Section 15"/>):</t> <t indent="0" pn="section-16.1-2.10.2"> Added the new primitives and error codes to <xreftarget="sec:iana:primitive"/>target="sec_iana_primitive" format="default" sectionFormat="of" derivedContent="Section 15.2"/> and <xreftarget="sec:iana:errorcode"/>target="sec_iana_errorcode" format="default" sectionFormat="of" derivedContent="Section 15.4"/> respectively.</t><t>Examples</li> <li pn="section-16.1-2.11" derivedCounter="11."> <t indent="0" pn="section-16.1-2.11.1">Examples over an unreliable transport (<xreftarget="app:unrelcallflow"/>):<vspace/>target="app_unrelcallflow" format="default" sectionFormat="of" derivedContent="Appendix A"/>):</t> <t indent="0" pn="section-16.1-2.11.2"> Added sample interactions over an unreliable transport for the scenarios in <xreftarget="fig:flow1"/>target="fig_flow1" format="default" sectionFormat="of" derivedContent="Figure 2"/> and <xreftarget="fig:flow2"/>target="fig_flow2" format="default" sectionFormat="of" derivedContent="Figure 3"/> </t><t>Motivation</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 (<xreftarget="app:motivation"/>):<vspace/> Introductiontarget="app_motivation" format="default" sectionFormat="of" derivedContent="Appendix B"/>):</t> <t indent="0" pn="section-16.1-2.12.2"> Added introduction to and motivation for extending BFCP to support an unreliable transport.</t></list></t></li> </ol> </section> <sectiontitle="Other changes" anchor="sec:changes:other"> <t>Clarificationsanchor="sec_changes_other" numbered="true" toc="include" removeInRFC="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><t><list style="numbers"> <t>ABNF<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 (<xreftarget="fig:ben-information"/>, <xref target="fig:floor-request-information"/>, ="fig:reqby-information"/>, <xref target="fig:floor-req-status"/>, <xref target="fig:overall-req-status"/>,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="default" 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" derivedContent="Figure 30"/>, and the ABNF figures in <xreftarget="sec:msg_format"/>):<vspace/>target="sec_msg_format" format="default" sectionFormat="of" derivedContent="Section 5.3"/>):</t> <t indent="0" pn="section-16.2-2.1.2"> Although formally correct in <xreftarget="RFC4582"/>,target="RFC4582" format="default" sectionFormat="of" derivedContent="3"/>, the notation has changed in a number ofFiguresfigures to an equivalent form for clarity, e.g.,s/*1(FLOOR-ID)/[FLOOR-ID]/<tt>s/*1(FLOOR-ID)/[FLOOR-ID]/</tt> in <xreftarget="fig:floorstatus"/>target="fig_floorstatus" format="default" sectionFormat="of" derivedContent="Figure 38"/> ands/*[XXX]/*(XXX)/<tt>s/*[XXX]/*(XXX)/</tt> in the other figures.</t><t>Typo</li> <li pn="section-16.2-2.2" derivedCounter="2."> <t indent="0" pn="section-16.2-2.2.1">Typo (<xreftarget="sec:client:hello:responses"/>):<vspace/> Changetarget="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 second paragraph.</t><t>Corrected</li> <li pn="section-16.2-2.3" derivedCounter="3."> <t indent="0" pn="section-16.2-2.3.1">Corrected attribute type (<xreftarget="sec:server:request:first"/>):<vspace/> Changetarget="sec_server_request_first" format="default" sectionFormat="of" derivedContent="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 eighth paragraph, since the note below describes priority and that the last paragraph 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" derivedContent="Section 5.2.6"/>):</t> <t indent="0" pn="section-16.2-2.4.2"> Added two additional error codes: "Incorrect Message Length" and "Generic Error".</t> </li> <li pn="section-16.2-2.5" derivedCounter="5."> <t indent="0" pn="section-16.2-2.5.1">New cipher suites (<xref target="sec_lower-security" format="default" sectionFormat="of" derivedContent="Section 7"/>)</t> <t indent="0" pn="section-16.2-2.5.2">Additional cipher suites are now 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 (Across the document):</t> <t indent="0" pn="section-16.2-2.6.2"> Language clarifications as a result of reviews. Also, the normative language 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> </middle> <back> <references pn="section-17"> <name slugifiedName="name-references">References</name> <references pn="section-17.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="1"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author initials="S." surname="Bradner" fullname="S. Bradner"> <organization showOnFrontPage="true"/> </author> <date year="1997" month="March"/> <abstract> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6298" quoteTitle="true" derivedAnchor="2"> <front> <title>Computing TCP's Retransmission Timer</title> <author initials="V." surname="Paxson" fullname="V. Paxson"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Allman" fullname="M. Allman"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Chu" fullname="J. Chu"> <organization showOnFrontPage="true"/> </author> <author initials="M." surname="Sargent" fullname="M. Sargent"> <organization showOnFrontPage="true"/> </author> <date year="2011" month="June"/> <abstract> <t indent="0">This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6298"/> <seriesInfo name="DOI" value="10.17487/RFC6298"/> </reference> <reference anchor="RFC4582" target="https://www.rfc-editor.org/info/rfc4582" quoteTitle="true" derivedAnchor="3"> <front> <title>The Binary Floor Control Protocol (BFCP)</title> <author initials="G." surname="Camarillo" fullname="G. Camarillo"> <organization showOnFrontPage="true"/> </author> <author initials="J." surname="Ott" fullname="J. Ott"> <organization showOnFrontPage="true"/> </author> <author initials="K." surname="Drage" fullname="K. Drage"> <organization showOnFrontPage="true"/> </author> <date year="2006" month="November"/> <abstract> <t indent="0">Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.</t> <t indent="0">This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4582"/> <seriesInfo name="DOI" value="10.17487/RFC4582"/> </reference> <reference anchor="RFC5018" target="https://www.rfc-editor.org/info/rfc5018" quoteTitle="true" derivedAnchor="4"> <front> <title>Connection Establishment in the Binary Floor Control Protocol (BFCP)</title> <author initials="G." surname="Camarillo" fullname="G. Camarillo"> <organization showOnFrontPage="true"/> </author> <date year="2007" month="September"/> <abstract> <t indent="0">This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5018"/> <seriesInfo name="DOI" value="10.17487/RFC5018"/> </reference> <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" 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 define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity 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 definitions and encoding for a core lexical analyzer of the type common to several Internet 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/rfc8126" 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 that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t indent="0">To make assignments in a given registry prudently, guidance 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. This document defines a framework for the documentation of these guidelines by specification 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 obsoletes 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/rfc5246" quoteTitle="true" derivedAnchor="7"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.2</title> <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 security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [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/rfc6347" 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 communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document 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/rfc3629" 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 compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers 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/rfc8174" quoteTitle="true" derivedAnchor="10"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials="B." surname="Leiba" fullname="B. Leiba"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="May"/> <abstract> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="11"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author initials="E." surname="Rescorla" fullname="E. Rescorla"> <organization showOnFrontPage="true"/> </author> <date year="2018" month="August"/> <abstract> <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC8856" target="https://www.rfc-editor.org/info/rfc8856" quoteTitle="true" derivedAnchor="12"> <front> <title>Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams</title> <author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo"> <organization showOnFrontPage="true"/> </author> <author initials="T" surname="Kristensen" fullname="Tom Kristensen"> <organization showOnFrontPage="true"/> </author> <author initials="C." surname="Holmberg" fullname="Christer Holmberg"> <organization showOnFrontPage="true"/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8856"/> <seriesInfo name="DOI" value="10.17487/RFC8856"/> </reference> <reference anchor="RFC4961" target="https://www.rfc-editor.org/info/rfc4961" 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 (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP". This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="131"/> <seriesInfo name="RFC" value="4961"/> <seriesInfo name="DOI" value="10.17487/RFC4961"/> </reference> <reference anchor="RFC5389" target="https://www.rfc-editor.org/info/rfc5389" 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 protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity 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. Rather, it is a tool to be used in the context of a NAT traversal solution. This is 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/rfc8085" 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. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), 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 collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.</t> <t indent="0">Some guidance is also applicable to the design of other 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/rfc8445" 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 Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay 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/rfc3264" 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 entities 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 offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). [STANDARDS-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/rfc4376" 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 exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control 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/rfc5239" 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 protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework 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/rfc3261" 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 include 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/rfc4301" 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 "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-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/rfc6501" quoteTitle="true" derivedAnchor="22"> <front> <title>Conference Information Data Model for Centralized Conferencing (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 conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) event package for conference State. [STANDARDS-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/rfc6503" 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 means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming 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/rfc6504" quoteTitle="true" derivedAnchor="24"> <front> <title>Centralized Conferencing Manipulation Protocol (CCMP) Call Flow 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 scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC 5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the 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 researchers and developers. This document is not an Internet Standards Track specification; 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/rfc1191" 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 discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU 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/rfc8201" 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="editor"> <organization showOnFrontPage="true"/> </author> <date year="2017" month="July"/> <abstract> <t indent="0">This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery 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/rfc4821" 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 as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery 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/rfc5763" quoteTitle="true" derivedAnchor="28"> <front> <title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title> <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 Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the 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 integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-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/rfc6951" quoteTitle="true" derivedAnchor="29"> <front> <title>UDP Encapsulation of Stream Control Transmission Protocol (SCTP) 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 encapsulating Stream Control Transmission Protocol (SCTP) packets into UDP packets and its 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 directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.</t> <t indent="0">Please note that this document only describes the functionality 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 which 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 tunneling (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/rfc7525" quoteTitle="true" derivedAnchor="30"> <front> <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title> <author initials="Y." surname="Sheffer" fullname="Y. Sheffer"> <organization showOnFrontPage="true"/> </author> <author initials="R." surname="Holz" fullname="R. Holz"> <organization showOnFrontPage="true"/> </author> <author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre"> <organization showOnFrontPage="true"/> </author> <date year="2015" month="May"/> <abstract> <t indent="0">Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t> </abstract> </front> <seriesInfo name="BCP" value="195"/> <seriesInfo name="RFC" value="7525"/> <seriesInfo name="DOI" value="10.17487/RFC7525"/> </reference> <reference anchor="RFC4380" target="https://www.rfc-editor.org/info/rfc4380" quoteTitle="true" derivedAnchor="31"> <front> <title>Teredo: Tunneling IPv6 over UDP through Network Address Translations (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 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; the Teredo relays act as IPv6 routers between the Teredo service and the "native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4". [STANDARDS-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/rfc6081" 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 Teredo protocol. These extensions provide additional capabilities to Teredo, including 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/rfc4960" 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 describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t> <t indent="0">SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services 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 multiple streams, with an option for order-of-arrival delivery of individual user messages,</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. [STANDARDS-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/rfc6544" quoteTitle="true" derivedAnchor="34"> <front> <title>TCP Candidates with Interactive Connectivity Establishment (ICE)</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 the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines 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 single 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 packets hide the actual payload and enable end-to-end delivery. This document proposes 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 Internet.</t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-manner-tsvwg-gut-02"/> <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-manner-tsvwg-gut-02.txt"/> <refcontent>Work in Progress</refcontent> </reference> <reference anchor="I-D.ietf-mmusic-media-path-middleboxes" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-07" derivedAnchor="36"> <front> <title>Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path</title> <author initials="B" surname="Stucker" fullname="Brian Stucker"> <organization showOnFrontPage="true"/> </author> <author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig"> <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 performing functions apart fromPARTICIPANT-PROVIDED-INFO to PRIORITY attributed in the eighth paragraph, sincenormal, standard functions of an IP router on thenote below describes prioritydata path between a source host andthat the last paragraph dealsdestination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact withPARTICIPANT-PROVIDED-INFO.</t> <t>New error codes (<xref target="sec:format:attributes:error-code"/>):<vspace/> Added two additional error codes: "Incorrect Message Length"NATs and"Generic Error".</t> <t>Assorted clarifications (Across the document):<vspace/> Language clarificationsfirewalls, asa result of reviews. Also,described in thenormative language where tightened where appropriate, i.e. changed from SHOULD strength to MUSTMIDCOM architecture, then problems may occur ina numberthe transport ofplaces.</t> </list></t> </section> </section> <section title="Acknowledgements" anchor="sec:acks"> <t>The XCON WG chairs, Adam Roach and Alan Johnston, provided useful ideasmedia traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult forRFC 4582 <xref target="RFC4582"/>. Additionally, Xiaotao Wu, Paul Kyzivat, Jonathan Rosenberg, Miguel A. Garcia-Martin, Mary Barnes, Ben Campbell, Dave Morgan, and Oscar Novo provided useful comments duringthework with RFC 4582. The authors also acknowledge contributionsend points to detect or predict problematic behavior and to determine whether therevision of BFCPmedia path is reliably available foruse over an unreliable transport from Geir Arne Sandbakken who hadpacket exchange. This document aims to summarize theinitial idea, Alfred E. Heggestad, Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Joerg Ott, Eoin McLeod, Mark K. Thompson, Hadriel Kaplan, Dan Wing, Cullen Jennings, David Benham, Nivedita Melinkeri, Woo Johnman, Vijaya Mandavavarious sources andAlan Ford. Ineffects of NAT and firewall control, thefinal phase Ernst Horvath did a thorough review revealing issuesreasons thatneeded clarification and changes. Usefulthey exist, andimportant final reviews were done by Mary Barnes. Paul Jones helped tremendously as editor for changes addressing IESG review comments.</t> </section> </middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119" ?> <?rfc include="reference.RFC.2988" ?> <?rfc include="reference.RFC.4582" ?> <?rfc include="reference.RFC.5018" ?> <?rfc include="reference.RFC.5234" ?> <?rfc include="reference.RFC.5226" ?> <?rfc include="reference.RFC.5246" ?> <?rfc include="reference.RFC.6347" ?> <?rfc include="reference.RFC.3629" ?> <?rfc include="reference.I-D.draft-ietf-bfcpbis-rfc4583bis-12" ?> <!-- TBD increase version! --> <?rfc include="reference.RFC.4961" ?> <?rfc include="reference.RFC.5389" ?> <?rfc include="reference.RFC.5405" ?> </references> <references title="Informational References"> <?rfc include="reference.RFC.3264" ?> <?rfc include="reference.RFC.4376" ?> <?rfc include="reference.RFC.5239" ?> <?rfc include="reference.RFC.5245" ?> <?rfc include="reference.RFC.3261" ?> <?rfc include="reference.RFC.4301" ?> <?rfc include="reference.RFC.6501" ?> <?rfc include="reference.RFC.6503" ?> <?rfc include="reference.RFC.6504" ?> <?rfc include="reference.RFC.1191" ?> <?rfc include="reference.RFC.1981" ?> <?rfc include="reference.RFC.4821" ?> <?rfc include="reference.RFC.5763" ?> <?rfc include="reference.RFC.6951" ?> <?rfc include="reference.RFC.7525" ?> <!-- Add referencepossible means of improving their behavior toIMTC role-based video BCP, at some stage. Referallow protocols that rely upon signaling along the media path toitoperate 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-ietf-mmusic-media-path-middleboxes-07.txt"/> <refcontent>Work inan informational note somehow. --> <!-- Motivation appendix references below --> <?rfc include="reference.RFC.4380" ?> <?rfc include="reference.RFC.6081" ?> <?rfc include="reference.RFC.4960" ?> <?rfc include="reference.RFC.6544" ?> <?rfc include="reference.I-D.draft-manner-tsvwg-gut-02" ?> <?rfc include="reference.I-D.draft-ietf-mmusic-media-path-middleboxes-07" ?>Progress</refcontent> </reference> <reference anchor="IMC05"target="http://saikat.guha.cc/pub/imc05-tcpnat.pdf/">target="https://www.usenix.org/legacy/event/imc05/tech/full_papers/guha/guha.pdf" quoteTitle="true" derivedAnchor="37"> <front> <title>Characterization and Measurement of TCP Traversal through NATs and Firewalls</title> <author initials="S" surname="Guha"/> <author initials="P" surname="Francis"/> <date month="" year="2005"/> </front> </reference> <reference anchor="P2PNAT"target="http://www.brynosaurus.com/pub/net/p2pnat.pdf/">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><!-- Appendices --></references> <sectiontitle="Exampleanchor="app_unrelcallflow" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-example-call-flows-for-bfcp">Example Call Flows for BFCP over an UnreliableTransport" anchor="app:unrelcallflow"> <t>WithTransport</name> <t indent="0" pn="section-appendix.a-1">With reference to <xreftarget="sec:overview:user"/>,target="sec_overview_user" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, the following figures show representativecall-flowscall flows for requesting and releasing a floor, and obtaining status information about a floor when BFCP is deployed over an unreliable transport. The figures here show aloss-lesslossless interaction.</t><t><figure align="left"<figure anchor="ReqRelUnrelExample"title="Requestingalign="left" suppress-title="false" pn="figure-48"> <name slugifiedName="name-requesting-and-releasing-a-f">Requesting and releasing afloor">floor</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt="" pn="section-appendix.a-2.1"> Floor Participant Floor Control Server |(1) FloorRequest | |Transaction Responder: 0 | |Transaction ID: 123 | |User ID: 234 | |FLOOR-ID: 543 ||---------------------------------------------->||---------------------------------------------->| | | |(2) FloorRequestStatus | |Transaction Responder: 1 | |Transaction ID: 123 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Pending | | FLOOR-REQUEST-STATUS | | Floor ID: 543 ||<----------------------------------------------||<----------------------------------------------| | | |(3) FloorRequestStatus | |Transaction Responder: 0 | |Transaction ID: 124 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 ||<----------------------------------------------||<----------------------------------------------| | | |(4) FloorRequestStatusAck | |Transaction Responder: 1 | |Transaction ID: 124 | |User ID: 234 ||---------------------------------------------->||---------------------------------------------->| | | |(5) FloorRequestStatus | |Transaction Responder: 0 | |Transaction ID: 125 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 ||<----------------------------------------------||<----------------------------------------------| | | |(6) FloorRequestStatusAck | |Transaction Responder: 1 | |Transaction ID: 125 | |User ID: 234 ||---------------------------------------------->||---------------------------------------------->| | | |(7) FloorRelease | |Transaction Responder: 0 | |Transaction ID: 126 | |User ID: 234 | |FLOOR-REQUEST-ID: 789 ||---------------------------------------------->||---------------------------------------------->| | | |(8) FloorRequestStatus | |Transaction Responder: 1 | |Transaction ID: 126 | |User ID: 234 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 789 | | OVERALL-REQUEST-STATUS | | Request Status: Released | | FLOOR-REQUEST-STATUS | | Floor ID: 543 ||<----------------------------------------------| ]]> </artwork> </figure></t> <t>Note|<----------------------------------------------|</artwork> </figure> <t indent="0" pn="section-appendix.a-3">Note that in <xreftarget="ReqRelUnrelExample"/>,target="ReqRelUnrelExample" format="default" sectionFormat="of" derivedContent="Figure 48"/>, the FloorRequestStatus message from the floor control server to the floor participant is a transaction-closing message as a response to the client-initiated transaction with Transaction ID154.126. As such, it is not followed by a FloorRequestStatusAck message from the floor participant to the floor control server.</t><t><figure align="left"<figure anchor="StatusUnrelExample"title="Obtainingalign="left" suppress-title="false" pn="figure-49"> <name slugifiedName="name-obtaining-status-information">Obtaining status information about afloor">floor</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt="" pn="section-appendix.a-4.1"> Floor Participant Floor Control Server |(1) FloorQuery | |Transaction Responder: 0 | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID: 543 ||---------------------------------------------->||---------------------------------------------->| | | |(2) FloorStatus | |Transaction Responder: 1 | |Transaction ID: 257 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 2nd | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 ||<----------------------------------------------||<----------------------------------------------| | | |(3) FloorStatus | |Transaction Responder: 0 | |Transaction ID: 258 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 764 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 124 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Accepted | | Queue Position: 1st | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 ||<----------------------------------------------||<----------------------------------------------| | | |(4) FloorStatusAck | |Transaction Responder: 1 | |Transaction ID: 258 | |User ID: 234 ||---------------------------------------------->||---------------------------------------------->| | | |(5) FloorStatus | |Transaction Responder: 0 | |Transaction ID: 259 | |User ID: 234 | |FLOOR-ID:543 | |FLOOR-REQUEST-INFORMATION | | Floor Request ID: 635 | | OVERALL-REQUEST-STATUS | | Request Status: Granted | | FLOOR-REQUEST-STATUS | | Floor ID: 543 | | BENEFICIARY-INFORMATION | | Beneficiary ID: 154 ||<----------------------------------------------||<----------------------------------------------| | | |(6) FloorStatusAck | |Transaction Responder: 1 | |Transaction ID: 259 | |User ID: 234 ||---------------------------------------------->| ]]> </artwork> </figure></t>|---------------------------------------------->|</artwork> </figure> </section> <sectiontitle="Motivationanchor="app_motivation" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b"> <name slugifiedName="name-motivation-for-supporting-a">Motivation for Supporting an UnreliableTransport" anchor="app:motivation"> <t>ThisTransport</name> <t indent="0" pn="section-appendix.b-1">This appendix iscontained in this documentprovided as an aid to understand the background and rationale for adding support for unreliable transport.</t> <section anchor="motivation"title="Motivation"> <t>Innumbered="true" toc="include" removeInRFC="false" pn="section-b.1"> <name slugifiedName="name-motivation">Motivation</name> <t indent="0" pn="section-b.1-1">In existing video conferencing deployments, BFCP is used to manage the floor for the content sharing associated with the conference. Forpeer to peerpeer-to-peer scenarios, includingbusiness to businessbusiness-to-business conferences andpoint to pointpoint-to-point conferences in general, it is frequently the case that one or both endpointsexistsexist behind a NAT. BFCP roles are negotiated in the offer/answer exchange as specified in <xreftarget="I-D.ietf-bfcpbis-rfc4583bis"/>,target="RFC8856" format="default" sectionFormat="of" derivedContent="12"/>, resulting in one endpoint being responsible for opening the TCP connection used for the BFCP communication.</t><t><figure align="left"<figure anchor="use_case"title="Use Case">align="left" suppress-title="false" pn="figure-50"> <name slugifiedName="name-use-case">Use case</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt="" pn="section-b.1-2.1"> +---------+ | Network | +---------+ +-----+ / \ +-----+ | NAT |/ \| NAT | +-----+ +-----+ +----+ / \ +----+ |BFCP|/ \|BFCP| | UA | | UA | +----++----+ ]]></artwork> </figure></t> <t>The+----+</artwork> </figure> <t indent="0" pn="section-b.1-3">The communication session between the video conferencing endpoints typically consists of a number of RTP over UDP mediastreams,streams for audio andvideo,video and a BFCP connection for floor control. Existing deployments are most common in, but not limited to, enterprise networks. In existing deployments, NAT traversal for the RTP streams works using ICE and/or other methods, including those described in <xreftarget="I-D.ietf-mmusic-media-path-middleboxes"/>.</t> <t>Whentarget="I-D.ietf-mmusic-media-path-middleboxes" format="default" sectionFormat="of" derivedContent="36"/>.</t> <t indent="0" pn="section-b.1-4">When enhancing an existingSIP basedSIP-based video conferencing deployment with support for content sharing, the BFCP connection often poses a problem. The reasons for this fall into two general classes. First, there may be a strong preference forUDP basedUDP-based signaling in general. Onhigh capacityhigh-capacity endpoints (e.g.,PSTNPublic Switched Telephone Network (PSTN) gateways or SIP/H.323 inter-working gateways), TCP can suffer fromhead of linehead-of-line blocking, and it uses many kernel buffers. Network operators view UDP as a way to avoid both of these. Second, the establishment and traversal of the TCP connection involving ephemeral ports, as is typically the case with BFCP over TCP, can be problematic, as described inAppendix A of<xreftarget="RFC6544"/>.target="RFC6544" section="A" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6544#appendix-A" derivedContent="34"/>. A broad study of NAT behavior and peer-to-peer TCP establishment for a comprehensive set of TCP NAT traversal techniques over a wide range of commercial NAT products concluded that it was not possible to establish a TCP connection in 11% of the cases <xreftarget="IMC05"/>.target="IMC05" format="default" sectionFormat="of" derivedContent="37"/>. The results are worse when focusing on enterprise NATs. A study ofhole punchinghole-punching as a NAT traversal technique across a wide variety of deployed NATs reported consistently higher success rates when using UDP than when using TCP <xreftarget="P2PNAT"/>.</t> <t>Ittarget="P2PNAT" format="default" sectionFormat="of" derivedContent="38"/>.</t> <t indent="0" pn="section-b.1-5">It is worthnoticingnoting that BFCP over UDP is 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 situation where multiple different and non-interoperable implementations wouldco-existcoexist in the market. The purpose of thisdraftdocument is toformalize and publish the extension fromextend the standard specification to support unreliable transport in order to facilitate complete interoperability between implementations.</t> <section anchor="alternatives"title="Alternatives Considered"> <t>Innumbered="true" toc="include" removeInRFC="false" pn="section-b.1.1"> <name slugifiedName="name-alternatives-considered">Alternatives Considered</name> <t indent="0" pn="section-b.1.1-1">In selecting the approach of defining UDP as an alternate transport for BFCP, several alternatives were considered and explored to some degree. Each of these is discussed briefly in the following subsections. In summary, while the alternatives that were not chosenalternativeswork in a number of scenarios, they are not sufficient, in and of themselves, to address the use case targeted by thisdraft.document. The last alternative, presented in <xreftarget="thisextension"/>, is thetarget="thisextension" format="default" sectionFormat="of" derivedContent="Appendix B.1.1.7"/>, was selectedoneand is specified in thisdraft.</t> <t>Itdocument.</t> <t indent="0" pn="section-b.1.1-2">It is also worth noting that the IETF Transport Areawerewas asked for a way to tunnel TCP over UDP, but at that point there was no consensus on how to achieve that.</t> <section anchor="ice_tcp"title="ICE TCP"> <t>ICEnumbered="true" toc="include" removeInRFC="false" pn="section-b.1.1.1"> <name slugifiedName="name-ice-tcp">ICE TCP</name> <t indent="0" pn="section-b.1.1.1-1">ICE TCP <xreftarget="RFC6544"/>target="RFC6544" format="default" sectionFormat="of" derivedContent="34"/> extends ICE toTCP basedTCP-based media, including the ability to offer a mix ofTCPTCP- andUDP basedUDP-based candidates for a single stream. ICE TCP has, in general, a lower success probability for enabling TCP connectivity without a relay if both of the hosts are behind a NAT (seeAppendix A of<xreftarget="RFC6544"/>)target="RFC6544" section="A" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6544#appendix-A" derivedContent="34"/>) than enabling UDP connectivity in the same scenarios. The happens because many of the currently deployed NATs in video conferencing networks do not support the flow of TCPhand shakehandshake packets seen in the case of TCP simultaneous-open, either because they do not allow incoming TCP SYN packets from an address to which a SYN packet has been senttorecently, or because they do not properly process the subsequent SYNACK. Implementing various techniques advocated for candidate collection in <xreftarget="RFC6544"/>target="RFC6544" format="default" sectionFormat="of" derivedContent="34"/> should increase the success probability, but many of these techniques require support from some network elements (e.g., from the NATs). Such support is not common in enterprise NATs.</t> </section> <section anchor="teredo"title="Teredo"> <t>Teredo <xref target="RFC4380"/>numbered="true" toc="include" removeInRFC="false" pn="section-b.1.1.2"> <name slugifiedName="name-teredo">Teredo</name> <t indent="0" pn="section-b.1.1.2-1">Teredo <xref target="RFC4380" format="default" sectionFormat="of" derivedContent="31"/> enables nodes located behind one or more IPv4 NATs to obtain IPv6 connectivity by tunneling packets over UDP. Teredo extensions <xreftarget="RFC6081"/>target="RFC6081" format="default" sectionFormat="of" derivedContent="32"/> provide additional capabilities to Teredo, including support for more types of NATs and support for more efficient communication.</t><t>As<t indent="0" pn="section-b.1.1.2-2">As defined, Teredo could be used to make BFCP work for the video conferencing use cases addressed in thisdraft.document. However, running the service requires the help of "Teredo servers" and "Teredo relays" <xreftarget="RFC4380"/>.target="RFC4380" format="default" sectionFormat="of" derivedContent="31"/>. These servers and relays generally do not exist inthe existingcurrent video conferencing deployments. It also requires IPv6 awareness on the endpoints. It should also be noted that ICMP6, as used with Teredo to complete an initial protocol exchange and confirm that the appropriate NAT bindings have been set up, is not a conventional feature of IPv4 or even IPv6, and some currently deployed IPv6 firewalls discard ICMP messages. As these networks continue to evolve and tackle the transaction to IPv6, Teredo servers and relays may be deployed, making Teredo available as a suitable alternative to BFCP over UDP.</t> </section> <section anchor="gut"title="GUT"> <t>GUT <xref target="I-D.manner-tsvwg-gut"/>numbered="true" toc="include" removeInRFC="false" pn="section-b.1.1.3"> <name slugifiedName="name-gut">GUT</name> <t indent="0" pn="section-b.1.1.3-1">GUT <xref target="I-D.manner-tsvwg-gut" format="default" sectionFormat="of" derivedContent="35"/> attempts to facilitate tunneling over UDP by encapsulating the native transport protocol and its payload (in general the whole IP payload) within a UDP packet destined to the well-known port GUT_P. Unfortunately, it requires user-space TCP, for which there is not a readily available implementation, and creating one is a large project in itself. Thisdraftdocument hasexpiredexpired, and its future is stillnot clearunclear as it has not yet been adopted by a working group.</t> </section> <section anchor="upnp_igd"title="UPnP IGD"> <t>Universalnumbered="true" toc="include" removeInRFC="false" pn="section-b.1.1.4"> <name slugifiedName="name-upnp-igd">UPnP IGD</name> <t indent="0" pn="section-b.1.1.4-1">Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on the edge of the network, providing connectivity to the Internet for computers internal to the LAN, but do not allow Internet devices to connect to computers on the internal LAN. IGDs enable a computer on an internal LAN to create port mappings on their NAT, through which hosts on the Internet can send data that will be forwarded to the computer on the internal LAN. IGDs may be self-contained hardware devices or may be software components provided within an operating system.</t><t>In<t indent="0" pn="section-b.1.1.4-2">In considering UPnP IGD, several issues exist. Not all NATs support UPnP, and many that do support it are configured with it turned off by default. NATs are often multilayered, and UPnP does not work well with such NATs. For example, a typical DSLmodemsmodem acts as a NAT, and the user plugs in a wireless access point behind that, which adds another layer of NAT. The client can discover the first layer of NAT usingmulticastmulticast, but it is harder to figure out how to discover and control NATs in the next layer up.</t> </section> <section anchor="nat_pmp"title="NAT PMP"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-b.1.1.5"> <name slugifiedName="name-nat-pmp">NAT PMP</name> <t indent="0" pn="section-b.1.1.5-1">The NAT Port Mapping Protocol (NAT PMP) allows a computer in a private network (behind a NAT router) to automatically configure the router to allow parties outside the private network to contact it. NAT PMP runs over UDP. It essentially automates the process of port forwarding. Included in the protocol is a method for retrieving the public IP address of a NAT gateway, thus allowing a client to make this public IP address and port number known to peers that may wish to communicate with it.</t><t>Many<t indent="0" pn="section-b.1.1.5-2">Many NATs do not support PMP. In those that do support it, it has similar issues with negotiation of multilayer NATs as UPnP. Video conferencing is used extensively in enterprise networks, and NAT PMP is not generally available in enterprise-class routers.</t> </section> <section anchor="sctp_udp"title="SCTP"> <t>Itnumbered="true" toc="include" removeInRFC="false" pn="section-b.1.1.6"> <name slugifiedName="name-sctp">SCTP</name> <t indent="0" pn="section-b.1.1.6-1">It would be quitestraight forwardstraightforward to specify a BFCP binding forSCTPStream Control Transmission Protocol (SCTP) <xreftarget="RFC4960"/>,target="RFC4960" format="default" sectionFormat="of" derivedContent="33"/>, and then tunnel SCTP over UDP in the use case described in <xreftarget="motivation"/>.target="motivation" format="default" sectionFormat="of" derivedContent="Appendix B.1"/>. SCTP is gaining some momentum currently. There was ongoing discussion in the RTCWebWGWorking Group regarding this approach, which resulted in <xreftarget="RFC6951"/>.target="RFC6951" format="default" sectionFormat="of" derivedContent="29"/>. However, this approachforto tunneling over UDP was not mature enough when considered and was not even fully specified.</t> </section> <section anchor="thisextension"title="BFCPnumbered="true" toc="include" removeInRFC="false" pn="section-b.1.1.7"> <name slugifiedName="name-bfcp-over-udp-transport">BFCP over UDPtransport"> <t>ToTransport</name> <t indent="0" pn="section-b.1.1.7-1">To overcome the problems with establishing 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 transport,it is recommended to followfollowing the guidelines provided in <xreftarget="RFC5405"/>.</t> <t>Minortarget="RFC8085" format="default" sectionFormat="of" derivedContent="15"/> is recommended.</t> <t indent="0" pn="section-b.1.1.7-2">Minor changes to the transaction modelarehave been introduced in that all requests now have an appropriate response to complete the transaction. The requests are sent with aretransmitretransmission timer associated with the response to achieve reliability. This alternative does not change the semantics of BFCP. It permits UDP as an alternate transport.</t><t>Existing<t indent="0" pn="section-b.1.1.7-3">Existing implementations, in the spirit of the approach detailed in earlier draft versions of thisdraft,document, have demonstrated that this approachto beis feasible. Initial compatibility among implementations has been achieved at previous interoperability events. The authors view 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 anchor="sec_acks" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c"> <name slugifiedName="name-acknowledgements">Acknowledgements</name> <t indent="0" pn="section-appendix.c-1">The XCON Working Group chairs, <contact 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"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Jonathan Rosenberg"/>, <contact fullname="Miguel A. Garcia-Martin"/>, <contact fullname="Mary Barnes"/>, <contact fullname="Ben Campbell"/>, <contact fullname="Dave Morgan"/>, and <contact fullname="Oscar Novo"/> provided useful comments during the work with RFC 4582. The authors also acknowledge contributions to the revision of BFCP for use over an unreliable transport from <contact fullname="Geir Arne Sandbakken"/> who had the initial idea, <contact fullname="Alfred E. Heggestad"/>, <contact fullname="Trond G. Andersen"/>, <contact fullname="Gonzalo Camarillo"/>, <contact fullname="Roni Even"/>, <contact fullname="Lorenzo Miniero"/>, <contact fullname="Jörg Ott"/>, <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 fullname="Nivedita Melinkeri"/>, <contact fullname="Woo Johnman"/>, <contact fullname="Vijaya Mandava"/>, and <contact fullname="Alan Ford"/>. In the final phase, <contact fullname="Ernst Horvath"/> did a thorough review, revealing issues that needed clarification and changes. Useful and important final reviews were done by <contact fullname="Mary Barnes"/>. <contact fullname="Paul Jones"/> helped tremendously as editor for changes addressing IESG review 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</organization> <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</organization> <address> <postal> <street>Boltzmannstrasse 3</street> <code>85748</code> <city>Garching</city> <country>Germany</country> </postal> <email>ott@in.tum.de</email> </address> </author> <author fullname="Charles Eckel" initials="C." surname="Eckel"> <organization 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>