<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.0.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-wish-whip-16" number="9725" category="std" consensus="true" updates="8842, 8840" updates="8840, 8842" obsoletes="" tocInclude="true" submissionType="IETF" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.22.0 --> version="3" xml:lang="en">

  <front>
    <title abbrev="whip">WebRTC-HTTP ingestion protocol Ingestion Protocol (WHIP)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-wish-whip-16"/> name="RFC" value="9725"/>
    <author initials="S." surname="Murillo" surname="Garcia Murillo" fullname="Sergio Garcia Murillo">
      <organization>Millicast</organization>
      <address>
        <email>sergio.garcia.murillo@cosmosoftware.io</email>
      </address>
    </author>
    <author initials="A." surname="Gouaillard" fullname="Alexandre Gouaillard">
      <organization>CoSMo Software</organization>
      <address>
        <email>alex.gouaillard@cosmosoftware.io</email>
      </address>
    </author>
    <date year="2024" month="August" day="21"/>
    <area>ART</area> year="2025" month="February"/>
    <area>WIT</area>
    <workgroup>wish</workgroup>
    <keyword>WebRTC</keyword>

    <abstract>
      <?line 35?>

      <t>This document describes a simple HTTP-based protocol that will allow
      WebRTC-based ingestion of content into streaming services and/or CDNs.</t>
      Content Delivery Networks (CDNs).</t>
      <t>This document updates RFC 8842 RFCs 8840 and RFC 8840.</t> 8842.</t>
    </abstract>
  </front>
  <middle>
    <?line 41?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The IETF RTCWEB working group Working Group standardized JSEP (<xref target="RFC9429"/>), the JavaScript Session Establishment Protocol (JSEP) <xref
      target="RFC9429"/>, a mechanism used to control the setup, management,
      and teardown of a multimedia session. It also describes how to negotiate
      media flows using the Offer/Answer Model offer/answer model with the Session Description
      Protocol (SDP) <xref target="RFC3264"/> target="RFC3264"/>, including the formats for data
      sent over the wire (e.g., media types, codec parameters, and
      encryption). WebRTC intentionally does not specify a signaling transport
      protocol at the application level.</t>

<t>Unfortunately, the lack of a standardized signaling mechanism in
WebRTC has been an obstacle to its adoption as an ingestion protocol
within the broadcast/streaming broadcast and streaming industry, where a streamlined
production pipeline is taken for granted: plug in granted. For example, cables carrying raw
media to hardware encoders, encoders are plugged in and then push the encoded media is
pushed to any streaming service or Content Delivery Network (CDN) ingest using an
ingestion protocol.</t> protocol.
      </t>
      <t>While WebRTC can be integrated with standard signaling protocols like
      SIP <xref target="RFC3261"/> or XMPP Extensible Messaging and Presence
      Protocol (XMPP) <xref target="RFC6120"/>, they are not designed to be
      used in broadcasting/streaming broadcasting and streaming services, and there is also no sign of
      adoption in that industry. RTSP The Real-Time Streaming Protocol (RTSP) <xref target="RFC7826"/>, which is based
      on RTP, does not support the SDP offer/answer model <xref
      target="RFC3264"/> for negotiating the characteristics of the media
      session.</t>
      <t>This document proposes a simple protocol based on HTTP for supporting WebRTC as a media ingestion method which:</t> that:</t>
      <ul spacing="normal">
        <li>
          <t>Is
          <t>is easy to implement,</t>
        </li>
        <li>
          <t>Is
          <t>is as easy to use as popular IP-based broadcast protocols</t> protocols,</t>
        </li>
        <li>
          <t>Is
          <t>is fully compliant with WebRTC and RTCWEB specs</t> specs,</t>
        </li>
        <li>
          <t>Enables
          <t>enables ingestion on both classical media platforms and WebRTC end-to-end platforms, achieving platforms (achieving the lowest possible latency.</t> latency),</t>
        </li>
        <li>
          <t>Lowers
          <t>lowers the requirements on both hardware encoders and broadcasting services to support WebRTC.</t> WebRTC, and</t>
        </li>
        <li>
          <t>Is
          <t>is usable both in both web browsers and in standalone encoders.</t>
        </li>
      </ul>
    </section>

    <section anchor="terminology">
      <name>Terminology</name>
      <t>The
        <t>
    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 are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
      <?line -18?> here.
        </t>
</section>
    <section anchor="overview">
      <name>Overview</name>
      <t>The WebRTC-HTTP Ingest Ingestion Protocol (WHIP) is designed to facilitate a
      one-time exchange of Session Description Protocol (SDP) offers and
      answers using HTTP POST requests. This exchange is a fundamental step in
      establishing an Interactive Connectivity Establishment (ICE) and
      Datagram Transport Layer Security (DTLS) session between the WHIP
      client, which represents the encoder or media producer, and the media
      server, which is the broadcasting ingestion endpoint.</t>
      <t>Upon successful establishment of the ICE/DTLS session, unidirectional
      media data transmission commences from the WHIP client to the media
      server. It is important to note that SDP renegotiations are not
      supported in WHIP, meaning WHIP. This means that no modifications to the "m=" sections
      can be made after the initial SDP offer/answer exchange via HTTP POST is
      completed and that only ICE related ICE-related information can be updated via HTTP PATCH
      requests as defined in <xref target="ice-support"/>.</t>
      <t>The following diagram illustrates the core operation of the WHIP protocol
      for initiating and terminating an ingest session:</t>

      <figure anchor="whip-protocol-operation">
        <name>WHIP session setup Session Setup and teardown</name> Teardown</name>
        <artwork><![CDATA[
+-------------+    +---------------+ +--------------+ +---------------+
| WHIP client |    | WHIP endpoint | | Media Server server | | WHIP session  |
+--+----------+    +---------+-----+ +------+-------+ +--------|------+
   |                         |              |                  |
   |                         |              |                  |
   |HTTP POST (SDP Offer) offer)    |              |                  |
   +------------------------>+              |                  |
   |201 Created (SDP answer) |              |                  |
   +<------------------------+              |                  |
   |          ICE REQUEST                   |                  |
   +--------------------------------------->+                  |
   |          ICE RESPONSE                  |                  |
   |<---------------------------------------+                  |
   |          DTLS SETUP                    |                  |
   |<======================================>|                  |
   |          RTP/RTCP FLOW                 |                  |
   +<-------------------------------------->+                  |
   | HTTP DELETE                                               |
   +---------------------------------------------------------->+
   | 200 OK                                                    |
   <-----------------------------------------------------------x
]]></artwork>
      </figure>

      <t>The elements in <xref target="whip-protocol-operation"/> are
      described as follows:</t>
      <ul
      <dl spacing="normal">
        <li>
          <t>WHIP client: This
          <dt>WHIP client:</dt><dd>This represents the WebRTC media encoder or
          producer, which functions as a client of the WHIP protocol by
          encoding and delivering media to a remote media server.</t>
        </li>
        <li>
          <t>WHIP endpoint: This server.</dd>
          <dt>WHIP endpoint:</dt><dd>This denotes the ingest server that
          receives the initial WHIP request.</t>
        </li>
        <li>
          <t>WHIP request.</dd>
          <dt>WHIP endpoint URL: Refers URL:</dt><dd>This refers to the URL of the WHIP endpoint responsible for creating the WHIP session.</t>
        </li>
        <li>
          <t>Media server: This session.</dd>
          <dt>Media server:</dt><dd>This is the WebRTC media server or
          consumer responsible for establishing the media session with the
          WHIP client and receiving the media content it produces.</t>
        </li>
        <li>
          <t>WHIP session: This produces.</dd>
          <dt>WHIP session:</dt><dd>This indicates the server handling the
          allocated HTTP resource by the WHIP endpoint for an ongoing ingest session.</t>
        </li>
        <li>
          <t>WHIP
          session.</dd>

          <dt>WHIP session URL: Refers URL:</dt><dd>This refers to the URL of the WHIP resource
          allocated by the WHIP endpoint for a specific media session. The
          WHIP client can send requests to the WHIP session using this URL to
          modify the session, such as ICE operations or termination.</t>
        </li>
      </ul>
      <t>The <xref session termination.</dd>
      </dl>

      <t><xref target="whip-protocol-operation"/> illustrates the
      communication flow between a WHIP client, WHIP endpoint, media server,
      and WHIP session. This flow outlines the process of setting up and
      tearing down an ingestion ingest session using the WHIP protocol, involving WHIP, which involves
      negotiation, ICE for Network Address Translation (NAT) traversal, DTLS
      and the Secure Real-time Transport Protocol (SRTP) for security, and
      RTP/RTCP for media transport:</t>

      <ul spacing="normal">
        <li>
          <t>WHIP client: Initiates
        <li>The WHIP client initiates the communication by sending an HTTP
        POST with an SDP Offer offer to the WHIP endpoint.</t> endpoint.
	</li>
        <li>
          <t>WHIP endpoint: Responds
        <li>The WHIP endpoint responds with a "201 Created" message containing
        an SDP answer.</t> answer.
	</li>
        <li>
          <t>WHIP
        <li>The WHIP client and media server: Establish an server establish ICE and DTLS
        sessions for NAT traversal and secure communication.</t> communication.
	</li>
        <li>
          <t>RTP/RTCP Flow: Real-time Transport Protocol
          <li>RTP and Real-time Transport Control Protocol RTCP flows are established for media transmission from the
          WHIP client to the media server, secured by the SRTP profile.</t> profile.
          </li>
        <li>
          <t>WHIP client: Sends
          <li>The WHIP client sends an HTTP DELETE to terminate the WHIP session.</t> session.
	  </li>
        <li>
          <t>WHIP session: Responds
          <li>The WHIP session responds with a "200 OK" to confirm the session termination.</t>
          termination.
	  </li>
      </ul>
    </section>
    <section anchor="protocol-operation">
      <name>Protocol Operation</name>
      <section anchor="http-usage">
        <name>HTTP usage</name> Usage</name>

        <t>Following the guidelines in <xref target="BCP56"/> guidelines, target="BCP56"/>, WHIP clients
        <bcp14>MUST NOT</bcp14> match error codes returned by the WHIP
        endpoints and resources to a specific error cause indicated in this
        specification. WHIP clients <bcp14>MUST</bcp14> be able to handle all
        applicable status codes by gracefully falling back to the generic n00
        semantics of a given status code on unknown error codes. WHIP
        endpoints and resources could convey finer-grained error information
        by a problem statement details json object in the response message body of the
        failed request as per <xref target="RFC9457"/>.</t>

        <t>The WHIP endpoints and sessions are origin servers as defined in
        <xref section="3.6." section="3.6" sectionFormat="of" target="RFC9110"/> handling target="RFC9110"/>; they handle the
        requests and providing provide responses for the underlying HTTP
        resources. Those HTTP resources do not have any representation defined
        in this specification, so the WHIP endpoints and sessions
        <bcp14>MUST</bcp14> return a 2XX sucessfull 2xx successful response with no content
        when a GET request is received.</t>
      </section>

      <section anchor="ingest-session-set-up">
        <name>Ingest session set up</name> Session Setup</name>

	<t>In order to set up an ingestion ingest session, the WHIP client
        <bcp14>MUST</bcp14> generate an SDP offer according to the JSEP rules
        for an initial offer as in per <xref section="5.2.1" sectionFormat="of"
        target="RFC9429"/> and perform send an HTTP POST request as per <xref
        section="9.3.3" sectionFormat="of" target="RFC9110"/> to the
        configured WHIP endpoint URL.</t>

        <t>The HTTP POST request <bcp14>MUST</bcp14> have a content type of
        "application/sdp" and contain the SDP offer as the body. The WHIP
        endpoint <bcp14>MUST</bcp14> generate an SDP answer according to the
        JSEP rules for an initial answer as in per <xref section="5.3.1"
        sectionFormat="of" target="RFC9429"/> and return the following: a "201 Created"
        response with a content type of "application/sdp", the SDP answer as
        the body, and a Location header field pointing to the newly created
        WHIP session. If the HTTP POST to the WHIP endpoint has a content type
        different than "application/sdp" or the SDP is malformed, the WHIP
        endpoint <bcp14>MUST</bcp14> reject the HTTP POST request with an appropiate 4XX
        appropriate 4xx error response.</t>

        <t>As the WHIP protocol only supports the ingestion use case with
        unidirectional media, the WHIP client <bcp14>SHOULD</bcp14> use the
        "sendonly" attribute in the SDP offer but <bcp14>MAY</bcp14> use the
        "sendrecv" attribute instead, instead; the "inactive" and "recvonly" attributes
        <bcp14>MUST NOT</bcp14> be used. The WHIP endpoint <bcp14>MUST</bcp14>
        use the "recvonly" attribute in the SDP answer.</t>
        <t>Following <xref

        <t><xref target="sdp-exchange-example"/> is an example of an
        HTTP POST sent from a WHIP client to a WHIP endpoint and the "201
        Created" response from the WHIP endpoint containing the Location
        header pointing to the newly created WHIP session:</t> session.</t>
        <figure anchor="sdp-exchange-example">
          <name>Example of the SDP offer/answer exchange done Offer/Answer Exchange Done via an HTTP POST</name>
          <artwork><![CDATA[
          <sourcecode type="http-message"><![CDATA[
POST /whip/endpoint HTTP/1.1
Host: whip.example.com
Content-Type: application/sdp
Content-Length: 1101

v=0
o=- 5228595038118931041 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=ice-options:trickle ice2
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:EsAw
a=ice-pwd:bP+XJMM09aR8AiX1jdukzR6Y
a=fingerprint:sha-256 DA:7B:57:DC:28:CE:04:4F:31:79:85:C4:31:67:EB:27:58:29:ED:77:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02 DA:7B:57:DC:28:CE:04:4F:31:79:85:C4:31:67:EB:
   27:58:29:ED:77:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02
a=setup:actpass
a=mid:0
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendonly
a=msid:d46fb922-d52a-4e9c-aa87-444eadc1521b ce326ecf-a081-453a-8f9f-0605d5ef4128 ce326ecf-a081-453a-8f9f-
   0605d5ef4128
a=rtcp-mux
a=rtcp-mux-only
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
m=video 0 UDP/TLS/RTP/SAVPF 96 97
a=mid:1
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendonly
a=msid:d46fb922-d52a-4e9c-aa87-444eadc1521b 3956b460-40f4-4d05-acef-03abcdd8c6fd 3956b460-40f4-4d05-acef-
   03abcdd8c6fd
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96

HTTP/1.1 201 Created
ETag: "xyzzy"
Content-Type: application/sdp
Content-Length: 1053
Location: https://whip.example.com/session/id

v=0
o=- 1657793490019 1 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=ice-lite
a=ice-options:trickle ice2
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:38sdf4fdsf54
a=ice-pwd:2e13dde17c1cb009202f627fab90cbec358d766d049c9697
a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:
   DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD
a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host
a=setup:passive
a=mid:0
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=recvonly
a=rtcp-mux
a=rtcp-mux-only
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
m=video 0 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=mid:1
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
]]></artwork>
]]></sourcecode>
        </figure>

        <t>Once a session is set up, consent freshness as per <xref
        target="RFC7675"/> <bcp14>SHALL</bcp14> be used to detect non-graceful
        disconnection by full ICE implementations and DTLS teardown for
        session termination by either side.</t>

        <t>To explicitly terminate a WHIP session, the WHIP client
        <bcp14>MUST</bcp14> perform send an HTTP DELETE request to the WHIP session
        URL returned in the Location header field of the initial HTTP
        POST. Upon receiving the HTTP DELETE request, the WHIP session will be
        removed and the resources freed on the media server, terminating the
        ICE and DTLS sessions.</t>

        <t>A media server terminating a session <bcp14>MUST</bcp14> follow the
        procedures in <xref section="5.2" sectionFormat="of"
        target="RFC7675"/> for immediate revocation of consent.</t>

        <t>The WHIP endpoints <bcp14>MUST</bcp14> support OPTIONS requests for
        Cross-Origin Resource Sharing (CORS) as defined in <xref
        target="FETCH"/>. The "200 OK" response to any OPTIONS request
        <bcp14>SHOULD</bcp14> include an "Accept-Post" Accept-Post header with a media
        type value of "application/sdp" as per <xref
        target="W3C.REC-ldp-20150226"/>.</t>
      </section>

      <section anchor="ice-support">
        <name>ICE support</name> Support</name>

        <t>ICE <xref target="RFC8845"/> target="RFC8445"/> is a protocol addressing that addresses the
        complexities of NAT traversal, traversal commonly encountered in Internet
        communication. NATs hinder direct communication between devices on
        different local networks, posing challenges for real-time
        applications. ICE facilitates seamless connectivity by employing
        techniques to discover and negotiate efficient communication
        paths.</t>

        <t>Trickle ICE <xref target="RFC8838"/> optimizes the connectivity
        process by incrementally sharing potential communication paths,
        reducing latency, and facilitating quicker establishment.</t>

        <t>ICE Restarts restarts are crucial for maintaining connectivity in dynamic
        network conditions or disruptions, allowing devices to re-establish
        communication paths without complete renegotiation. This ensures
        minimal latency and reliable real-time communication.</t>

        <t>Trickle ICE and ICE restart support are <bcp14>RECOMMENDED</bcp14>
        for both WHIP sessions and clients.</t>

        <section anchor="http-patch-usage">
          <name>HTTP PATCH request usage</name> Request Usage</name>

          <t>The WHIP client <bcp14>MAY</bcp14> perform trickle Trickle ICE or ICE
          restarts by sending an HTTP PATCH request as per <xref
          target="RFC5789"/> to the WHIP session URL, with URL. This HTTP PATCH request <bcp14>MUST</bcp14> contain a body containing with
          an SDP fragment with media type "application/trickle-ice-sdpfrag" as
          specified in <xref target="RFC8840"/> carrying target="RFC8840"/>, which carries the relevant ICE
          information. If the HTTP PATCH request sent to the WHIP session URL has a content
          type different than "application/trickle-ice-sdpfrag" or the SDP
          fragment is malformed, the WHIP session <bcp14>MUST</bcp14> reject
          the HTTP PATCH with an appropiate 4XX appropriate 4xx error response.</t>

          <t>If the WHIP session supports either Trickle ICE or ICE restarts,
          but not both, it <bcp14>MUST</bcp14> return a "422 Unprocessable
          Content" error response for the HTTP PATCH requests that are not
          supported as per <xref section="15.5.21" sectionFormat="of"
          target="RFC9110"/>.</t>

          <t>The WHIP client <bcp14>MAY</bcp14> send overlapping HTTP PATCH
          requests to one WHIP session. Consequently, as those HTTP PATCH
          requests may be received out-of-order out of order by the WHIP session, session. Thus, if the WHIP
          session supports ICE restarts, it <bcp14>MUST</bcp14> generate a
          unique strong entity-tag identifying the ICE session as per <xref
          section="8.8.3" sectionFormat="of" target="RFC9110"/>, being
          <bcp14>OPTIONAL</bcp14> otherwise. The initial value of the
          entity-tag identifying the initial ICE session <bcp14>MUST</bcp14>
          be returned in an ETag header field in the "201 Created" response to
          the initial POST request to the WHIP endpoint.</t>

          <t>WHIP clients <bcp14>SHOULD NOT</bcp14> use entity-tag validation
          when matching a specific ICE session is not required, such as for example example, when
          initiating a DELETE request to terminate a session.
          WHIP sessions <bcp14>MUST</bcp14> ignore any entity-tag
          value sent by the WHIP client when ICE session matching is not
          required, as in the HTTP DELETE request.</t>

	  <t>Missing or outdated ETags in the PATCH requests from WHIP clients
          will be answered by WHIP sessions as per <xref section="13.1.1"
          sectionFormat="of" target="RFC9110"/> and <xref section="3"
          sectionFormat="of" target="RFC6585"/>, with a "428 Precondition
          Required" response for a missing entity tag, entity-tag and a "412 Precondition
          Failed" response for a non-matching entity tag.</t> entity-tag.</t>
        </section>
        <section anchor="trickle-ice">
          <name>Trickle ICE</name>

          <t>Depending on the Trickle ICE support on the WHIP client, the
          initial offer by the WHIP client <bcp14>MAY</bcp14> be sent after
          the full ICE gathering is complete with the full list of ICE
          candidates, or it <bcp14>MAY</bcp14> only contain local candidates
          (or even an empty list of candidates) as per <xref target="RFC8845"/>.
          target="RFC8445"/>. For the purpose of reducing setup times, when
          using Trickle ICE ICE, the WHIP client <bcp14>SHOULD</bcp14> send the SDP
          offer as soon as possible, containing (containing either locally gathered ICE
          candidates or an empty list of candidates.</t> candidates) as soon as possible.</t>
          <t>In order to simplify the protocol, the WHIP session cannot signal
          additional ICE candidates to the WHIP client after the SDP answer
          has been sent. The WHIP endpoint <bcp14>SHALL</bcp14> gather all the
          ICE candidates for the media server before responding to the client request
          request, and the SDP answer <bcp14>SHALL</bcp14> contain the full
          list of ICE candidates of the media server.</t>

          <t>As the WHIP client needs to know the WHIP session URL associated
          with the ICE session in order to send a PATCH request containing new
          ICE candidates, it <bcp14>MUST</bcp14> wait and buffer any gathered
          candidates until the "201 Created" HTTP response to the initial POST
          request is received.  In order to lower reduce the HTTP traffic and
          processing time required required, the WHIP client <bcp14>SHOULD</bcp14> send
          a single aggregated HTTP PATCH request with all the buffered ICE
          candidates once the response is received.  Additionally, if ICE
          restarts are supported by the WHIP session, the WHIP client needs to
          know the entity-tag associated with the ICE session in order to send
          a PATCH request containing new ICE candidates, so candidates; thus, it
          <bcp14>MUST</bcp14> also wait and buffer any gathered candidates
          until it receives the HTTP response with the new entity-tag value to
          the last PATCH request performing an ICE restart.</t>
          <t>WHIP clients generating the HTTP PATCH body with the SDP fragment
          and its subsequent processing by WHIP sessions <bcp14>MUST</bcp14>
          follow to the guidelines defined in <xref section="4.4"
          sectionFormat="of" target="RFC8840"/> with the following
          considerations:</t>
          <ul spacing="normal">
            <li>
              <t>As per <xref target="RFC9429"/>, only m-sections "m=" sections not marked
              as bundle-only can gather ICE candidates, so given that the
              "max-bundle" policy is being used, the SDP fragment will contain
              only the offerer-tagged m-line "m=" line of the bundle group.</t>
            </li>
            <li>
              <t>The WHIP client <bcp14>MAY</bcp14> exclude ICE candidates
              from the HTTP PATCH body if they have already been confirmed by
              the WHIP session with a successful HTTP response to a previous
              HTTP PATCH request.</t>
            </li>
          </ul>
          <t>WHIP sessions and clients that support Trickle ICE
          <bcp14>MUST</bcp14> make use of entity-tags and conditional requests
          as explained in <xref target="http-patch-usage"/>.</t>
          <t>When a WHIP session receives a PATCH request that adds new ICE
          candidates without performing an ICE restart, it <bcp14>MUST</bcp14>
          return a "204 No Content" response without a body and <bcp14>MUST
          NOT</bcp14> include an ETag header in the response. If the WHIP
          session does not support a candidate transport or is not able to
          resolve the connection address, it <bcp14>MUST</bcp14> silently
          discard the candidate and continue processing the rest of the
          request normally.</t>

          <t><xref target="trickle-ice-example"/> shows an example of the
          Trickle ICE procedure where the WHIP client sends a PATCH request
          with updated ICE candidate information and receives a successful
          response from the WHIP session.</t>

          <figure anchor="trickle-ice-example">
            <name>Example of a Trickle ICE request Request and response</name>
            <artwork><![CDATA[ Response</name>
            <sourcecode type="http-message"><![CDATA[
PATCH /session/id HTTP/1.1
Host: whip.example.com
If-Match: "xyzzy"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 576

a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0
a=ice-ufrag:EsAw
a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1
a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host
   generation 0 ufrag EsAw network-id 1
a=candidate:3471623853 1 udp 2122194687 198.51.100.2 61765 typ host
   generation 0 ufrag EsAw network-id 2
a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype
   active generation 0 ufrag EsAw network-id 1
a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host
   tcptype active generation 0 ufrag EsAw network-id 2
a=end-of-candidates

HTTP/1.1 204 No Content
]]></artwork>
]]></sourcecode>
          </figure>
          <t><xref target="trickle-ice-example"/> shows an example of the Trickle ICE procedure where the WHIP client sends a PATCH request with updated ICE candidate information and receives a successful response from the WHIP session.</t>

        </section>

        <section anchor="ice-restarts">
          <name>ICE Restarts</name>
          <t>As defined in <xref target="RFC8839"/>, when an ICE restart
          occurs, a new SDP offer/answer exchange is triggered. However, as
          WHIP does not support renegotiation of non-ICE related non-ICE-related SDP
          information, a WHIP client will not send a new offer when an ICE
          restart occurs. Instead, the WHIP client and WHIP session will only
          exchange the relevant ICE information via an HTTP PATCH request as
          defined in <xref target="http-patch-usage"/> and <bcp14>MUST</bcp14>
          assume that the previously negotiated non-ICE related non-ICE-related SDP
          information still apply applies after the ICE restart.</t>
          <t>When performing an ICE restart, the WHIP client
          <bcp14>MUST</bcp14> include the updated "ice-pwd" and "ice-ufrag" in
          the SDP fragment of the HTTP PATCH request body as well as the new
          set of gathered ICE candidates as defined in <xref
          target="RFC8840"/>.  Similar to what is defined in <xref
          target="trickle-ice"/>, as per <xref target="RFC9429"/> target="RFC9429"/>, only m-sections
          "m=" sections not marked as bundle-only can gather ICE candidates, so
          given that the "max-bundle" policy is being used, the SDP fragment
          will contain only the offerer-tagged m-line "m=" line of the bundle group.  A
          WHIP client sending a PATCH request for performing ICE restart
          <bcp14>MUST</bcp14> contain an "If-Match" If-Match header field with a
          field-value of "*" as per <xref section="13.1.1" sectionFormat="of"
          target="RFC9110"/>.</t>
          <t><xref target="RFC8840"/> states that an agent <bcp14>MUST</bcp14>
          discard any received requests containing "ice-pwd" and "ice-ufrag"
          attributes that do not match those of the current ICE Negotiation Session, however,
          Session. However, any WHIP session receiving an updated "ice-pwd"
          and "ice-ufrag" attributes <bcp14>MUST</bcp14> consider the request
          as performing an ICE restart instead and, if supported,
          <bcp14>SHALL</bcp14> return a "200 OK" with an
          "application/trickle-ice-sdpfrag" body containing the new ICE
          username fragment and password and a new set of ICE candidates for
          the WHIP session. Also, the "200 OK" response for a successful ICE
          restart <bcp14>MUST</bcp14> contain the new entity-tag corresponding
          to the new ICE session in an ETag response header field and
          <bcp14>MAY</bcp14> contain a new set of ICE candidates for the media
          server.</t>
          <t>As defined in <xref section="4.4.1.1.1" sectionFormat="of" target="RFC8839"/>
          target="RFC8839"/>, the set of candidates after an ICE restart may
          include some, none, or all of the previous candidates for that data
          stream and may include a totally new set of candidates. So Therefore, after
          performing a successful ICE restart, both the WHIP client and the
          WHIP session <bcp14>MUST</bcp14> replace the previous set of remote
          candidates with the new set exchanged in the HTTP PATCH request and
          response, discarding any remote ICE candidate not present on the new
          set. Both the WHIP client and the WHIP session <bcp14>MUST</bcp14>
          ensure that the HTTP PATCH requests request and response bodies include the
          same 'ice-options,' 'ice-pacing,' "ice-options," "ice-pacing," and 'ice-lite' "ice-lite" attributes as those
          used in the SDP offer or answer.</t>
          <t>If the ICE restart request cannot be satisfied by the WHIP
          session, the resource <bcp14>MUST</bcp14> return an appropriate HTTP
          error code and <bcp14>MUST NOT</bcp14> terminate the session
          immediately and keep the existing ICE session. The WHIP client
          <bcp14>MAY</bcp14> retry performing a new ICE restart or terminate
          the session by issuing an HTTP DELETE request instead. In any case,
          the session <bcp14>MUST</bcp14> be terminated if the ICE consent
          expires as a consequence of the failed ICE restart as per <xref
          section="5.1" sectionFormat="of" target="RFC7675"/>.</t>
          <t>In case of unstable network conditions, the ICE restart HTTP
          PATCH requests and responses might be received out of order. In
          order to mitigate this scenario, when the client performs an ICE
          restart, it <bcp14>MUST</bcp14> discard any previous ICE username
          and passwords password fragments and ignore any further HTTP PATCH response
          received from a pending HTTP PATCH request. WHIP clients
          <bcp14>MUST</bcp14> apply only the ICE information received in the
          response to the last sent request. If there is a mismatch between
          the ICE information at the WHIP client and at the WHIP session
          (because of an out-of-order request), the STUN Session Traversal
          Utilities for NAT (STUN) requests will contain invalid ICE
          information and will be dropped by the receiving side. If this
          situation is detected by the WHIP client, it <bcp14>MUST</bcp14>
          send a new ICE restart request to the server.</t>

          <t><xref target="trickle-restart-example"/> demonstrates a Trickle ICE
          restart procedure example. The WHIP client sends a PATCH request
          containing updated ICE information, including a new username fragment and
          password, along with newly gathered ICE candidates. In response, the
          WHIP session provides ICE information for the session after the ICE
          restart, including the updated username fragment and password, as well as the
          previous ICE candidate.</t>

          <figure anchor="trickle-restart-example">
            <name>Example of an ICE restart request Restart Request and response</name>
            <artwork><![CDATA[ Response</name>
            <sourcecode type="http-message"><![CDATA[
PATCH /session/id HTTP/1.1
Host: whip.example.com
If-Match: "*"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 82

a=ice-options:trickle ice2
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0
a=ice-ufrag:ysXw
a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k
a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host
   generation 0 ufrag EsAw network-id 1
a=candidate:3471623853 1 udp 2122194687 198.51.100.2 61765 typ host
   generation 0 ufrag EsAw network-id 2
a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype
   active generation 0 ufrag EsAw network-id 1
a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host
   tcptype active generation 0 ufrag EsAw network-id 2

HTTP/1.1 200 OK
ETag: "abccd"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 252

a=ice-lite
a=ice-options:trickle ice2
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0
a=ice-ufrag:289b31b754eaa438
a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a
a=candidate:1 1 udp 2130706431 198.51.100.1 39132 typ host
a=end-of-candidates
]]></artwork>
]]></sourcecode>
          </figure>
          <t><xref target="trickle-ice-example"/> demonstrates a Trickle ICE restart procedure example. The WHIP client sends a PATCH request containing updated ICE information, including a new ufrag and password, along with newly gathered ICE candidates. In response, the WHIP session provides ICE information for the session after the ICE restart, including the updated ufrag and password, as well as the previous ICE candidate.</t>

        </section>
      </section>
      <section anchor="webrtc-constraints">
        <name>WebRTC constraints</name> Constraints</name>
        <t>To simplify the implementation of WHIP in both clients and media
        servers, WHIP introduces specific restrictions on WebRTC usage. The
        following subsections will explain these restrictions in detail:</t> detail.</t>
        <section anchor="sdp-bundle">
          <name>SDP Bundle</name>
          <t>Both the WHIP client and the WHIP endpoint <bcp14>SHALL</bcp14>
          support <xref target="RFC9143"/> and use the "max-bundle" policy as
          defined in <xref target="RFC9429"/>. The WHIP client and the media
          server <bcp14>MUST</bcp14> support multiplexed media associated with
          the BUNDLE group as per <xref section="9" sectionFormat="of"
          target="RFC9143"/>. In addition, per <xref target="RFC9143"/> target="RFC9143"/>, the
          WHIP client and media server <bcp14>SHALL</bcp14> use RTP/RTCP
          multiplexing for all bundled media. In order to reduce the network
          resources required at the media server, both The the WHIP client and
          WHIP endpoints <bcp14>MUST</bcp14> include the "rtcp-mux-only"
          attribute in each bundled "m=" sections section as per <xref section="3"
          sectionFormat="of" target="RFC8858"/>.</t>
        </section>
        <section anchor="single-mediastream">
          <name>Single MediaStream</name>

          <t>WHIP only supports a single MediaStream as defined in <xref target="RFC8830"/> and therefore
          target="RFC8830"/>; therefore, all "m=" sections <bcp14>MUST</bcp14>
          contain a "msid" attribute with the same value. The MediaStream
          <bcp14>MUST</bcp14> contain at least one MediaStreamTrack of any
          media kind kind, and it <bcp14>MUST NOT</bcp14> have two or more than
          MediaStreamTracks for the same media (audio or video). However, it
          would be possible for future revisions of this spec specification to allow more
          than a single MediaStream or MediaStreamTrack of each media kind, so
          kind. Therefore, in order to ensure forward compatibility, if the
          number of audio and or and/or video MediaStreamTracks or the number of
          MediaStreams are not supported by the WHIP endpoint, it
          <bcp14>MUST</bcp14> reject the HTTP POST request with an a "422
          Unprocessable Content" or "400 Bad Request" error response. The WHIP
          endpoint <bcp14>MAY</bcp14> also return a problem statement as recommended in <xref target="http-usage"/> proving that provides further error
          details about the failed request.</t> request, as
          recommended in <xref target="http-usage"/>.</t>
        </section>

        <section anchor="no-partially-successful-answers">
          <name>No partially successful answers</name> Partially Successful Answers</name>
          <t>The WHIP endpoint <bcp14>SHOULD NOT</bcp14> reject individual
          "m=" sections as per <xref section="5.3.1" sectionFormat="of"
          target="RFC9429"/> in case there is any error processing the "m=" section, but
          section; instead, it <bcp14>SHOULD</bcp14> reject the HTTP POST request with an a "422 Unprocessable
          Content" or "400 Bad Request" error response to prevent having
          partially successful ingest sessions sessions, which can be misleading to end
          users. The WHIP endpoint <bcp14>MAY</bcp14> also return a problem
          statement as recommended in <xref target="http-usage"/> proving
          further error details about the failed request.</t>
        </section>
        <section anchor="dtls-setup-role-and-sdp-setup-attribute">
          <name>DTLS setup role Setup Role and SDP "setup" attribute</name> Attribute</name>
          <t>When a WHIP client sends an SDP offer, it <bcp14>SHOULD</bcp14>
          insert an SDP "setup" attribute with an "actpass" attribute value,
          as defined in <xref target="RFC8842"/>. However, if the WHIP client
          only implements the DTLS client role, it <bcp14>MAY</bcp14> use an
          SDP "setup" attribute with an "active" attribute value. If the WHIP
          endpoint does not support an SDP offer with an SDP "setup" attribute
          with an "active" attribute value, it <bcp14>SHOULD</bcp14> reject
          the request with an a "422 Unprocessable Content" or "400 Bad Request"
          error response.</t>
          <t>NOTE: <xref target="RFC8842"/> defines that the offerer
          must insert an SDP "setup" attribute with an "actpass" attribute
          value. However, the WHIP client will always communicate with a media
          server that is expected to support the DTLS server role, in which
          case the client might choose to only implement support for the DTLS
          client role.</t>
        </section>
        <section anchor="trickle-ice-and-ice-restarts">
          <name>Trickle ICE and ICE restarts</name> Restarts</name>
          <t>The media server <bcp14>SHOULD</bcp14> support full ICE, unless
          it is connected to the Internet with an IP address that is
          accessible by each WHIP client that is authorized to use it, in
          which case it <bcp14>MAY</bcp14> support only ICE lite. The WHIP
          client <bcp14>MUST</bcp14> implement and use full ICE.</t>
          <t>Trickle ICE and ICE restarts restart support is <bcp14>OPTIONAL</bcp14>
          for both the WHIP clients and media servers as explained in <xref
          target="ice-support"/>.</t>
        </section>
      </section>
      <section anchor="load-balancing-and-redirections">
        <name>Load balancing Balancing and redirections</name> Redirections</name>
        <t>WHIP endpoints and media servers might not be colocated on the same
        server, so it is possible to load balance incoming requests to
        different media servers.</t>

        <t>WHIP clients <bcp14>SHALL</bcp14> support HTTP redirections as per
        <xref section="15.4" sectionFormat="of" target="RFC9110"/>. In order
        to avoid POST requests to be being redirected as GET requests, status codes 301
        "301 Moved Permanently" and 302 "302 Found" <bcp14>MUST NOT</bcp14> be used and used; the preferred method
        for performing load balancing is via the "307 Temporary Redirect"
        response status code as described in <xref section="15.4.8"
        sectionFormat="of" target="RFC9110"/>. Redirections are not required
        to be supported for the PATCH and DELETE requests.</t>
        <t>In case of high load, the WHIP endpoints <bcp14>MAY</bcp14> return
        a "503 Service Unavailable" response indicating that the server is
        currently unable to handle the request due to a temporary overload or
        scheduled maintenance as described in <xref section="15.6.4"
        sectionFormat="of" target="RFC9110"/>, which will likely be alleviated
        after some delay. The WHIP endpoint might send a Retry-After header
        field indicating the minimum time that the user agent ought to wait
        before making a follow-up request as described in <xref
        section="10.2.3" sectionFormat="of" target="RFC9110"/>.</t>
      </section>
      <section anchor="stunturn-server-configuration">
        <name>STUN/TURN server configuration</name> Server Configuration</name>
        <t>The WHIP endpoint <bcp14>MAY</bcp14> return STUN/TURN server configuration URLs and credentials usable by the client in the "201 Created" response to the HTTP POST request to the WHIP endpoint URL.</t>
        <t>A reference to each STUN/TURN server will be returned using the "Link" Link header field <xref target="RFC8288"/> with a "rel" attribute value of "ice-server". The Link target URI is the server URI as defined in <xref target="RFC7064"/> and <xref target="RFC7065"/>. The credentials are encoded in the Link target attributes as follows:</t>

        <ul spacing="normal">
          <li>
            <t>username:
            <li>username: If the Link header field represents a TURN server, Traversal
            Using Relays around NAT (TURN) server and credential-type is "password", the "credential-type" attribute has a
            "password" value, then this attribute specifies the username to use with
            that TURN server.</t>
          </li>
          <li>
            <t>credential: server.</li>
            <li>credential: If the "credential-type" attribute is missing or
            has a "password" value, the credential this attribute represents a
            long-term authentication password, as described in <xref
            section="9.2" sectionFormat="of" target="RFC8489"/>.</t>
          </li>
          <li>
            <t>credential-type: target="RFC8489"/>.</li>
            <li>credential-type: If the Link header field represents a TURN
            server, then this attribute specifies how the credential "credential" attribute
            value should be used when that TURN server requests
            authorization. The default value if the attribute is not present
            is "password".</t>
          </li> "password".</li>
        </ul>

        <t><xref target="stun-server-example"/> illustrates the Link headers included in a "201 Created" response, providing the ICE server URLs and associated credentials.</t>

        <figure anchor="stun-server-example">
          <name>Example of a STUN/TURN servers configuration</name>
          <artwork><![CDATA[ Server's Configuration</name>
          <sourcecode type="http-message"><![CDATA[
Link: <stun:stun.example.net>; rel="ice-server"
Link: <turn:turn.example.net?transport=udp>; rel="ice-server";
      username="user"; credential="myPassword";
      credential-type="password"
Link: <turn:turn.example.net?transport=tcp>; rel="ice-server";
      username="user"; credential="myPassword";
      credential-type="password"
Link: <turns:turn.example.net?transport=tcp>; rel="ice-server";
      username="user"; credential="myPassword";
      credential-type="password"
]]></artwork>
]]></sourcecode>
        </figure>
        <t><xref target="stun-server-example"/> illustrates the Link headers included in a 201 Created response, providing the ICE server URLs and associated credentials.</t>

        <t>NOTE: The naming of both the "rel" attribute value of
        "ice-server" and the target attributes follows the one that used on in the
        RTCConfiguration dictionary in Section 4.2.1 of the W3C WebRTC
        recommendation (see <xref target="W3C.REC-webrtc-20210126"/> RTCConfiguration dictionary in section 4.2.1. target="W3C.REC-webrtc-20210126"/>). The "rel"
        attribute value of "ice-server" is not prepended with the
        "urn:ietf:params:whip:" so it can be reused by other specifications specifications,
        which may use this mechanism to configure the usage of STUN/TURN
        servers.</t>
        <t>NOTE: Depending on the ICE Agent agent implementation, the WHIP
        client may need to call the setConfiguration method before calling the
        setLocalDescription method with the local SDP offer in order
        to avoid having to perform an ICE restart for applying the updated
        STUN/TURN server configuration on the next ICE gathering
        phase.</t>

        <t>There are some WebRTC implementations that do not support updating
        the STUN/TURN server configuration after the local offer has been
        created as specified in <xref section="4.1.18" sectionFormat="of"
        target="RFC9429"/>. In order to support these clients, the WHIP
        endpoint <bcp14>MAY</bcp14> also include the STUN/TURN server
        configuration on in the responses to OPTIONS request requests sent to the WHIP
        endpoint URL before the POST request is sent. However, this method is
        <bcp14>NOT RECOMMENDED</bcp14> to be used by the WHIP clients and, clients, and if it is
        supported by the underlying WHIP client's webrtc WebRTC implementation, the
        WHIP client <bcp14>SHOULD</bcp14> wait for the information to be
        returned by the WHIP endpoint on in the response of the HTTP POST request
        instead.</t>
        <t>The generation of the TURN server credentials may require performing
        sending a request to an external provider, which can both add
        latency to the OPTIONS request processing and increase the processing
        required to handle that request. In order to prevent this, the WHIP
        endpoint <bcp14>SHOULD NOT</bcp14> return the STUN/TURN server
        configuration if the OPTIONS request is a preflight request for CORS
        as defined in <xref target="FETCH"/>, that is, if The the OPTIONS request
        does not contain an Access-Control-Request-Method with "POST" a POST value
        and the Access-Control-Request-Headers HTTP header does not contain
        the "Link" Link value.</t>
        <t>The WHIP clients <bcp14>MAY</bcp14> also support configuring the
        STUN/TURN server URIs with long term long-term credentials provided by either
        the broadcasting service or an external TURN provider, overriding the
        values provided by the WHIP endpoint.</t>
        <section anchor="congestion-control">
          <name>Congestion control</name> Control</name>

          <t><xref target="RFC8836"/> defines the congestion control
          requirements for interactive Real-Time real-time media to be used in
          WebRTC. These requirements are based on the assumption of the need to provide that the data continuously,
          needs to be provided continuously within a very limited time window (no more
          (a delay of no more than hundreds of milliseconds end-to-end). If
          the latency target is higher, some of the requirements present in RFC8836
          <xref target="RFC8836"/> could be relaxed to allow more flexible
          implementations.</t>
        </section>
      </section>
      <section anchor="authentication-and-authorization">
        <name>Authentication and authorization</name> Authorization</name>
        <t>All WHIP endpoints, sessions sessions, and clients <bcp14>MUST</bcp14>
        support HTTP Authentication authentication as per <xref section="11"
        sectionFormat="of" target="RFC9110"/> and target="RFC9110"/>. Additionally, in order to
        ensure interoperability, bearer token authentication as defined in the
        next section <bcp14>MUST</bcp14> be supported by all WHIP
        entities. However, this does not preclude the support of additional
        HTTP authentication schemes as defined in <xref section="11.6"
        sectionFormat="of" target="RFC9110"/>.</t>
        <section anchor="bearer-token-authentication">
          <name>Bearer token authentication</name> Token Authentication</name>

          <t>WHIP endpoints and sessions <bcp14>MAY</bcp14> require the HTTP
          request to be authenticated using an HTTP Authorization header field
          with a Bearer bearer token as specified in <xref section="2.1"
          sectionFormat="of" target="RFC6750"/>. WHIP clients
          <bcp14>MUST</bcp14> implement this authentication and authorization
          mechanism and send the HTTP Authorization header field in all HTTP
          requests sent to either the WHIP endpoint or session except (except the
          preflight OPTIONS requests for CORS.</t> CORS).</t>

          <t>The nature, syntax, and semantics of the bearer token, as well as
          how to distribute it to the client, is are outside the scope of this
          document. Some examples of the kind Examples of tokens that could be used are,
          include, but are not limited to, JWT tokens JSON Web Tokens (JWTs) as per
          <xref target="RFC6750"/> and <xref target="RFC8725"/> or and a shared secret
          stored on a database. The tokens are typically made available to the
          end user alongside the WHIP endpoint URL and configured on the WHIP
          clients (similar to the way RTMP Real Time Messaging Protocol (RTMP) URLs
          and Stream Keys are distributed).</t>
          <t>WHIP endpoints and sessions could perform the authentication and
          authorization by encoding an authentication token within the URLs
          for the WHIP endpoints or sessions instead. In case the WHIP client
          is not configured to use a bearer token, the HTTP Authorization
          header field <bcp14>MUST NOT</bcp14> be sent in any request.</t>
        </section>
      </section>
      <section anchor="simulcast-and-scalable-video-coding">
        <name>Simulcast and scalable video coding</name> Scalable Video Coding</name>
        <t>Simulcast as per <xref target="RFC8853"/> <bcp14>MAY</bcp14> be
        supported by both the media servers and WHIP clients through
        negotiation in the SDP offer/answer.</t>
        <t>If the client supports simulcast and wants to enable it for
        ingesting, it <bcp14>MUST</bcp14> negotiate the support in the SDP
        offer according to the procedures in <xref section="5.3"
        sectionFormat="of" target="RFC8853"/>. A server accepting a simulcast
        offer <bcp14>MUST</bcp14> create an answer according to the procedures
        in <xref section="5.3.2" sectionFormat="of" target="RFC8853"/>.</t>
        <t>It is possible for both media servers and WHIP clients to support
        Scalable Video Coding (SVC). However, as there is no universal
        negotiation mechanism in SDP for SVC, the encoder must consider the
        negotiated codec(s), intended usage, and SVC support in available
        decoders when configuring SVC.</t>
      </section>
      <section anchor="protocol-extensions">
        <name>Protocol extensions</name> Extensions</name>
        <t>In order to support future extensions to be defined for the WHIP protocol, WHIP, a common procedure for registering and announcing the new
        extensions is defined.</t>
        <t>Protocol extensions supported by the WHIP sessions
        <bcp14>MUST</bcp14> be advertised to the WHIP client in the "201
        Created" response to the initial HTTP POST request sent to the WHIP
        endpoint.  The WHIP endpoint <bcp14>MUST</bcp14> return one "Link" Link
        header field for each extension that it supports, with the extension
        "rel" attribute value containing the extension URN and the URL for the
        HTTP resource that will be available for receiving requests related to
        that extension.</t>
        <t>Protocol extensions are optional for both WHIP clients and
        servers. WHIP clients <bcp14>MUST</bcp14> ignore any Link target attribute
        with an unknown "rel" attribute value value, and WHIP sessions <bcp14>MUST
        NOT</bcp14> require the usage of any extension.</t>

        <t>Each protocol extension <bcp14>MUST</bcp14> register a unique "rel"
        attribute value at IANA starting that starts with the prefix: prefix
        "urn:ietf:params:whip:ext" as defined in <xref target="urn-whip-subspace"/>.</t> the "WebRTC-HTTP Ingestion Protocol (WHIP)
    Extension URNs" registry (<xref
        target="urn-whip-ext-registry"/>).</t>
        <t>For example, considering consider a potential extension of server-to-client
        communication using server-sent events as specified in https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events, the Section 9.2 of
        <xref target="HTML"/>. The URL for connecting to the server-sent event
        resource for the ingested stream could be returned in the initial HTTP
        "201 Created" response with a "Link" Link header field and a "rel"
        attribute of "urn:ietf:params:whip:ext:example:server-sent-events"
        (this document does not specify such an extension, extension and uses it only as
        an example).</t>
        <t>In this theoretical case, the "201 Created" response to the HTTP
        POST request would look like:</t>
        <figure anchor="protocol-extension-example">
          <name>Example of a WHIP protocol extension</name>
          <artwork><![CDATA[
HTTP/1.1 201 Created
Content-Type: application/sdp
Location: https://whip.example.com/session/id
Link: <https://whip.example.com/session/id/sse>;
      rel="urn:ietf:params:whip:ext:example:server-sent-events"
]]></artwork>
        </figure>

        <t><xref target="protocol-extension-example"/> shows an example of a the "201 Created"
        response to the HTTP POST request in this theoretical case (i.e., the
        WHIP protocol extension supported by the WHIP session, as indicated in
        the Link header of the "201 Created" response).
	</t>

        <figure anchor="protocol-extension-example">
          <name>Example of a WHIP Extension</name>
          <sourcecode type="http-message"><![CDATA[
HTTP/1.1 201 Created response.</t>
Content-Type: application/sdp
Location: https://whip.example.com/session/id
Link: <https://whip.example.com/session/id/sse>;
      rel="urn:ietf:params:whip:ext:example:server-sent-events"
]]></sourcecode>
        </figure>

      </section>
    </section>

    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document specifies a new protocol on top of HTTP and WebRTC, WebRTC;
      thus, security protocols and considerations from related specifications
      apply to the WHIP specification. These include:</t>
      <ul spacing="normal">
        <li>
          <t>WebRTC

      <ul>
          <li>WebRTC security considerations: See <xref
          target="RFC8826"/>. HTTPS <bcp14>SHALL</bcp14> be used in order to
          preserve the WebRTC security model.</t>
        </li>
        <li>
          <t>Transport model.</li>
          <li>Transport Layer Security (TLS): See <xref target="RFC8446"/> and
          <xref target="RFC9147"/>.</t>
        </li>
        <li>
          <t>HTTP target="RFC9147"/>.</li>
          <li>HTTP security: See <xref section="11" sectionFormat="of"
          target="RFC9112"/> and <xref section="17" sectionFormat="of" target="RFC9110"/>.</t>
        </li>
        <li>
          <t>URI
          target="RFC9110"/>.</li>
          <li>URI security: See <xref section="7" sectionFormat="of" target="RFC3986"/>.</t>
        </li> target="RFC3986"/>.</li>
      </ul>
      <t>On top of that, the WHIP protocol exposes a thin new attack surface
      specific of to the REST API methods used within it:</t>

      <ul spacing="normal">
        <li>
          <t>HTTP
          <li>HTTP POST flooding and resource exhaustion: It would be possible
          for an attacker in possession of authentication credentials valid
          for ingesting a WHIP stream to make multiple HTTP POST requests to the WHIP
          endpoint.  This will force the WHIP endpoint to process the incoming
          SDP and allocate resources for being able to set up the DTLS/ICE
          connection.  While the malicious client does not need to initiate
          the DTLS/ICE connection at all, the WHIP session will have to wait
          for the DTLS/ICE connection timeout in order to release the
          associated resources.  If the connection rate is high enough, this
          could lead to resource exhaustion on the servers handling the requests
          requests, and it they will not be able to process legitimate incoming
          ingests.  In order to prevent this scenario, WHIP endpoints
          <bcp14>SHOULD</bcp14> implement a rate limit and avalanche control
          mechanism for incoming initial HTTP POST requests.</t>
        </li>
        <li>
          <t>Insecure direct object references (IDOR) on the requests.</li>

<li>Insecure Direct Object References (IDORs) for WHIP session locations: URLs:
     If the URLs returned by the WHIP endpoint for the location of WHIP
     sessions location are easy to guess, it would be possible for an
     attacker to send multiple HTTP DELETE requests and terminate all
     the WHIP sessions currently running.
	  In order to prevent this scenario,
          WHIP endpoints <bcp14>SHOULD</bcp14> generate URLs with enough
          randomness, using a cryptographically secure pseudorandom number
          generator following the best practices in Randomness "Randomness Requirements
          for Security Security" <xref target="RFC4086"/>, and implement a rate limit and avalanche control
          mechanism for HTTP DELETE requests.  The security considerations for
          Universally Unique IDentifier (UUID) IDentifiers (UUIDs) in <xref section="8" sectionFormat="comma"
          sectionFormat="of" target="RFC9562"/> are applicable for generating the
          WHIP sessions location URL.</t>
        </li>
        <li>
          <t>HTTP session URLs.</li>

          <li>HTTP PATCH flooding: Similar to the HTTP POST flooding, a
          malicious client could also create a resource exhaustion by sending
          multiple HTTP PATCH request requests to the WHIP session, although the WHIP
          sessions can limit the impact by not allocating new ICE candidates
          and reusing the existing ICE candidates when doing ICE restarts.  In
          order to prevent this scenario, WHIP endpoints <bcp14>SHOULD</bcp14>
          implement a rate limit and avalanche control mechanism for incoming
          HTTP PATCH requests.</t>
        </li> requests.</li>
      </ul>
    </section>
    <section anchor="iana-considerations">

      <name>IANA Considerations</name>
      <t>This specification adds

      <t>Per this specification, IANA has added a new link relation type and
   a registry for new URN sub-namespaces sub-namespace for WHIP protocol extensions.</t> WHIP. IANA has also created registries
   to manage entries within the "urn:ietf:params:whip" and
   "urn:ietf:params:whip:ext" namespaces.
      </t>

      <section anchor="link-relation-type-ice-server">
        <name>Link Relation Type: ice-server</name>
        <t>The link relation type below has been registered by IANA in the
        "Link Relation Types" registry per <xref section="4.2"
        sectionFormat="of" target="RFC8288"/>.</t>
        <t>Relation Name: ice-server</t>
        <t>Description: Conveys target="RFC8288"/>:</t>

	<dl newline="false" spacing="normal">
        <dt>Relation Name:</dt><dd>ice-server</dd>
        <dt>Description:</dt><dd>Conveys the STUN and TURN servers that can be used by
        an ICE Agent agent to establish a connection with a peer.</t>
        <t>Reference: TBD</t> peer.</dd>
        <dt>Reference:</dt><dd>RFC 9725</dd>
	</dl>
      </section>

      <section anchor="webrtc-http-ingestion-protocol-whip-registry-group">
        <name>WebRTC-HTTP Ingestion Protocol (WHIP) registry group</name>
        <t>IANA  is asked to create a new registry group called "WebRTC-HTTP Ingestion Protocol (WHIP)". This group includes the "WebRTC-HTTP ingestion protocol (WHIP) URNs" and "WebRTC-HTTP ingestion protocol (WHIP) extension URNs" registries described below.</t>
      </section>
      <section anchor="registration-of-whip-urn-sub-namespace-and-whip-registries">
        <name>Registration of WHIP URN anchor="urn-whip-subspace">
        <name>URN Sub-namespace and for WHIP registries</name>
        <t>IANA is asked to add an (urn:ietf:params:whip)</name>

<t> IANA has added a new entry to in the "IETF “IETF URN Sub-namespace for Registered
Protocol Parameter Identifiers" registry and create a sub-namespace for Identifiers” registry, following the Registered Parameter Identifier as per template in <xref target="RFC3553"/>: "urn:ietf:params:whip".</t>
target="RFC3553"/>:</t>

<dl newline="false">
 <dt>Registry name:</dt><dd>whip</dd>
 <dt>Specification:</dt><dd>RFC 9725</dd>
 <dt>Repository:</dt><dd>&lt;https://www.iana.org/assignments/whip&gt;</dd>
 <dt>Index value:</dt><dd>TBD</dd>
</dl>

<t>To manage this sub-namespace, IANA is asked to create the has created two registries within
a new registry group called "WebRTC-HTTP ingestion protocol Ingestion Protocol (WHIP)":</t>

<ul>
<li>"WebRTC-HTTP Ingestion Protocol (WHIP) URNs" and "WebRTC-HTTP ingestion protocol registry (<xref target="urn-whip-registry"/>)</li>
<li>"WebRTC-HTTP Ingestion Protocol (WHIP) extension URNs".</t> Extension URNs" registry (<xref target="urn-whip-ext-registry"/>)</li>
</ul>
      </section>

        <section anchor="urn-whip-registry">
          <name>WebRTC-HTTP ingestion protocol Ingestion Protocol (WHIP) URNs registry</name> Registry</name>
          <t>The "WebRTC-HTTP ingestion protocol Ingestion Protocol (WHIP) URNs" registry is used
          to manage entries within the "urn:ietf:params:whip" namespace. The registry descriptions
          registration procedure is as follows:</t>
          <ul spacing="normal">
            <li>
              <t>Registry group: WebRTC-HTTP ingestion protocol (WHIP)</t>
            </li>
            <li>
              <t>Registry name: WebRTC-HTTP ingestion protocol (WHIP) URNs</t>
            </li>
            <li>
              <t>Specification: this document (RFC TBD)</t>
            </li>
            <li>
              <t>Registration procedure: Specification Required</t>
            </li>
            <li>
              <t>Field names: "Specification Required" <xref target="RFC8126"/>.  The registry contains the following fields:
	  URI, description, change controller, reference and Description, Reference, IANA registry reference</t>
            </li>
          </ul> Registry Reference, and Change Controller. This document is listed as the reference.</t>

          <t>The registry contains a single initial value:</t>
          <ul entry:</t>
          <dl spacing="normal">
            <li>
              <t>URI: urn:ietf:params:whip:ext</t>
            </li>
            <li>
              <t>Description: WebRTC-HTTP ingestion protocol
              <dt>URI:</dt><dd>urn:ietf:params:whip:ext</dd>
              <dt>Description:</dt><dd>WebRTC-HTTP Ingestion Protocol (WHIP) extension URNs</t>
            </li>
            <li>
              <t>Change Controller: IETF</t>
            </li>
            <li>
              <t>Reference: this document (RFC TBD) Section <xref target="urn-whip-ext-registry"/></t>
            </li>
            <li>
              <t>IANA registry reference: WebRTC-HTTP ingestion protocol URNs</dd>
              <dt>Reference:</dt><dd><xref target="urn-whip-ext-registry"/> of RFC 9725</dd>
              <dt>IANA Registry Reference:</dt><dd>See "WebRTC-HTTP Ingestion Protocol (WHIP) extension URNs registry.</t>
            </li>
          </ul> Extension URNs" on &lt;https://www.iana.org/assignments/whip&gt;</dd>
	      <dt>Change Controller:</dt><dd>IETF</dd>

          </dl>
        </section>

        <section anchor="urn-whip-ext-registry">
          <name>WebRTC-HTTP ingestion protocol Ingestion Protocol (WHIP) extension Extension URNs registry</name> Registry</name>
          <t>The "WebRTC-HTTP ingestion protocol Ingestion Protocol (WHIP) Extension URNs" registry is
          used to manage entries within the "urn:ietf:params:whip:ext"
          namespace.  The registry descriptions registration procedure is as follows:</t>
          <ul spacing="normal">
            <li>
              <t>Registry group: WebRTC-HTTP ingestion protocol (WHIP)</t>
            </li>
            <li>
              <t>Registry name: WebRTC-HTTP ingestion protocol (WHIP) Extension URNs</t>
            </li>
            <li>
              <t>Specification: this document (RFC TBD)</t>
            </li>
            <li>
              <t>Registration procedure: Specification Required</t>
            </li>
            <li>
              <t>Field names: "Specification Required"
          <xref target="RFC8126"/>.
          The registry contains the following fields:
	  URI, description, change controller, reference and Description, Reference, IANA registry reference</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="urn-whip-subspace">
        <name>URN Sub-namespace for WHIP</name>
        <t>WHIP endpoint utilizes URNs to identify Registry Reference, and Change Controller. This document is listed as the supported reference.
          </t>
        <t>A WHIP protocol extensions on extension URN is used as a value in the "rel" attribute of the Link header as defined in <xref target="protocol-extensions"/>.</t>
        <t>This section creates and registers an IETF URN Sub-namespace target="protocol-extensions"/> for use in the WHIP specifications and future extensions.</t>
        <section anchor="specification-template">
          <name>Specification Template</name>
          <t>Namespace ID:</t>
          <ul spacing="normal">
            <li>
              <t>The Namespace ID "whip" has been assigned.</t>
            </li>
          </ul>
          <t>Registration Information:</t>
          <ul spacing="normal">
            <li>
              <t>Version: 1</t>
            </li>
            <li>
              <t>Date: TBD</t>
            </li>
          </ul>
          <t>Declared registrant purpose of signaling the namespace:</t>
          <ul spacing="normal">
            <li>
              <t>Registering organization: The Internet Engineering Task Force.</t>
            </li>
            <li>
              <t>Designated contact: A designated expert will monitor WHIP extensions supported by the WHIP public mailing list, "wish@ietf.org".</t>
            </li>
          </ul>
          <t>Declaration of Syntactic Structure:</t>
          <ul spacing="normal">
            <li>
              <t>The Namespace Specific String (NSS) of all endpoint. WHIP extension URNs that use the "whip" Namespace ID shall have the following structure: urn:ietf:params:whip:{type}:{name}:{other}.</t>
            </li>
            <li>
              <t>The keywords have the following meaning:  </t>
              <ul spacing="normal">
                <li>
                  <t>type: The entity type. This specification only defines the "ext" type.</t>
                </li>
                <li>
                  <t>name: A required ASCII string that conforms to the URN syntax requirements (see <xref target="RFC8141"/>) and defines a major namespace of a WHIP protocol extension. The value <bcp14>MAY</bcp14> also be an industry name or organization name.</t>
                </li>
                <li>
                  <t>other: Any ASCII string that conforms to the URN syntax requirements (see <xref target="RFC8141"/>) and defines the sub-namespace (which <bcp14>MAY</bcp14> be further broken down in namespaces delimited by colons) as needed to uniquely identify an WHIP protocol extension.</t>
                </li>
              </ul>
            </li>
          </ul>
          <t>Relevant Ancillary Documentation:</t>
          <ul spacing="normal">
            <li>
              <t>None</t>
            </li>
          </ul>
          <t>Identifier Uniqueness Considerations:</t>
          <ul spacing="normal">
            <li>
              <t>The designated contact shall be responsible for reviewing and enforcing uniqueness.</t>
            </li>
          </ul>
          <t>Identifier Persistence Considerations:</t>
          <ul spacing="normal">
            <li>
              <t>Once a name has been allocated, it <bcp14>MUST NOT</bcp14> be reallocated for a different purpose.</t>
            </li>
            <li>
              <t>The rules provided for assignments of values within a sub-namespace <bcp14>MUST</bcp14> be constructed so that the meanings of values cannot change.</t>
            </li>
            <li>
              <t>This registration mechanism is not appropriate for naming values whose meanings may change over time.</t>
            </li>
          </ul>
          <t>Process of Identifier Assignment:</t>
          <ul spacing="normal">
            <li>
              <t>Namespace with type "ext" (e.g., "urn:ietf:params:whip:ext") is reserved for IETF-approved WHIP specifications.</t>
            </li>
          </ul>
          <t>Process of Identifier Resolution:</t>
          <ul spacing="normal">
            <li>
              <t>None specified.</t>
            </li>
          </ul>
          <t>Rules for Lexical Equivalence:</t>
          <ul spacing="normal">
            <li>
              <t>No special considerations; the rules for lexical equivalence specified in <xref target="RFC8141"/> apply.</t>
            </li>
          </ul>
          <t>Conformance with URN Syntax:</t>
          <ul spacing="normal">
            <li>
              <t>No special considerations.</t>
            </li>
          </ul>
          <t>Validation Mechanism:</t>
          <ul spacing="normal">
            <li>
              <t>None specified.</t>
            </li>
          </ul>
          <t>Scope:</t>
          <ul spacing="normal">
            <li>
              <t>Global.</t>
            </li>
          </ul>
        </section> type.</t>

        </section>

      <section anchor="registering-whip-protocol-extensions-urns">
        <name>Registering WHIP Protocol Extensions URNs and WHIP Extension URNs</name>
        <t>This section defines the process for registering new WHIP protocol extensions URNs with IANA in the
        "WebRTC-HTTP ingestion protocol Ingestion Protocol (WHIP) extension URNs" registry (see <xref target="urn-whip-subspace"/>).</t>
        <t>A WHIP Protocol Extension URNs is used as a value in the "rel" attribute of the Link header as defined in <xref target="protocol-extensions"/> for the purpose of signaling the WHIP protocol extensions supported by (<xref
        target="urn-whip-registry"/>) and the WHIP endpoints.</t>
        <t>WHIP "WebRTC-HTTP Ingestion Protocol Extensions URNs have an "ext" type as defined in <xref target="urn-whip-subspace"/>.</t>
        (WHIP) Extension URNs" registry (<xref target="urn-whip-ext-registry"/>).
	</t>
        <section anchor="registration-procedure">
          <name>Registration Procedure</name>
          <t>The IETF has created a mailing list, "wish@ietf.org", &lt;wish@ietf.org&gt;, which can
          be used for public discussion of proposals regarding WHIP protocol extensions proposals
          prior to registration.  Use of the mailing list is strongly
          encouraged. The IESG has
   appointed a A designated expert as per (DE) <xref target="RFC8126"/> who
          target="RFC8126"/>, appointed by the IESG,  will monitor the
   wish@ietf.org &lt;wish@ietf.org&gt; mailing list
          and review registrations.</t>
          <t>Registration of new "ext" type URNs (in the namespace
          "urn:ietf:params:whip:ext") belonging to a WHIP Protocol Extension extension
          <bcp14>MUST</bcp14> be documented in a permanent and readily
          available public specification, in sufficient detail so that
          interoperability between independent implementations is possible possible, and
          reviewed by the designated expert DE as per Section 4.6 of <xref section="4.6"
          sectionFormat="of" target="RFC8126"/>.
   An  A Standards Track RFC is
          <bcp14>REQUIRED</bcp14> for the registration of new value data types
          that modify existing properties.
   An  A Standards Track RFC is also
          <bcp14>REQUIRED</bcp14> for registration of WHIP Protocol Extensions extension
          URNs that modify WHIP Protocol Extensions extensions previously documented in
          an existing RFC.</t>

          <t>The registration procedure begins when a completed registration template, defined in the sections below, <xref target="whip-protocol-extension-registration-template"/>, is sent to iana@iana.org. &lt;iana@iana.org&gt;.
   Decisions made by the designated expert DE can be appealed to an Applications and Real Time Real-Time (ART) Area Director, then to the IESG.
   The normal appeals procedure described in RFC 2026 <xref target="BCP9"/> is to be followed.</t>
          <t>Once the registration procedure concludes successfully, IANA creates
   or modifies the corresponding record in the WHIP "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry.</t>
          <t>An RFC specifying one or more new WHIP Protocol Extension extension URNs <bcp14>MUST</bcp14> include the
   completed registration templates, template(s), which <bcp14>MAY</bcp14> be expanded with
   additional information. These completed templates template(s) are intended to go
   in the body of the document, not in the IANA Considerations section.
   The RFC <bcp14>MUST</bcp14> include the syntax and semantics of any extension-specific attributes that may be provided in a Link header
   field advertising the extension.</t>
        </section>
        <section anchor="guidance-for-designated-experts">
          <name>Guidance for the Designated Experts</name> Expert</name>
          <t>The Designated Expert (DE) DE is expected to ascertain do the following:</t>
<ul>
	  <li>Ascertain the existence of suitable documentation (a
	  specification) as described in <xref target="RFC8126"/> and to verify
	  that the document is permanently and publicly available.</t>
          <t>The DE is also expected to check
	  available. Specifications should be documented in an
	  Internet-Draft.</li>
          <li>Check the clarity of purpose and use of the requested registration.</t>
          <t>Additionally, the DE must verify
          registration.</li> <li>Verify that any request for one of these
          registrations has been made available for review and comment comments by
          posting the request to the WebRTC Ingest Signaling over HTTPS (wish) Working Group &lt;wish@ietf.org&gt; mailing list.</t>
          <t>Specifications should be documented in an Internet-Draft. Lastly, the DE must ensure list.</li>
          <li>Ensure that any other request for a code point does not conflict with work that is active in or already published by the IETF.</t> IETF.</li>
</ul>

        </section>
        <section anchor="whip-protocol-extension-registration-template">
          <name>WHIP Protocol Extension Registration
          <name>Registration Template</name>
          <t>A WHIP Protocol Extension URNs extension URN is defined by completing the following template:</t>
          <ul
          <dl spacing="normal">
            <li>
              <t>URN: A
              <dt>URN:</dt><dd>A unique URN for the WHIP Protocol Extension extension (e.g., "urn:ietf:params:whip:ext:example:server-sent-events").</t>
            </li>
            <li>
              <t>Reference: A formal reference to the publicly available specification</t>
            </li>
            <li>
              <t>Name: A "urn:ietf:params:whip:ext:example:server-sent-events")</dd>
              <dt>Description:</dt><dd>A descriptive name of the WHIP Protocol Extension extension (e.g., "Sender Side events").</t>
            </li>
            <li>
              <t>Description: A brief description of the function of the extension, in a short paragraph or two</t>
            </li>
            <li>
              <t>Contact information: Contact information for the organization or person making events")</dd>
              <dt>Reference:</dt><dd>A formal reference to the registration</t>
            </li>
          </ul> publicly available specification</dd>
              <dt>IANA Registry Reference:</dt><dd>TBD</dd>
              <dt>Change Controller:</dt><dd>TBD</dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors wish to thank Lorenzo Miniero, Juliusz Chroboczek, Adam Roach, Nils Ohlmeier, Christer Holmberg, Cameron Elliott, Gustavo Garcia, Jonas Birme, Sandro Gauci, Christer Holmberg and everyone else in the WebRTC community that have provided comments, feedback, text and improvement proposals on the document and contributed early implementations of the spec.</t>
    </section>
  </middle>
  <back>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

        <reference anchor="FETCH" target="https://fetch.spec.whatwg.org">
          <front>
            <title>Fetch - Living Standard</title>
            <title>Fetch</title>
            <author>
              <organization>WHATWG</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC9429">
          <front>
            <title>JavaScript Session Establishment Protocol (JSEP)</title>
            <author fullname="J. Uberti" initials="J." surname="Uberti"/>
            <author fullname="C. Jennings" initials="C." surname="Jennings"/>
            <author fullname="E. Rescorla" initials="E." role="editor" surname="Rescorla"/>
            <date month="April" year="2024"/>
            <abstract>
              <t>This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.</t>
              <t>This specification obsoletes RFC 8829.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9429"/>
          <seriesInfo name="DOI" value="10.17487/RFC9429"/>
        </reference>
        <reference anchor="RFC3264">
          <front>
            <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <date month="June" year="2002"/>
            <abstract>
              <t>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="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>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="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>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="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="RFC7675">
          <front>
            <title>Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness</title>
            <author fullname="M. Perumal" initials="M." surname="Perumal"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <author fullname="R. Ravindranath" initials="R." surname="Ravindranath"/>
            <author fullname="T. Reddy" initials="T." surname="Reddy"/>
            <author fullname="M. Thomson" initials="M." surname="Thomson"/>
            <date month="October" year="2015"/>
            <abstract>
              <t>To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.</t>
              <t>This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7675"/>
          <seriesInfo name="DOI" value="10.17487/RFC7675"/>
        </reference>
          <refcontent>WHATWG Living Standard</refcontent>
          <annotation>Commit snapshot: <eref
          target="https://fetch.spec.whatwg.org/commit-snapshots/edfa8d100cf1ecfde385f65c172e0e8d018fcd98/"
          brackets="angle"/>.</annotation>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9429.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7675.xml"/>

        <reference anchor="W3C.REC-ldp-20150226" target="https://www.w3.org/TR/2015/REC-ldp-20150226/">
          <front>
            <title>Linked Data Platform 1.0</title>
            <author fullname="Ashok Malhotra" role="editor"/>
            <author fullname="John Arwe" role="editor"/>
            <author fullname="Steve Speicher" role="editor"/>
            <author fullname="Ashok Malhotra" role="editor"/>
            <date day="26" month="February" year="2015"/>
          </front>
          <seriesInfo name="W3C REC" value="REC-ldp-20150226"/>
          <seriesInfo name="W3C" value="REC-ldp-20150226"/>
        </reference>
        <reference anchor="RFC8845">
          <front>
            <title>Framework for Telepresence Multi-Streams</title>
            <author fullname="M. Duckworth" initials="M." role="editor" surname="Duckworth"/>
            <author fullname="A. Pepperell" initials="A." surname="Pepperell"/>
            <author fullname="S. Wenger" initials="S." surname="Wenger"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting, and rendering the media streams. This protocol is used in addition to SIP signaling and Session Description Protocol (SDP) negotiation for setting up a telepresence session.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8845"/>
          <seriesInfo name="DOI" value="10.17487/RFC8845"/>
        </reference>
        <reference anchor="RFC8838">
          <front>
            <title>Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol</title>
            <author fullname="E. Ivov" initials="E." surname="Ivov"/>
            <author fullname="J. Uberti" initials="J." surname="Uberti"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8838"/>
          <seriesInfo name="DOI" value="10.17487/RFC8838"/>
        </reference>
        <reference anchor="RFC5789">
          <front>
            <title>PATCH Method for HTTP</title>
            <author fullname="L. Dusseault" initials="L." surname="Dusseault"/>
            <author fullname="J. Snell" initials="J." surname="Snell"/>
            <date month="March" year="2010"/>
            <abstract>
              <t>Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5789"/>
          <seriesInfo name="DOI" value="10.17487/RFC5789"/>
        </reference>
        <reference anchor="RFC8840">
          <front>
            <title>A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)</title>
            <author fullname="E. Ivov" initials="E." surname="Ivov"/>
            <author fullname="T. Stach" initials="T." surname="Stach"/>
            <author fullname="E. Marocco" initials="E." surname="Marocco"/>
            <author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.</t>
              <t>This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The document also defines a new SIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session Description Protocol (SDP) "end-of-candidates" attribute and a new SIP option tag "trickle-ice" are defined.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8840"/>
          <seriesInfo name="DOI" value="10.17487/RFC8840"/>
        </reference>
        <reference anchor="RFC6585">
          <front>
            <title>Additional HTTP Status Codes</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <date month="April" year="2012"/>
            <abstract>
              <t>This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6585"/>
          <seriesInfo name="DOI" value="10.17487/RFC6585"/>
        </reference>
        <reference anchor="RFC8839">
          <front>
            <title>Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)</title>
            <author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Huguenin"/>
            <author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/>
            <author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
            <author fullname="A. Keränen" initials="A." surname="Keränen"/>
            <author fullname="R. Shpount" initials="R." surname="Shpount"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents.</t>
              <t>This document obsoletes RFCs 5245 and 6336.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8839"/>
          <seriesInfo name="DOI" value="10.17487/RFC8839"/>
        </reference>
        <reference anchor="RFC9143">
          <front>
            <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
            <author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
            <author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/>
            <author fullname="C. Jennings" initials="C." surname="Jennings"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group.</t>
              <t>This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension.</t>
              <t>This specification updates RFCs 3264, 5888, and 7941.</t>
              <t>This specification obsoletes RFC 8843.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9143"/>
          <seriesInfo name="DOI" value="10.17487/RFC9143"/>
        </reference>
        <reference anchor="RFC8858">
          <front>
            <title>Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)</title>
            <author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>This document defines a new Session Description Protocol (SDP) media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC 5761 by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8858"/>
          <seriesInfo name="DOI" value="10.17487/RFC8858"/>
        </reference>
        <reference anchor="RFC8830">
          <front>
            <title>WebRTC MediaStream Identification in the Session Description Protocol</title>
            <author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>This document specifies a Session Description Protocol (SDP) grouping mechanism for RTP media streams that can be used to specify relations between media streams.</t>
              <t>This mechanism is used to signal the association between the SDP concept of "media description" and the Web Real-Time Communication (WebRTC) concept of MediaStream/MediaStreamTrack using SDP signaling.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8830"/>
          <seriesInfo name="DOI" value="10.17487/RFC8830"/>
        </reference>
        <reference anchor="RFC8842">
          <front>
            <title>Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS)</title>
            <author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
            <author fullname="R. Shpount" initials="R." surname="Shpount"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>This document defines the Session Description Protocol (SDP) offer/answer procedures for negotiating and establishing a Datagram Transport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification.</t>
              <t>This document defines a new SDP media-level attribute, "tls-id".</t>
              <t>This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8842"/>
          <seriesInfo name="DOI" value="10.17487/RFC8842"/>
        </reference>
        <reference anchor="RFC8288">
          <front>
            <title>Web Linking</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="October" year="2017"/>
            <abstract>
              <t>This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").</t>
              <t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8288"/>
          <seriesInfo name="DOI" value="10.17487/RFC8288"/>
        </reference>
        <reference anchor="RFC7064">
          <front>
            <title>URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol</title>
            <author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/>
            <author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
            <author fullname="P. Jones" initials="P." surname="Jones"/>
            <author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Huguenin"/>
            <date month="November" year="2013"/>
            <abstract>
              <t>This document specifies the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7064"/>
          <seriesInfo name="DOI" value="10.17487/RFC7064"/>
        </reference>
        <reference anchor="RFC7065">
          <front>
            <title>Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers</title>
            <author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Huguenin"/>
            <author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/>
            <author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
            <author fullname="P. Jones" initials="P." surname="Jones"/>
            <date month="November" year="2013"/>
            <abstract>
              <t>This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7065"/>
          <seriesInfo name="DOI" value="10.17487/RFC7065"/>
        </reference>
        <reference anchor="RFC8489">
          <front>
            <title>Session Traversal Utilities for NAT (STUN)</title>
            <author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Huguenin"/>
            <author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <author fullname="R. Mahy" initials="R." surname="Mahy"/>
            <author fullname="P. Matthews" initials="P." surname="Matthews"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with 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>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.</t>
              <t>This document obsoletes RFC 5389.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8489"/>
          <seriesInfo name="DOI" value="10.17487/RFC8489"/>
        </reference>
        <reference anchor="RFC6750">
          <front>
            <title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</title>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <author fullname="D. Hardt" initials="D." surname="Hardt"/>
            <date month="October" year="2012"/>
            <abstract>
              <t>This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6750"/>
          <seriesInfo name="DOI" value="10.17487/RFC6750"/>
        </reference>
        <reference anchor="RFC8725">
          <front>
            <title>JSON Web Token Best Current Practices</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="D. Hardt" initials="D." surname="Hardt"/>
            <author fullname="M. Jones" initials="M." surname="Jones"/>
            <date month="February" year="2020"/>
            <abstract>
              <t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="225"/>
          <seriesInfo name="RFC" value="8725"/>
          <seriesInfo name="DOI" value="10.17487/RFC8725"/>
        </reference>
        <reference anchor="RFC8853">
          <front>
            <title>Using Simulcast in Session Description Protocol (SDP) and RTP Sessions</title>
            <author fullname="B. Burman" initials="B." surname="Burman"/>
            <author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
            <author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/>
            <author fullname="M. Zanaty" initials="M." surname="Zanaty"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in the Session Description Protocol (SDP). The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source and makes an extension to SDP to indicate that those RTP streams are different simulcast formats of that media source. The SDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8853"/>
          <seriesInfo name="DOI" value="10.17487/RFC8853"/>
        </reference>
        <reference anchor="RFC8826">
          <front>
            <title>Security Considerations for WebRTC</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8826"/>
          <seriesInfo name="DOI" value="10.17487/RFC8826"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>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>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="RFC9147">
          <front>
            <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
            <date month="April" year="2022"/>
            <abstract>
              <t>This document specifies
          <refcontent>W3C Recommendation</refcontent>
          <annotation>Latest version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
              <t>This document obsoletes RFC 6347.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9147"/>
          <seriesInfo name="DOI" value="10.17487/RFC9147"/>
        </reference>
        <reference anchor="RFC9112">
          <front>
            <title>HTTP/1.1</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.</t>
              <t>This document obsoletes portions of RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC4086">
          <front>
            <title>Randomness Requirements for Security</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="J. Schiller" initials="J." surname="Schiller"/>
            <author fullname="S. Crocker" initials="S." surname="Crocker"/>
            <date month="June" year="2005"/>
            <abstract>
              <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
              <t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. 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="106"/>
          <seriesInfo name="RFC" value="4086"/>
          <seriesInfo name="DOI" value="10.17487/RFC4086"/>
        </reference>
        <reference anchor="RFC9562">
          <front>
            <title>Universally Unique IDentifiers (UUIDs)</title>
            <author fullname="K. Davis" initials="K." surname="Davis"/>
            <author fullname="B. Peabody" initials="B." surname="Peabody"/>
            <author fullname="P. Leach" initials="P." surname="Leach"/>
            <date month="May" year="2024"/>
            <abstract>
              <t>This specification defines UUIDs (Universally Unique IDentifiers) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</t>
              <t>This specification is derived from the OSF DCE specification with the
kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9562"/>
          <seriesInfo name="DOI" value="10.17487/RFC9562"/>
        </reference>
        <reference anchor="RFC3553">
          <front>
            <title>An IETF URN Sub-namespace for Registered Protocol Parameters</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <author fullname="T. Hardie" initials="T." surname="Hardie"/>
            <author fullname="G. Klyne" initials="G." surname="Klyne"/>
            <date month="June" year="2003"/>
            <abstract>
              <t>This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. 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="73"/>
          <seriesInfo name="RFC" value="3553"/>
          <seriesInfo name="DOI" value="10.17487/RFC3553"/>
        </reference> available at: <eref target="https://www.w3.org/TR/ldp/" brackets="angle"/>.</annotation>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8838.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5789.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8840.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6585.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8839.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9143.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8858.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8830.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8842.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8288.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7064.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7065.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8489.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6750.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8725.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8853.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8826.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9562.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3553.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC3261">
          <front>
            <title>SIP: Session Initiation Protocol</title>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <author fullname="G. Camarillo" initials="G." surname="Camarillo"/>
            <author fullname="A. Johnston" initials="A." surname="Johnston"/>
            <author fullname="J. Peterson" initials="J." surname="Peterson"/>
            <author fullname="R. Sparks" initials="R." surname="Sparks"/>
            <author fullname="M. Handley" initials="M." surname="Handley"/>
            <author fullname="E. Schooler" initials="E." surname="Schooler"/>
            <date month="June" year="2002"/>
            <abstract>
              <t>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="RFC6120">
          <front>
            <title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <date month="March" year="2011"/>
            <abstract>
              <t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6120"/>
          <seriesInfo name="DOI" value="10.17487/RFC6120"/>
        </reference>
        <reference anchor="RFC7826">
          <front>
            <title>Real-Time Streaming Protocol Version 2.0</title>
            <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"/>
            <author fullname="A. Rao" initials="A." surname="Rao"/>
            <author fullname="R. Lanphier" initials="R." surname="Lanphier"/>
            <author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
            <author fullname="M. Stiemerling" initials="M." role="editor" surname="Stiemerling"/>
            <date month="December" year="2016"/>
            <abstract>
              <t>This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.</t>
              <t>RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7826"/>
          <seriesInfo name="DOI" value="10.17487/RFC7826"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7826.xml"/>
        <referencegroup anchor="BCP56" target="https://www.rfc-editor.org/info/bcp56">
          <reference anchor="RFC9205" target="https://www.rfc-editor.org/info/rfc9205">
            <front>
              <title>Building Protocols with HTTP</title>
              <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
              <date month="June" year="2022"/>
              <abstract>
                <t>Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations.</t>
                <t>This document obsoletes RFC 3205.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="56"/>
            <seriesInfo name="RFC" value="9205"/>
            <seriesInfo name="DOI" value="10.17487/RFC9205"/>
          </reference>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9205.xml"/>
        </referencegroup>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9457.xml"/>

        <reference anchor="RFC9457"> anchor="HTML" target="https://html.spec.whatwg.org/">
          <front>
            <title>Problem Details for HTTP APIs</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="E. Wilde" initials="E." surname="Wilde"/>
            <author fullname="S. Dalal" initials="S." surname="Dalal"/>
            <date month="July" year="2023"/>
            <abstract>
              <t>This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.</t>
              <t>This document obsoletes RFC 7807.</t>
            </abstract>
            <title>HTML</title>
            <author>
              <organization>WHATWG</organization>
            </author>
          </front>
          <seriesInfo name="RFC" value="9457"/>
          <seriesInfo name="DOI" value="10.17487/RFC9457"/>
          <refcontent>WHATWG Living Standard</refcontent>
          <annotation>Commit snapshot: <eref target="https://html.spec.whatwg.org/commit-snapshots/09db56ba9343c597340b2c7715f43ff9b10826f6/" brackets="angle"/>.</annotation>
        </reference>

        <reference anchor="W3C.REC-webrtc-20210126" target="https://www.w3.org/TR/2021/REC-webrtc-20210126/"> target="https://www.w3.org/TR/2024/REC-webrtc-20241008/">
          <front>
            <title>WebRTC 1.0: Real-Time Communication Between Browsers</title>
            <author fullname="Cullen Jennings" role="editor"/>
            <author fullname="Florent Castelli" role="editor"/>
            <author fullname="Henrik Boström" role="editor"/>
            <author fullname="Jan-Ivar Bruaroey" role="editor"/>
            <date day="26" month="January" year="2021"/>
          </front>
          <seriesInfo name="W3C REC" value="REC-webrtc-20210126"/>
          <seriesInfo name="W3C" value="REC-webrtc-20210126"/>
        </reference>
        <reference anchor="RFC8836">
          <front>
            <title>Congestion Control Requirements for Interactive Real-Time Media</title>
            <author fullname="R. Jesup" initials="R." surname="Jesup"/>
            <author fullname="Z. Sarker" initials="Z." role="editor" surname="Sarker"/>
            <date month="January" year="2021"/>
            <abstract>
              <t>Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.</t>
              <t>This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8836"/>
          <seriesInfo name="DOI" value="10.17487/RFC8836"/>
        </reference>
        <reference anchor="RFC8141">
          <front>
            <title>Uniform Resource Names (URNs)</title>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <author fullname="J. Klensin" initials="J." surname="Klensin"/>
            <date month="April" year="2017"/>
            <abstract>
              <t>A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8141"/>
          <seriesInfo name="DOI" value="10.17487/RFC8141"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t>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>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>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract> day="8" month="October" year="2024"/>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
          <refcontent>W3C Recommendation</refcontent>
          <annotation>Latest version available at: <eref target="https://www.w3.org/TR/webrtc/" brackets="angle"/>.</annotation>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8836.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

        <referencegroup anchor="BCP9" target="https://www.rfc-editor.org/info/bcp9">
          <reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026">
            <front>
              <title>The Internet Standards Process -- Revision 3</title>
              <author fullname="S. Bradner" initials="S." surname="Bradner"/>
              <date month="October" year="1996"/>
              <abstract>
                <t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. 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="9"/>
            <seriesInfo name="RFC" value="2026"/>
            <seriesInfo name="DOI" value="10.17487/RFC2026"/>
          </reference>
          <reference anchor="RFC5657" target="https://www.rfc-editor.org/info/rfc5657">
            <front>
              <title>Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard</title>
              <author fullname="L. Dusseault" initials="L." surname="Dusseault"/>
              <author fullname="R. Sparks" initials="R." surname="Sparks"/>
              <date month="September" year="2009"/>
              <abstract>
                <t>Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml"/>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5657.xml"/>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6410.xml"/>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7100.xml"/>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7127.xml"/>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7475.xml"/>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8789.xml"/>
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9282.xml"/>
        </referencegroup>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The authors wish to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion thank <contact fullname="Lorenzo Miniero"/>,
      <contact fullname="Juliusz Chroboczek"/>, <contact fullname="Adam
      Roach"/>, <contact fullname="Nils Ohlmeier"/>, <contact
      fullname="Christer Holmberg"/>, <contact fullname="Cameron Elliott"/>,
      <contact fullname="Gustavo Garcia"/>, <contact fullname="Jonas Birme"/>,
      <contact fullname="Sandro Gauci"/>, <contact fullname="Christer
      Holmberg"/>, and suggestions for improvements.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="9"/>
            <seriesInfo name="RFC" value="5657"/>
            <seriesInfo name="DOI" value="10.17487/RFC5657"/>
          </reference>
          <reference anchor="RFC6410" target="https://www.rfc-editor.org/info/rfc6410">
            <front>
              <title>Reducing the Standards Track to Two Maturity Levels</title>
              <author fullname="R. Housley" initials="R." surname="Housley"/>
              <author fullname="D. Crocker" initials="D." surname="Crocker"/>
              <author fullname="E. Burger" initials="E." surname="Burger"/>
              <date month="October" year="2011"/>
              <abstract>
                <t>This document updates the Internet Engineering Task Force (IETF) Standards Process defined everyone else in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="9"/>
            <seriesInfo name="RFC" value="6410"/>
            <seriesInfo name="DOI" value="10.17487/RFC6410"/>
          </reference>
          <reference anchor="RFC7100" target="https://www.rfc-editor.org/info/rfc7100">
            <front>
              <title>Retirement of the "Internet Official Protocol Standards" Summary Document</title>
              <author fullname="P. Resnick" initials="P." surname="Resnick"/>
              <date month="December" year="2013"/>
              <abstract>
                <t>This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="9"/>
            <seriesInfo name="RFC" value="7100"/>
            <seriesInfo name="DOI" value="10.17487/RFC7100"/>
          </reference>
          <reference anchor="RFC7127" target="https://www.rfc-editor.org/info/rfc7127">
            <front>
              <title>Characterization of Proposed Standards</title>
              <author fullname="O. Kolkman" initials="O." surname="Kolkman"/>
              <author fullname="S. Bradner" initials="S." surname="Bradner"/>
              <author fullname="S. Turner" initials="S." surname="Turner"/>
              <date month="January" year="2014"/>
              <abstract>
                <t>RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current WebRTC community that have provided
      comments, feedback, text, and more accurate characterization of Proposed Standards.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="9"/>
            <seriesInfo name="RFC" value="7127"/>
            <seriesInfo name="DOI" value="10.17487/RFC7127"/>
          </reference>
          <reference anchor="RFC7475" target="https://www.rfc-editor.org/info/rfc7475">
            <front>
              <title>Increasing the Number of Area Directors in an IETF Area</title>
              <author fullname="S. Dawkins" initials="S." surname="Dawkins"/>
              <date month="March" year="2015"/>
              <abstract>
                <t>This document removes a limit improvement proposals on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="9"/>
            <seriesInfo name="RFC" value="7475"/>
            <seriesInfo name="DOI" value="10.17487/RFC7475"/>
          </reference>
          <reference anchor="RFC8789" target="https://www.rfc-editor.org/info/rfc8789">
            <front>
              <title>IETF Stream Documents Require IETF Rough Consensus</title>
              <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/>
              <author fullname="E. Rescorla" initials="E." role="editor" surname="Rescorla"/>
              <date month="June" year="2020"/>
              <abstract>
                <t>This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="9"/>
            <seriesInfo name="RFC" value="8789"/>
            <seriesInfo name="DOI" value="10.17487/RFC8789"/>
          </reference>
          <reference anchor="RFC9282" target="https://www.rfc-editor.org/info/rfc9282">
            <front>
              <title>Responsibility Change for the RFC Series</title>
              <author fullname="B. Rosen" initials="B." surname="Rosen"/>
              <date month="June" year="2022"/>
              <abstract>
                <t>In RFC 9280, responsibility for the RFC Series moved to the RFC Series Working Group and the RFC Series Approval Board. It is no longer the responsibility of the RFC Editor, and the role of the IAB in the RFC Series is altered. Accordingly, in Section 2.1 of RFC 2026, the sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction
      contributed early implementations of the IAB" is deleted.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="9"/>
            <seriesInfo name="RFC" value="9282"/>
            <seriesInfo name="DOI" value="10.17487/RFC9282"/>
          </reference>
        </referencegroup>
      </references>
    </references> spec.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1923LbSJLoO7+iDv0w0jZJkRR144ynl5bkbs36opHk6Z7Y
2DgBAiCJMQlwAVAy2+39lvMt58tO3uoGgJLc3Tuzu3E8EdM2CFRlZWXlPbO6
3W4rysI0WMVjFeXBrOwmcTnrPiTFovuwSNbdwXGrTMol/PxDPL25O+9+f3d3
rZJ0HhdlkqVqnWdlFmZLtffD91fX+61gOs3j+7HCj1thUMbzLN+OVVFGrWSd
j1WZb4py2O+f9YetII+DsZrc3LUesvzjPM82a/gQpm5t1hF8WozV6elo2MH/
77daH+MtvBdpSFqtogzS6H8HyywF8LZx0VonY/WvAE5HFVle5vGsgL9tV/iX
f2u1gk25yPJxS3VbCv4kKYx/21NvN3myXGb0jBFxG+fzJFPfBXmYBN7vWT4P
0uSnAJc+Vm/heRIGRUm/xasgWcJK6ePenD7urfjjfw6zYpUV2ax8gEX3kswD
YtJT32Ub+HoZ5JEDx2QZf4IV5nH1Zx+M8+z2baZuZXAXlgAG6M3Nt3UoWmmW
r2CY+xjQol5f3p1/P6YBDK6UzAdY/35y98N39EQo4nVchgvVVW+SeyAIdYvb
oUEsg3wel2O1KMt1MT44mOG7vWIdh72HRVA+zHswqAzf6na7KpgWZR6EZat1
t0gKBVS5WcVpqaK4CPNkGhcqUEWyWi9jhSTYnQZFHFnyK2FQoJ3lEha9zB40
tfJbllyzmQqztMSBk7TMgC6BBlcIPezbfRLiNGl0kOXq/OJd0asCI3Spbl6f
E2niy/offXgbF7JKomgZt1ov1FVa5lm0CXFmHClWV5d3rxXA9cPlK4U0jxMT
3atCkJf8BPD+6fbyWu19/vy/YOiz0fDsy5f9Dix/FYcL2PdipTa4KgAf15LT
6mNYQLlZd9QqSIN5jNB2CLoyhlGzB1o6DLFZlskqjoCui7goALCeuioBZ0Xm
YHoBCITRUzi8ZQILVvzFDBBbwNwINc74fjaL84NJWjzEuXqbRfESdqBc0G+3
PLq6oEHXhPxrwytuL673Fa/vcHg8+vIFdiNcbiI98ozIssD/KsA4AgvYz+5h
Hvz5IYEzsRf35r2OgFZu1zEc9hCACNU6yOH8lHFeMAriNMy3BMJ+TwgDdx+G
hEdALlvYYFh1mpUKCTSZbYnW5vAbAZQHabEGhmKpDWgtWK/x8NPClvF9vITt
/5ACwOUmBZQttx0CdRmEHxn13g7b0e2mJqkGbhEUahrHKUCvMjgXQQhUDxsS
RBljMkAybeLCiH8YB2ee5lkQIXc6sESepBGw3xxge1jEgMNADgBAwodJqFWt
k3WMDxVQfxl8BFBwK+aAiTIGDrxebnAwFQbTJWAuDPJ8i+PnwYPekAxWkUfI
aBD/sC+4GwAXjL0pmEb4eWS/CNJt/UQqPIxyZi8AKCCCrXoXl3h+1B4c031B
hFBmI2Jgc35YJIBFwXAIb01jogJYFKyJKVfvkbM/eoRCLZOPQNdX10C43zLh
DoBwAbof317rh8eDYf/LF1ooEBGsHYkKDhYMxycWJt0wS7IbBNMc1BmRHF/a
J9gFOqJpRpARQWlaoO0OSrO3PWAwtxqek9PhMcID4hhYNQzDDBE+u7m77jh0
v1kThdPRvbiGCfBoB3y0V3S0veOK1KDZgz60QMfIwOM8gSWFBQKJj31uU+Wo
gN51Vrjc3dCyAZVUDpxRoMQJZR/hIPD4dsvh5C+yiFc8BpasrgoVB8UWsU8z
EG/k54H9CXYF/7nO1huQlepKSxizS5YS+NvZBjlHmMGQCRwLJiANFooFZvPI
UfCLy5TPiiOLgAQy+CZcBoCbMFjKUtbLoEQGSKJIjxinUbfMuvAf+ztQSLhI
4nu9AcCe8RgAPosE5gLeA4cm3PZg9jfwU17QW3n87xvgn4iFwsBQO6s0t0uh
VkCi2BRyYeB6jJBNgSvk8YAoH+IpDvBQ6NHgGZ8vVNjMRD2UlHdxDrSfLbP5
lgUl6HooIKNCtd9+uL1rd/i/6t17+vvN5Z8/XN1cXuDfb7+fvHlj/tKSN26/
f//hzYX9m/3y/P3bt5fvLvhjeKq8R63228lf23z22u+v767ev5u8afMhc+kW
ccXHGXlIvs5jZCJB0dJSlNb76vz6//6fwUjOznAwAFEu/zgdnOBBAj6c8mxZ
CuTE/0Tu0QIBA6IbRwERBQxrnZTAAzpIpMUCBTpyBsDeP/0rYubfxuoP03A9
GP1RHuCCvYcaZ95Dwln9Se1jRmLDo4ZpDDa95xVM+/BO/ur9W+PdefiHb0kc
dQen3/6xhSTz/h7pMX5genGNkyuWBte+ZYLMz2XEsyBMloDSEqUgEGQX9SIV
f0JpPI+ReT1DhSE2ydTNvFKrRwTI9XvYBjxuAE7RU8T4zATI0oGHwHFAeoLD
X5TxGncbXoZzBFaQCLMrpC/gqyD4UA6mMf41KbfqUr9IBLl3dX65T5BcgMIE
Qm2l7ozi8ibYAh+/jUMwR+DLvYu7N7f7micDEZcPqG0gd0BcAUdKSH9kqZHH
QN0FsQsrtXMUfMKvSG2IcyOwDMvP7/Gpp4ywFqJZILCzdQYHCHWnNfy72ITA
YQpgrRYNtDqRJbDGA4Rdg95RmzSJgJuFrMrJzKQyktq2SniJwKZhHOReszxb
VVeK9FCFm/Ri2CQQGYDBgF8CURmztEUhmcdGBGZpYcS9MEfmADgLKqmg4hGX
hk9BiINETWaiPRZ69vbqZRsmD/mhaCirIAICnZWi+SZpAvMt6zLa0NU9rMBS
HyyAJBRzJ81lAI0A/DJgGFnZJizxnGzlRM5QEzAMDSUjB4riGamMsMLPn0Eq
dGXRX770+EDOMjTDcM2AUqJGsM1QPyH7idSFDPCVrYG2tWVmdsWoACj0eckl
nwa0Z1BU6H9r1U/oAeT9f+AfMSx/sz8t9U3X/fMNPvQf4cNvnnjQ/aalfvYI
72ccSB7pwwD//lm9JVK8JVKkB/SKPrHqZ4LoG3cuD6JvfAC+MW+ZV342EBEE
u/78/Og/3Ue/8UCWhpHVsq25/wsGqm6B+fPHb74SomF/oM5BS8ejQTDx0dv/
aoj+sAukr4XIPscTjQL+EvC1+6udEO0C6AmUPQ3R7fX7d7eXXw/Rzztx9DjK
HoOIBMft5d2H6/o3z4Ho5bP+/PErdg1ssANQW67V6zfvf/hqiHbT0VfvGh22
i8s3l3cNe/Xon19ER48BKRAN+331/l++Epg6RM8lo6Y/n9yBfsM/IqI+j9mP
+rLtsXZy43meu7Z6Qa54LRW7Rmh+YVkbL8WaI2m8690vpKBY8yQoREgXZCU7
UmnMqmpF7xNDlHUkRwm06h+ri6DTigqDXiot6BrF+3TLA2nZHrF7h91i2icE
cKyysqKcaYC1zBSQoxg1tEJUJdEMcnYbguYFemIMExSeKkXjiG5TG1d9uHkz
Vjcxqfmip8EjbznmXcAWKLFse6PmEqKw0Ma5u8k4zVtnOQJ90oBoAR9Hg6HB
9sxr03gGQ83jYl2yrt6B2GZs+B8Z53ip97UwONE6lgCbRqjACjIFTFBBo6Ue
ER3xIUlLYi8AdrbJwxh3vY47XAh6O9N5Zk0EF1/eIXnGrpjpLBi7Jxa/bxJW
vFXqroI31JCLmJAnyrBM74GnXeSAJgSrFIV/K6gS0wWMnQWeEZSU5pgWuNVG
x0UQ+Iw/dq7rmvVqBXaROKfRa29MvMA38DxUdCp2G3mfXKrljafxsk2J9jjP
B0Ch1YboB+5FFO+wMLIB0F/hOWarqKqwhg68ep8tiTodI6tDyMIt0w7gSRTl
ODfZukte8d67yd0+2n+wjCKAsUjyIzxkAcdAOcGS7X1rIjuWPYjlffY3isHc
EYeeSOuZMX1NaKDOQq/YbGncEiBEJCIxYaymS0cVnhiF16MuayzXmN8NsYSo
kBFU29FV2wBrUQTzmA53kKQyrdVgez7stNiVx56Mq4EcErAF5GdwDHEO1QDe
LdrpnYIR7i0fp7OaD1DT+PENIdw3vHAuwS/zIsenyIup4YVTX9kt7RF4rh+g
I2sw7APJA+l0lizjXnXXb2PcBb2polHhqHKi40ZZ4LPXhs1EXagtAb9Zkq9c
RuJxC3KNGYS810wCnr5gkDZECZ9fYFy2S/8AJeK1MdY/f/721fn10TFwlfkm
iSgGVHTcNRZKexfVKsD4b5znJJ1AswCuWG7ydAerLUTqMF8uWLgbxivDBOiH
17IlMn5X/ZrwxDo8U2D0U46SkRAivq+DdPgDUES5KQTOeR6EMTvwZ/AernyK
gTrZ/3mcghYSqhQQX8SrINXxjEDNQX9I3cHQhb5JP6bI4RxU9B5fe5htlhHu
5n0MIACS8y7ARC4VHsR1y0wxHgkUB8tY0dSk7qm/Feg2mf4tDkslMT9RDWJz
5KdZtNVicRYAxRrJRcEO4DAcJzobHZ0Y300D5OaY4+nK8mSOznw6H3V30C27
sNRh77iHc1MUezDoA015+oH1J6UUe7xPiCPqNTBLwRc3Kaiay63xqxo0okTK
irjyFKQN+eEWwIgopGgUWUanA2ydtjB1ZBfpGiQQxTGtw84Mf/wRZTn7LZd2
D+j4ppnRqdC3D69/d2mcwoq0bNJJox6d0StP70FxCqK01bqCjc4jlgf8rFGa
dmoMjSAlciZHd2odhyoIQxiTNoNXTFkH+WYpmKcJWEWWDwp/f496w97AbDCl
KfBWxjnSri/aalSnRznrHfYOK2QiABGzmxPvrSnlQqr1CWjFvPUG85gdgFO0
naD9QRGt2wSviEU/9omAkuMaDpCjBhoQGhErvtivwKz+oobaw0bUGprzBbxP
cs9Yd8cs1gKgV8vKTqDeZKKtLOIASW+WxMCyaPXO0tL4AaOg4hbz1cUr5jt2
j5q0GUp2qIAMujJsAf0TOEbDtgljwAXAEVoFSyS4OOo0DC9nlbhk2UgxWuuC
WfJsTfkuIzjSzIc1alEPnxQNNiw51MX77RqerNwCEQd6X5pCFfUTK2E1/LSN
SiKOD3RalmC1b8pY1QgVnqq3k7/SFxRGwK9gmnv/qwJ0cUBQGzQFiiUx7bfx
xcoUjoSXbIWdB4CgbBjChVJ0TOWrGbCNXR2zgL8EGKNAU4aUJ/k3SVyXiVAW
ECluQVVtCyrg6VDUjoPia3/mK0dDxh+rR+D5xG8CEQT3AdpuB2YWXNDBoDdo
fZ8VJadK9mTJPdCUW5Lt0r2DszBWFeI3v76J03m5GCtgmYNW6/5lv5W97Kqj
4fD06Oyof3g6GJyeHQ76o4Eaqqt36up6pAbDk14f/jdoFS+7rfJlX/VbwUtO
vHz14d3Fm0vVVwN4FH8qV8G6S6l03VXyKY7gIYZ5OOekGMM+hx9hh+DZsLV6
GWyiJFNn6sPF9QFYBQeo3t9O/nL9GqAbtMKXMn+fZsc58zJcj89U7TnOsZnl
wXx8WUwe5MH6IRpPr7/58U9v3/bPgpvTSfLj4G/R5uNPN8d/hVdmeODydY6W
ULEIusOjY3UxGZ+8Gh+djC/Ox8PT8fnluD8aj16PDwfjk7Px6dH4fIR/Pz4Z
X74aD0/GR6fj4dn48mJ8cjIeTsb9i/FwNJ5c4pPJxfiwP351Pn51MX49GJ+d
jzF19SX56cZwltZBUcC/V0k07hvUjUcKGPUYk2nHlI5WjHNQuBdwMD8BlKAg
juEDGoaPOI5QwBDR6Hg2PRsOu9HRMOiO4rOwGwSnJ93RaAQ0GA6OhoOpCuPD
4XEczrpB/3TQHR0dBt3T2dms2z/uH0VH8Ww0GJ4KkrurzSfnr12ZC4BBKGF3
VLbeFAej036/f4Drmq1Kfg42xRotrpeD/u/hnCfpFM7ULA5fDmDDQVeLMyCW
+oafHauzE8EHktJ0g9q4nvcrsSOvD/pPvo//5hyqrvfl4Okv43UAbDnqVof4
RVtzeHZ0PB0d97uj/mzUHUX9oy6aGt3+YTANo+g0PJ5FFv+ArL9cnx6cAfL1
qejOpvg4DFcgcXP/IbDuj/UnCviDM+SJystPZkjaTngWrMuXZ8etluY9yuGL
rcs7OHCq/Wn700/b9teyn/7RYUszSpvvW2VqB8IYDwC1hlkNjo9OTs4ORwDs
4EwNfjs2tUzK+O/OsQ5Pi2g2mkXF7GjkcK5hPDiMonhwEg7Cab9/NuwPZ8fD
k1kwPeuH0zg8PDqNTo6Po/7oLDw7prPTxNFeE6t6fTg+vBxPzscXw/HlZDw5
GZ8PxpfnyNQuzsavDsenk/Hh0RjZX398eowsb3SMPw0vxufwFTGyU+Bir4n3
AUMcjYeXwNpg1hDOd4KR//EA9gIQo4aDw/5J/3h0CA/OTntHQDd92BYg8sHh
EFU1BeZXaZghckLQLH45M9SaxD+WdzVs/n9/Zuah9h/De6phr0ur5e1OZ4kw
VxATUVxFsK1eNOqPrdb7NKSsZrGf0bonc7lD4RNWH+NikaLL2JiiaGSdHJ8c
gf7J2W86SbfEpPgSLYc0S7vaaQTmSRFKIhZ7Z8juR7eoyS/VKUHaTWqy8Nmt
XHPcUSgswWRfBaIG0/ruMkACsl5A1tbxHwaenrnD4q+a4OKI1BZPU8wCAxXG
fSfqe7MJKO4kbcKaXekpyuHyw0oN03fqk1PhxjSmUN+9ZCqJP0t8OrBtnAzc
kF/mZARJkljdPw0YnfghNS+RyEBC6OO4qI1tRJs8rjs/tH0upMPJSiuao0TQ
7zX2uOgEqa/ZwUZz6pRazn28td4xHPY8z4qi+579bjc6snW74OjK3vn7m9v9
mh+Oynm+fGHjzTiRjQkk+faV+bT9yfUY5NloT8IwXpfda+D1bU0K4mmw1Rfq
PlhudnlZzEn74fC8d3N53l3C8QUN5Kg/xPx08X3BvmksfH7hJpW1Wvib5M2e
jo7EUHTqMTgKZDLRKeXtE9BnTG5bLy7RoWgEme0YfN5geiWjjDIt07ishCvw
80ItEvRCKrbgq/Ecia5FMWdIo5PRuDAw+rgEU5HiVUUH07MRTmBdy2WMrgLa
4dwEOBzsFT2Od5lUVWRnwWqJ3Ct0U0GRe8CSM/KRAsNapAnuJjEwZFZI73gk
bEVPPJsBa6GQpreUdVAuCgo6ir7kYv7wFAseULImP5nAlgOGDgQCOEA/nGNO
9TWFUOo6o6obwEfDrB1AQrQJ8T3JXGdXlFk+/vLvGwArzv30UISX8o3wKbph
0Esd5jBWwDmEKzDqtWHvQQy7Hm3TYIXOfokowu9RYkKxgL58wypkh0vLKJ4Z
m1T4HMSPiY41rIpOSrYpTR6mnzaq04LTgngMcKRkBUALAsTpt0wohGFppBJP
8zYLP+EET0KGOVKIEycBm/BCufouJ2aRJZEVOpYvGlJA/SjSGsNAJpZUjZij
a0qLo9IBE2Z3oCwaY6LenJ64Pjo5PbOO4qog62j2ROGPetgT1XUKodBrDg/z
WJdA2yVOFK3xI2JlEi/QbFaYEvqtTR0Uy65lfI95w6QY2HBOxS9Ka2xax1f6
RRuhdfykZs07HKaeAKz5SwnK5zlKW3AWZ/VxjYtU1Jy73bTQIZ8mhnCQPjuY
jOJHXNqj4VB9SIXd0NkQs7RdgcbEkJrymCknqJ61XQtRDI56IO4HfpBCJ2ZU
aZ2yQ5DhLgFNthSgMnOGJQcVd/k5AgwvpCUWD5JH3gS3Kt+vgi2rSxw7wnSM
bjbrcozIjb0aNTGZ7dgOH/FJLbKBbmuYFevyMlgNsu9y2y2DuQI9Ff4x27p6
lx6+hsPT3mk1zAPbHOO3utpDZUgYDwk62+8cBdMoFlx9sHN+/b4Lh44Nu5ot
UDA6PHylVjTeHe5iOZ96Bi980Jyi0fJC1LZWhlzmziJgcWhzkxKM8UGKqYtK
qkPj7oISrteTIq7IZhFRJphYVDSSmzffZAA4FoUhQV8UEPKSeYqJ+qgq+mAj
TSDRu+Qm54Dmd6E2q6qBz5GvHZYCoPFtwmodrA6InOsScPfMZ5WTQY59D/fa
tmDLknMTKiKvduAPe4Ne5byTYHSC2/rX46PTI6qwlGSN0fBUXcPB1FoEKCW8
1rbPlEB3lqUxWhWgVYfe2qPB0B/kNcXua0OgWWpwa8cRwe2pcC8cAQFi+iJe
i7QVm8p9WasMWUNNkHsOJABVJwBkhFOhD1u8YszkeYAnXejB6EUmUZHeA32K
skbxfeOZAg6FRhZPQCq8Dt6ylm1fVHt4Hu65hhp0Y0CMHtG+tO8rFWxa9NRr
kRnrTY61qfiN0Uw5PReVsKLDdM4ZbC76doT0SDLUgsxFJuxSqjY7rr4ispIW
B4tlvMVRBSmKY8q7Vtmr5A+gk0InI9p8u5rAhgFILlIlNFpYiQQuK5O7/E8n
kJktd0LMpqidDOGGiCL7XniNlL2jhYozmRbnniU/jWfIovhsuHF3AcdokA7+
BSie080AeIT4qhXNnInshYVlxjSOI8IM5gU1+1qCosjCxJaeVyVo4qV8EFvw
9WGHTNL4oXZOtCR/CBJe+XTDJJc6dOSsDezgZNkgA3VuzdOC0EtmcSkO65Id
LQwscTQ+ddpPqA13NGy0YHj0DGGpeDrHFK/5PI/nNsXYRxBzZKEjXn3D0UGH
oZc65S1jYsgedbJk5tssqDtavbFR73qaMhyp+p9NE0VmyILaCXwdbSSVBHqf
MgzAOHFNUxC6WWIdvQ+y2Ia62NWit6pDiUrqORZ5KLLybOcR19ihunP4uNhM
Rbd2Sa6mCXjeP8kFNGmQzVluo95IqwJiBVo5ZvId0P0Hw0iK97jVUl01cUUP
5/h0WKatuqYKFDnwKsg/slnihB8oE114ZcM2c5oiGTh0pFfBpy5/3QZJA0bj
lppBkP6Nru5OHXWkN2nOSFPiKyS34hy3do6tO7pUli2MkWfgjjY9XGOTgRR/
Ys9ilbPrjIzqxiY09lZyupbAl6ItCxJJhm0+elohc0qKa6wMPYjxfZJtigb+
oemvyTPCmNVqkiv7iYJWwUeKICBe7FEodLaZkaRuRS06+wNLXjXPyhdqYWJT
+PUyzZGs8gK2biPgNnVWYJxSO09fk9U97I/Uu8ya2t7Zx9HE4YLLNClEjiPZ
tboqCavGKeKtrdaeJLBrcNryoErI7+kUYIwbLO9jz0OJaha7ie3aCtCq0dwm
Lyn2faEPzBQ6OzBJN7EnqhhyU9WkUU7dtEBS9Ez2D+2IE/t+MvfnatZ9i7v+
nHB8g8unFp4/OjluNQXPn4qA2xjuzpSc6+Hmr3nW/3D+/s+jnz797V9+DH44
f7VJBn4o+fD05PjwZHAyUgO1idZqOBgOh8f94fBQDc6GvT4lkR4PTo5HJqBs
WD1sWV/R3Arn1i7aLuDRn+VwdDI4Hh6eHh06swzORsenJ27kekgTHX3VRENv
otHJ4eFweDocwjxluFaDo8Hp8LQ/Gp04qzmzE8A75LmT/g1fvbDh4Gh0cnLY
Pz1yJxyMwCb1F/ar5sQ1YoOZbNa1PMLLFXEP/mOB3MBjhq7irU96W7mWqBO6
/fy56fkXanZSzQqsGqwmSid9rapaV8FlGU0Kom524DFIL/3e1spxmyIrUHak
E9peRy8krGUCExzX0grkFzIePLVCAi1n3LSJzVfXm5+F4Yb6mhFX3x03x1rC
PAEZnWP65veggXNNV8Eg1jirF5RAFKNrwe0TQbm2FiudSgomaQs0IOulCB3b
uLtXAUxfp6XWLMhK7RmPz0E7vcTHnOx+ykA1juBhvC5prQADhXyziq0epdUF
AMOE0qKnUKWKMpFalK1jGldUXeqMtlsaN4b5tWzFHzUdt4U9S36v4d5tNyfX
KHlZLRSh0cSSHDSFGGEvjGqP+RTw1S5XRBW7Vi/utW6TVYK9tR6oXVnlRdc9
9aXjO2YkA/5/knI8qfEndtT6m4DuDoco3CNEBKAhwGCQ1hzavmNb1GD6R5eN
sfY/tZ/n88QYhxfgKkqpaETVEqadG1LUChTX20hYwui3jl26mz6dBHSaQMp4
uMqMYyGCSmAeFAVDfLxz2NattroXht+l2yZ1WU7Y02emmhSvDTlP7WNcNp9c
nXmPI5MDwfgLOuJ8cvVrTtHQcban43vV+KY+pAgAUG6OfWR9Yxhz9LCxmnia
nRO9w9Pmx6gmyyLraC9RJaFEKqmteNxJrg1ugjDL6/47vRTH/6HNCDOrR+zE
uMHGNOfiGQv0mz7VJbJj6OMJsWeExTSNITO4fJD4fIUWMGyneXaRreIOio6Y
fNropxLqNjZpDVg8FNQNlRL7uE7XGRL7JXC+hbNqxw+sbjOByyXXHTvW4eSA
JsG8K2YMBqw408wSBAhp4VAxQD2ZosV65MWDKqLb0SM7muXwmdvqOXw9DhmI
FP/paIZM2FOvvm59nKJhxUZjZywHQDycCaWNWSFd4Hn8nZOW3Pkd/3MdYHQB
/oUj/E6nMP/O5T8mIKz7h/qhBIoBcDW3jr+7pGc8hOzVx+AM8JWC0hh2Oi5N
DwXPEaATAHLKACA02MJX3/j3y57NMdZJckv2FXyM4zW7Qj8l3CHOOfT1Hgx4
wAGWfOuTsWYWRsfMd0yP2Umg17mZJpXwqPBs1E+JtLCGq+ONoePKZoZI/FRM
f5JrGn9aJ3msG6Ho8H5o5JhU5LpQ1+TykWU4nGjI4RwqK4Pnm5SSj+KG9KVO
jQieIlnMP5ovympqAc5DfmdCiPFAr2CaOSMX82zDOA3yJBOzxQm/yC4VOz1M
ru5gOIcnwlzJVRiBJm1FbYB6tslJ5/PWKafRLEjqx3T4s8Hx11Bezsq7UfSq
1oYZvFqH7fq9CycWpf1d0tsXY8Gs57i9GKuzCOOpsiv3sabPvWnMpfRcQufl
hwgI+6LW3n14Z6nB02uTlLIT6nCkkYmqR8AI1paHWPWK0ph5lUgdSbnhj0nv
x5zqCuPR8WXjmrN2ZBMfE8SaINxv4G/7p1/razsdth4rOvmNvHDb4kfXC3f/
cPRm9fDdaHsQH0fX1wc/Ta7Pvlsfffz/Xrj/fl441+OGyrUuzAqmYRj9Wuoc
HhnyfKo86jei1OHp2fRwMD05GsVBMDo8dai2Pz0+no1OhqOzo3jWD8MgPJlG
wfHRYTA9nsajszgYHA4GsKHD4Cga9INaeRKT1zPLk+q+zcdcmGkjw9nhw5TX
nuHHjEA/TXWbpqqflOeybkzNomrKT7Mn0zEBXX+m56+zNywwV2UidCUrJjhj
jh83rqDa5h1uHlIErCZeEz/czSMuaqJDG10mT7DJHebC6rq2GiH2PVSe+mDg
5foC3fqfdwErL6jKxsuH8Qt4kBxoXYlp1Z4YvcO1G3WLnERu/IhtVxFaFOy1
ZJSbOx7I18j7a+PEFKaWV0nCSlQQYStifyhMXY9LvOeF/cxoCrwiH1Or9bRp
U8m6MXUX7G8bjA7FDUoV/g0OsiY/H7vp6jTb1BbaL3qha0mwZMPcBtGUCiHs
iC9MqTcSsb4rhJ6Vd0nf6LjORF5cE3Y8ABkxuH7TrMqAiXs1E6udESMf+xoy
ZY3FYnWyem4rmkyqi+hvflETkVsTIptqh1wTs+2VS1Z6MsQBqpgCsN9vuobP
Q+vnODqVGh2gMs68oe6Ft+SGkDC53wfDpOg4L+7wDR/q5EriNJTJhWj1ofO9
nfAjqJfu2gyNkIVNbk6mQ3d+f5BSLWNUyzER23nrLtc3toBBwXvyMUkjySSx
pi2lI8CeUh/0jB0DaW0g62YiwHi8PRal8AOVou478RmY4YFaQ4Fqbe5xwCFm
m3JDOW73CWcjZFqzBj5DuQyUtGIhadwBGKhpqUQWdq2cKOTQsbg+AI4HtNMw
YxP44xSrcjgriih8s5qiHwIwR8ujbuOyxAa84AUi5gvn56Y+6k3dxNwEhWc0
d3msZABAaY9A4XoVRJStGxe1OoLGDiiTv3IalfHg1nt0BZRMRs3nIy/gpENN
JCmRm4jpytMyYwdUTNH8dlwFNjcFD+O7DO86wkw8OnvGjSd3ETQUG7qZ6II3
bLYGm7QJqmeuwRVR70qUiCvC2rKYKE6LqCRMuINzhcffY+OQfFEpiKnTEKG6
EWV+w9FCetnqJvxJAbxCe6ZjFot58V+TKKTsFdOU82zJvhPUDdr0zGGafj6R
r186jcLooJmqUFh3qX+ujehELrgvivsbMeXOrgDhECW2ZYOzmnwm+WLUM9b2
aKk6yTfD3OnE9kJ6FpDcCMmH0c9FMjtbT0Zyu6m5rTu/fkoXx86p+K2ZWAtv
x7kce1iX3SisY1uimKDtsCv01+24s6vVLZXr+h6CbeFUNJouZn61tsSMQSFm
35FzC5EhBXlXSCE1h1g6Y8m07OMMF1nG7MGnLDOqFtxVImsorqiUXArjrWiT
nL+sB5dSCLzAhMp5k5JrIShXjZdHVpEuSdZ4BuxJFptBSUBMjDQFrANGWe41
x9Kv0ZWOdPucXHeVlFUsyfGx9R9yWQg6DBoc8aR7GsRpc0Gv7fG61MLMArCZ
EjBTlFqhlQaTqyFpsnoRCWzTmwzOwzRYBmmou4yDzq3bsBWivPp9Hv1pmFwk
aBJmupm0RJNIrTOdYjPZR6O6Ufa7gQB1cCB07nJpSwFtWac3MwYjK1Vkrqkm
2ax2LY2Fi6NqRN+1T4L7LIn8a4rkUis9LqdWOC0rMYPC7aR62B8Qzg77w1rb
OGP4gQCGBeZkJNHlbJW8hqW/SYBATN8hpeGwf6LuYryDJ8i3wNgYLCfq7LZi
JdniXL/lY6J3WsXFjYc9UTttCQJhwmqhmiGw64U6THhho8KPzCyAbmhlDV0J
Cx3Eksj/Uf+Q7nrB6w4/pME9yHXk7s4ypSWuuUTIOr+Jb3BCBJzWTVppg+vK
kWgjac+lwShVqiL6sS9JuACDlWzZgO7HJJJ9FKnHVQLTtwAQb8cbE5dUqYq9
Du7ZnGeXD4a/sd9/0Nhdk8+chABuMNbXndBnlZpNBycx185vVlxIYpCEmpok
qmQbHLWUugepGloFH9knxl6YLqpNbqZY88rRxVwpZ2V+g+GUg7sPN+/07ugm
ptKHuVljFEp4/GMsG5IcciBP7qNgb93buiLuWdWsdZ27sT8nN1udKDrDFL1E
HRilTA1c28ZFqm1td/f2myT9WElNEjVkeHqqqyYC7Ca5rOkQ1FWEmDvN02aS
wRHlnmEA8kpfnyCw4JMmXRMdxqaaUx4caa+Vi1h7G6Lth+PM6Efm3Zs0dNRy
rPVI+sxbuXO1RqAcDHYq29ulEAIsrK09nm25RJVsf4sm3ZOgMDRPcVMR9OId
gRPhzIWNx+1MBth2ZXbPg1SYotUslwYFFjKtypYeIp3PvVWjp7mL4XNSTPBd
0zXD8e3uOH9ntvvO6Qg7QfiLIcB/Efofx+1CSrYaVycl0QvtviEJKLFwH/NO
8F10MtMKBHniLNgsSxlODCFvC9ycFo80et7tZ7jssfpDUW7SMf6fCXuCOvnH
32Oy6kv3THkf4fEd4/+5H31rKi5ebqJ1wxC/d2/K0TT4so1/a//eQdrL9mp7
rYH+fXXfXtoFfRVMZfiPgan4rwDUoyn5VT5d+HKlrdQLJBCBzgtlNT2vXzji
nDCT78StFtw2k07AyHZ716Efw7VFxDn+f4cpGwsWT0rK9yXDEo3F8CzpYdTS
OicXNs5mcCpnWFfBH57r2I3x3jDH+vz5W93X6iGe5mXYHfaHg/4AW1vhNcDn
nhSPOICDyhc10dfZhcPeoPfMBVgmsGYXknF/t6sNAjHhYdwWy0TcWXlM6wKV
gTpu+A3wtesLEwu5pTRyfXNJub6DYr6RMgtuBYQ9/KpUZjar1msAN3xCKpkf
b6u7CBAKLJmleXUtbxGXPkrFqhCNLpQbHeRVbGK3dO9w1RdEa5xx6wDryklq
FpI4DtGVaBvruYFbigVhilA1ZPmERmdSEj+VlcYIa5CuMbeLw4BIzgmj5vb6
Sp9BN19a24cEgobnCThsGJaRwYgwFfu6w3W9+ZFNjh30Bqe+b9i3NR1nTaH1
1KKxYbv2oLpRrefh0eaxwYTVxnYkL3dpuJp2yL6rFLVzvwLHi0UHgmgI/la5
19i9472e3lTU08D1W84lF84Hv8PwNrKUJ0+KOJjItNGWqht513b9Ixe0VNHo
V4d4WJEESbZnnNwWXZvl7pSjU+NxFvvaT950LBCq9EKvF9Ch5BGYu+WIgSGz
D6LI9EiTPa3utxN+oNgdNqTTnkDnN9fcNyZz4CbqOUSsIwlIA02060VXyKR7
BvGKjleFXzocxrMlGcNuSQj2e9zV7rGjHX5EZncNAxtHtlM9MiEfYleuVOqK
A7n71mGVbe68yhJJi9Ad330vugBRjqjetWkds1A8xbWOWoXlBpp/aNzt5Gxg
+El6OSWzkInh0qDQVOS0XMVxmu66141VNDnSNJYm0XeSWzWGFuGPX6MQcR4D
vvQdESGjDpWtbzkefuw55amAufKyJlqOhPAlyfaScLor6y4x4WaHIyU6/YRs
jSL2B0IpMw0clYfK39buwdayWBZJz6gkQcqkqTaOmyGR+gcYwpY0q4R82gjT
Q5JGYEbt0S3YufiAOGS92ODFFRHFtlegYyYFdUDC7ohRt8y68J99E5wxp5+V
uKQghxt7YVeGdXnrM0ZTqgTTcg8TMcZl8InX5kTSZ5jrge6VisBlX8/EN1xJ
bXUNulZrslxWHH+d5n4CXjYMnZrq4DXfblN/qoagPVEG3Rao4/XTOMjplY8Y
/atN412PJLqJ1lJ12rsnvQK7yJJarlaFpTn5sAFOLYQOMszc5kK09gpQ6Jdc
NdQWWlT0jht8cS/Uq90rbXT82z4g5JNjOWUkoCOj0KNphzOOLl1OMHGpoLEc
z4dsp1rlXLB0fHJEPut6brqNwLDj4gmqdJR5XrOw8qcgx/O8XHqoKIxS5TDS
ikph213Hn7CNsAkIsFhrbncM8k10izTAvBc4NVs4e586ArJzJRvxbgebXkrg
gvu4RElh/CdGBzQJ5wWmxxeamxVhto5Ndk2UhRvuMHuLXEVMYDMxZQbh33Fm
UcNDzwEUIPCY7KDDC4YZZh31px/u9KdevSvvteOjPD0ZYtNjLrBbBKiuwJEE
FUMVZZYzww6IESP/ZkeSHhhJeLtOuIPYKsAwiY4vaFTojAbO/zSoqGvJ0hBD
38pV7w9XqL1Cqnxl7Afg7jd3b6+taS+5SP8Sbxk6uzvA3h8/l4xb0052ET9N
7f4dw9X3+QCKuMLxCEqv9tGCYmm58EqETIDZ1ccTo+xobIkzNqiQ63POnhtZ
0yKMa95s5oe6TVabJWowjDPYcNpjTsBiDLRazkt+67sjTIrUfftc9m6cK5Xo
q85FtC1xcgywuNe11qrUDqolajrrROcNFt4aHoKUI5IxR7XEtJELttK5zQGz
ja1d0VK/1K16M9vu9u5u+iOlk060ghlQO3SpnTTw8gScYkjmMlHbjgvhHpnW
8WzzxIArP6ZsYuRPbYhVmm81MfyFiOGcj8Pe7V/O9/3mEKVO4wL1bJMmcpOr
u6VWeiTSTBnAgYE6wkn4XnDKHfGKpZ1+CfhKuFfsd0g5IQcWeZGYu8NY7gZa
ZgUfZWRVkFPdtQPgEz4C5uZTVNlTPqmfX5hLk+3TL5WeiCYto+Tse/M1C3ut
dniMwfZODKSlvJPAzz3d58Da2J9DjClNsw2HuBkjD+5MtiECrKVpIY92mnOu
QY1g18qksEkkHlv6mj63dcN/pxOl1xTZdKpG0ZvaFAOktrUYTDQLFfvVMoWO
ddXZl5odpZVSePs6Gm7aZkVB5rWFNmWuNLPpF2sIj/dSF7YZTUW3+yB0BKWd
bcf+0dWpa9Fz/e7rbpKLyf5o0PRsqSO53OtpWPom2mb0VLuqODf9udqucelS
LqezqkvcqHVtaXqjmdpty+gdQJTqavJuoshzmuhyE60VJp/GO5zYMF27ZgLA
m126GB0rJ9ZByH3SXtteyB3DhZhh2xsILPh0bzmFOMDI1Be9e538Wb2Xl7i0
9543rKK66+uvFuVq2cNfetjs5GHey/L5AZcPAG4PnJG6PFIPv3hRf97xSFb3
MrOSpAaTpWbrBURxiSojK16Ozetf9+Id+8dvGG06ytK7uLLpGLvYtZ9j2aRx
fd1ttecp4E76JeF7K42vU7uPHZ2BRtl0lLsWuI2j9jk/h4aF5cJJQjVw6VR3
f22+BKfqL7PsI6W6mEsfGy9Ze/xata+7QU3Cj8949aAo4j/qeCPFIX/JZjwe
X/QvRDX70VYNkteLLj7yc3Pfr51zPdWGldqMe5eK+3kBYs81RStRs1C3eAc8
dtc+9zp5oo3qEqlNFeAaO+eWWKCiNU7DDg5kxOSIQ8LbFHLJvNyhQp+YbpHO
dFy7ruVOJWzHJereTRL+pens8ZOoCmWqSDTJzF1pU2psA7qjhyC/rdyQlfjO
cSIdBqAy9ApUtyVmadyZto1vgi0mxuo39u7e3O6bOUejY88CPhuMTjjNgxCo
xx3v8ogNax3bBydVH1GXkoSahjKvHp6d8v1E780Goqzv1LVAzEXNCtp5MiZx
+4ELYoVNscln2BnFlAQKtd1cAi+ZXF9JNKmQlBE2RpOStsgynRnwmcjmsAqT
jz8tgg05h8dwyK92lQ+hLULAcHwTfxOvDNXreDax6yznBgCe0WUakLI0wUYQ
2O5U18Y9cd1zD6CkM0NqFgwcNvka2MMccpazkzXLnbsjctGGfMuWuSAMFSpq
2aU9G3JROg6AOdwH0plDmoEiID8sEsmQXAV40xo13WH5b8SN9njLdQrxrvFQ
rwGwdl1uxuVimR+faxoGneRY35F4dYRLE7pyEiPM4nEt2qC2I9H9HeIXB9Si
cS4OWdYAsKRFN0ut0JLJbhbbkgJjtvOp0zokcVr/odIsuNe7twSlEFbELRVl
E5mSGOgdsTWnm0jFB6MLUWzWOa+T3GpMG/eUSMy4oGiJNVmZkA0cO6wcdO93
sTchcoZYX/mVTakuw6RBFmrv6uL9zb7nBdN7vhRxXozt1pBr6fEAbFPTrcIM
ximJQUFcfr7RnWyfPvG6Xbh/RivZy2wf2VtBJNnCB8UmGuebFO2sX7WL5pYZ
Qg2plkynsKdplK1SWqL41oEvbddlNs+D9UK8mbJB6yLeRBl/oosKZWisnDTV
1ewqptAwhspC9r7cmKn0VR02rGaEEwuhUR+lAeuZv4ICm7DPfDHeJYvpuw/a
IQNL/8Am1tUFcmrQOHK19+HD1cW+FpdHx8OOMpfvoDDMzdVymkQqHdV3EB3n
/3bdRjlaFI2V6elY05H1O+gdqXFXZkAU19XOskY25FwKVpEvfqvr+vVZ2MsA
m1LPF01UDIeDt4ukywoMR7rHhlpIs2hpbqEvstemNXsdq9z2ZuiiirJK08bC
vxfh787xGvo/kXZL9nijZuupkNxNnDXbJSrPpImS0KJOJ2T/sRsg3zLFYlh+
M+1ifiOZ50zIO5R4CauSXn6jh2ZzyWa/cVioYfppjGFbk7Ok3RHMammFfgB1
5HhaKQUdZjezvqP8bXdWJ4NsjLi6x/CFTkCgtXsZlhwK4nw7nQwkSWOc+YZe
bXNvYODKbTGx1zE5ym+0vBmru1cXTiOLLu3mlckNMC6nPUTvvt0I6pcApi+i
gLJKio+SUKePHm6o/zol0WGPgGfN1ZZbDPlTsTAYO94AiRlgXQEWUFdI983n
feC59oq2Bj+J3ZxxIgkmqhv+3W/rgRt265Kn9ZDZ8QRzLuIw+wgN0xTxJcyn
fXV597phRKT3G0uLBnPXaH3H6C+7ijQPt+vY6kIAuaCrNiTZD86wDaP5EZ7D
I4wm7HCutfnC4VWQBnPdz82dsqNqOBDY/o57LEH9509mkfn5hXEU6mdyVeVX
wW7GSwpzQbTgDGkhkb6W2sfeiGllkMphWjNmZBlMwZh2qkqUUl1Nw3JEx8/D
RPVbrkx5/qrZdcSD3LrSYOxHyNUeEBmyqH33C+/YmejI2B/JXJEmsL4mdyLh
aYwmesfFTUdJ+2+RdUuMXNnaJKoyRVo1eDW/8Yab5xIrcHqVeBcOaqTD/OPa
tevaZ+Yu1RMQv4TAZcJzXt65Wd5YIWvxsWpkwo49MKqf4yKH2Sz1f5HZduDq
l63ADPRVR3XHGO6h9UD/qoN7WZETv/zkcgDi73161a84vv7a/wcdZIYLxXqz
vCUJ7pCPCQ5VskvUpkyWdJU1UR56eeROUTeNII52Kqza9m8IelQ9zNXIVVNQ
+ktPq91yelnIarODpT33Ud2tbFBlv+uSqLiJ8UbtaphbN3fyNhPLrtHT3Gq9
MxNcXZBXEknffajaLNuM9h0UeG8ghbI9yrmyGek00F9gPUSCA/zXBXb3YzX3
Ig6XlOck2x/YywrMcmkErQRxUeIcrJ6fhKoRSNM/4TKdA+75tTtQYvCSxzAm
wxYYN95xyJkJIBPCcqwmSKn6KfacyMXPtcpASHhZABtQ4UOsmCYHGd4c2AF0
gFb/z8hBMPCHmguvx6ift1uaCD68LfNNiNvRgFi9H/gSJWy8u73dJ48tQMIk
i2bGRlyDsgnexhR4zbx4Hxdeqzkzb7N0+4xG1ZfxZ8Q2/IcqhZA+5Vavj/GW
m/E2DL2KA3QNMeNDPsDlmHcLfdkdPRCbwbcwKWrnJj+3ievS+2Y45oETm7o/
uT2/usIVmfJ4zA6hnsOinZNpRimEfkrwXhHHSjKvB6PBly/7dEA0BOi6+Bt2
qjIofSwIxSKBo9wmb51unsXg08bwb7rM1iFVemiXR6iG9aXb/7yFMXtzWcce
V1hIBpjuPDTNKUEuwpyCJFWOHY+X4nEm43RLbTFSvk4V/eWS7EYuKuytopkq
IGIX6sj25qtcJmkIJw3r4y5EJGl+Ach5l6XAkBwjhx1h5L7zPRjmPEW18y2n
YmpKXRKb5nGfxA86yhIjrilfZ2Nm6XmzXyP/KkqSWLXpAdz3JMp41y1zlOhF
1PE6yhE45je5TsH2BpHbaM29evlm6VYb0OvEdZkAgFClIMEk4/sbrvOFuB/m
hnp9FJLKwul+dIrdkaR5PMttASQxGlstP0zuZHOaxc/4LCFGNXDU0t7MhQVC
ohZk1PYnoZNxLeEEvMXBIn9ilkt7bfkeZ5SgU4jZx17cm/c6j6h1+3zrJzlv
GJUoYLsE+r2W/74g3QnVDd49t/Ep1iaJIKHTxuEkb+JPlIFwCQcX8EGKt3zD
XwTLih/49xyBMSMsZYTYjlDNJbcsgEPEAME5MxFq70G4Ik2CuMgT88PHf7E3
lr/Ve71jpbeYS82/fbfMpsHS9cWwLCbMGqfIpdWs2CLytCGXeekAUzXPDl1Z
O7U1Epm0YHZnpF/jvtjhcdpqVtuQirTfI+1ZX/ZTXyZDpG0S6qcgdf+/rV5p
XEbOldZ8sbPn/G/C2eNdGCluoVqP7qLc3Jk6svyZeVyok/qWx7W2PEhakoaH
mjCyVlOk+rgu1vFb+yHicSjqSMSqHF5HsDHB8Z2IQa6WFVxRlmQSp7WgEmI+
2CJKFyiqKgWbJ50vOTt9k4MlGvVkQbff4YLweziwiGVaVV0hNf49PuJUbg78
tKao4kgeEnxg2LhAuectoGCNpOo4xQPmbCRt8J6uFTIc+DFWi15Z1Mbn3Ito
19HQ8knbpbqjACwZOJduOIbXwSaY6WWyNWUXPW5Nfc6KDV47zdF9aqVoxF21
RsrcwgBqG5fY10rVCy8l26LQnpOd+2UDEFS15G4fEc0kBX0fRgxQveYerWiR
w3w3l3/+cHVzeWGOc96wOcxAqCgPd0hshFUWoQZm4lVrWi9Vaz0+Jymx3sTV
SR8//O7sO9907tWrbHdqQQaAeubY543+CNi4eZJK+I2ysmHPSseK5HCRGLad
aq2baX1KgYOOLv4mx0CQBv+M/4fnh1AGFp204qWimp27LowGjjIodxI/SNXE
5v+xTY5Vm4qqNvcmN3f7agKUrS4o9SAzjWmkKSBwiJ5GBN85K8MXDioqrXO+
fXV+TQ1bdU4722vIdVri5Xlv70JvRC6oAhLZsY1TsdqThKm4KnAc6ogc2XZE
/t1e2DwjjzwXRcPpdzyJTJ5IjpL6yZ0kYtN52cj8XQK22iQbh3yCNgotJ8Qg
gs0MTKsNYs22ZtEps9dZdnZ0MyBF4E3BA2ZwZDiO4IFuchNRoY9Ah/RneaEh
Rqvp1dAC4qjWEFysw1rhnJfc3TW5adVb+FAjn8bWziAe7CggJDw5/1cKD2rZ
9yLJv9uA3piKl8pxulzSOZGmmbXnau/icr/a+TMoQvhJF5ETh9D3KhWbhC9E
ilzjUe0FvkTYb+gu5YhRyoXJsHyZnYFiExkfaVJYOSS3WLHccUWRLmi/uDSM
1F1EuIiBzdIBAWsXxQ6ArxU03UzTv2G6Qq3Yl82QIZ7Ekmej6hsXdqdWjLCf
mWspC/+0F9ZKrZQKWutYElNXhAhgewCvySGpZmRwFigHjtWt0TjJtuN80j3U
TPbVD1lOffi+oxCyq58gFm99H6ZtslWTFtrh173Igxl8+yYoyipm3JvcEDPc
BcfFT8D9JCuNf9H3AlsszVipnb/twUql95S0Zy6pJ4ooFlYlQF1Vq7W7GJan
b1kX7NMmhJZl5I4h7qM3xcmAkvHYJlP4LTrSpF4DrUAvA61htqdM6ceyyPd7
PKsTvpqoGcsvr7sgWyrV4+QfYB7qnbgCTVzhPhYX2+xZy7hFbgwqGZa8VqD0
4nkTNc2TeObGL8wlbps0dP/t1COw12WByc6IJkpdo3vpHjKe41z8UY4EGTc9
NNviuQ25iWqBThduYlmV3ZjbMwmxIggUjzl7BpklcY1sQWaBFDABR38D0jT9
KVNvkzQBhbij/rRZJpviJ3W+yLNpFv4Uf+yoSRSs1E0WhIuOeof9yN8vlqs4
wegNvMYlQN9nS8zCm8Mj2AwwdNTlcplkJYi07+AEBveZ+i7IwySAKYB3FepV
kuN1mLfAWnL8bRMmDcOxUw57SiADi5dOpEPf7UJVO6WwPTI8jeQSlgWSfRbH
0RR0XGAL2N1A0vnQ1UM8zVp2Et4xbF9S8nW5soqD3O0dLexJCIHKf4B5dbtd
hbO1/h/Vl14kbs0AAA==

-->

</rfc>