rfc9725.original.xml   rfc9725.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-wish-whip-16" number="9725" category="std" consensus="true" updates="8840,
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft 8842" obsoletes="" tocInclude="true" submissionType="IETF" sortRefs="true" symR
-ietf-wish-whip-16" category="std" consensus="true" updates="8842, 8840" tocIncl efs="true" version="3" xml:lang="en">
ude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.22.0 --> <!-- [rfced] This is a question for Sergio. Your name appears as follows in
the document header:
Original:
S. Murillo
Your name has appeared in various ways in the other RFCs that you have
authored (see below). Which form do you prefer?
RFC 9605:
S. G. Murillo
RFCs 9335 and 8079:
S. Garcia Murillo
S. Garcia Murillo
-->
<front> <front>
<title abbrev="whip">WebRTC-HTTP ingestion protocol (WHIP)</title> <title abbrev="whip">WebRTC-HTTP Ingestion Protocol (WHIP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-wish-whip-16"/> <seriesInfo name="RFC" value="9725"/>
<author initials="S." surname="Murillo" fullname="Sergio Garcia Murillo"> <author initials="S." surname="Murillo" fullname="Sergio Garcia Murillo">
<organization>Millicast</organization> <organization>Millicast</organization>
<address> <address>
<email>sergio.garcia.murillo@cosmosoftware.io</email> <email>sergio.garcia.murillo@cosmosoftware.io</email>
</address> </address>
</author> </author>
<author initials="A." surname="Gouaillard" fullname="Alexandre Gouaillard"> <author initials="A." surname="Gouaillard" fullname="Alexandre Gouaillard">
<organization>CoSMo Software</organization> <organization>CoSMo Software</organization>
<address> <address>
<email>alex.gouaillard@cosmosoftware.io</email> <email>alex.gouaillard@cosmosoftware.io</email>
</address> </address>
</author> </author>
<date year="2024" month="August" day="21"/> <date year="2025" month="January"/>
<area>ART</area> <area>WIT</area>
<workgroup>wish</workgroup> <workgroup>wish</workgroup>
<keyword>WebRTC</keyword>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract> <abstract>
<?line 35?>
<t>This document describes a simple HTTP-based protocol that will allow WebRTC-b <t>This document describes a simple HTTP-based protocol that will allow
ased ingestion of content into streaming services and/or CDNs.</t> WebRTC-based ingestion of content into streaming services and/or
<t>This document updates RFC 8842 and RFC 8840.</t> Content Delivery Networks (CDNs).</t>
<t>This document updates RFCs 8840 and 8842.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 41?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The IETF RTCWEB working group standardized JSEP (<xref target="RFC9429" <t>The IETF RTCWEB Working Group standardized the JavaScript Session Estab
/>), a mechanism used to control the setup, management, and teardown of a multim lishment Protocol (JSEP) <xref
edia session. It also describes how to negotiate media flows using the Offer/Ans target="RFC9429"/>, a mechanism used to control the setup, management,
wer Model with the Session Description Protocol (SDP) <xref target="RFC3264"/> i and teardown of a multimedia session. It also describes how to negotiate
ncluding the formats for data sent over the wire (e.g., media types, codec param media flows using the offer/answer model with the Session Description
eters, and encryption). WebRTC intentionally does not specify a signaling transp Protocol (SDP) <xref target="RFC3264"/>, including the formats for data
ort protocol at application level.</t> sent over the wire (e.g., media types, codec parameters, and
<t>Unfortunately, the lack of a standardized signaling mechanism in WebRTC encryption). WebRTC intentionally does not specify a signaling transport
has been an obstacle to adoption as an ingestion protocol within the broadcast/ protocol at the application level.</t>
streaming industry, where a streamlined production pipeline is taken for granted
: plug in cables carrying raw media to hardware encoders, then push the encoded <!-- [rfced] How may we clarify the text that appears after the colon in
media to any streaming service or Content Delivery Network (CDN) ingest using an the sentence below? How does it connect to the rest of the sentence?
ingestion protocol.</t>
<t>While WebRTC can be integrated with standard signaling protocols like S Original:
IP <xref target="RFC3261"/> or XMPP <xref target="RFC6120"/>, they are not desig Unfortunately, the lack of a standardized signaling mechanism in
ned to be used in broadcasting/streaming services, and there is also no sign of WebRTC has been an obstacle to adoption as an ingestion protocol
adoption in that industry. RTSP <xref target="RFC7826"/>, which is based on RTP, within the broadcast/streaming industry, where a streamlined
does not support the SDP offer/answer model <xref target="RFC3264"/> for negoti production pipeline is taken for granted: plug in cables carrying raw
ating the characteristics of the media session.</t> media to hardware encoders, then push the encoded media to any
<t>This document proposes a simple protocol based on HTTP for supporting W streaming service or Content Delivery Network (CDN) ingest using an
ebRTC as media ingestion method which:</t> ingestion protocol.
Perhaps:
Unfortunately, the lack of a standardized signaling mechanism in
WebRTC has been an obstacle to its adoption as an ingestion protocol
within the broadcast and streaming industry, where a streamlined
production pipeline is taken for granted. For example, cables carrying raw
media to hardware encoders are plugged in and then the encoded media is
pushed to any streaming service or Content Delivery Network (CDN) using an
ingestion protocol.
-->
<t>Unfortunately, the lack of a standardized signaling mechanism in
WebRTC has been an obstacle to its adoption as an ingestion protocol withi
n
the broadcast and streaming industry, where a streamlined production
pipeline is taken for granted: plug in cables carrying raw media to
hardware encoders, then push the encoded media to any streaming service
or Content Delivery Network (CDN) ingest using an ingestion
protocol.</t>
<t>While WebRTC can be integrated with standard signaling protocols like
SIP <xref target="RFC3261"/> or Extensible Messaging and Presence
Protocol (XMPP) <xref target="RFC6120"/>, they are not designed to be
used in broadcasting and streaming services, and there is also no sign of
adoption in that industry. The Real-Time Streaming Protocol (RTSP) <xref t
arget="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 W
ebRTC as a media ingestion method that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Is easy to implement,</t> <t>is easy to implement,</t>
</li> </li>
<li> <li>
<t>Is as easy to use as popular IP-based broadcast protocols</t> <t>is as easy to use as popular IP-based broadcast protocols,</t>
</li> </li>
<li> <li>
<t>Is fully compliant with WebRTC and RTCWEB specs</t> <t>is fully compliant with WebRTC and RTCWEB specs,</t>
</li> </li>
<li> <li>
<t>Enables ingestion on both classical media platforms and WebRTC end- to-end platforms, achieving the lowest possible latency.</t> <t>enables ingestion on both classical media platforms and WebRTC end- to-end platforms (achieving the lowest possible latency),</t>
</li> </li>
<li> <li>
<t>Lowers the requirements on both hardware encoders and broadcasting services to support WebRTC.</t> <t>lowers the requirements on both hardware encoders and broadcasting services to support WebRTC, and</t>
</li> </li>
<li> <li>
<t>Is usable both in web browsers and in standalone encoders.</t> <t>is usable in both web browsers and standalone encoders.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>The WebRTC-HTTP Ingest Protocol (WHIP) is designed to facilitate a one- <t>The WebRTC-HTTP Ingestion Protocol (WHIP) is designed to facilitate a
time exchange of Session Description Protocol (SDP) offers and answers using HTT one-time exchange of Session Description Protocol (SDP) offers and
P POST requests. This exchange is a fundamental step in establishing an Interact answers using HTTP POST requests. This exchange is a fundamental step in
ive Connectivity Establishment (ICE) and Datagram Transport Layer Security (DTLS establishing an Interactive Connectivity Establishment (ICE) and
) session between the WHIP client, which represents the encoder or media produce Datagram Transport Layer Security (DTLS) session between the WHIP
r, and the media server, the broadcasting ingestion endpoint.</t> client, which represents the encoder or media producer, and the media
<t>Upon successful establishment of the ICE/DTLS session, unidirectional m server, which is the broadcasting ingestion endpoint.</t>
edia data transmission commences from the WHIP client to the media server. It is <t>Upon successful establishment of the ICE/DTLS session, unidirectional
important to note that SDP renegotiations are not supported in WHIP, meaning th media data transmission commences from the WHIP client to the media
at no modifications to the "m=" sections can be made after the initial SDP offer server. It is important to note that SDP renegotiations are not
/answer exchange via HTTP POST is completed and only ICE related information can supported in WHIP. This means that no modifications to the "m=" sections
be updated via HTTP PATCH requests as defined in <xref target="ice-support"/>.< can be made after the initial SDP offer/answer exchange via HTTP POST is
/t> completed and that only ICE-related information can be updated via HTTP PA
<t>The following diagram illustrates the core operation of the WHIP protoc TCH
ol for initiating and terminating an ingest session:</t> 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"> <figure anchor="whip-protocol-operation">
<name>WHIP session setup and teardown</name> <name>WHIP Session Setup and Teardown</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-------------+ +---------------+ +--------------+ +---------------+
+-------------+ +---------------+ +--------------+ +---------------+ | WHIP client | | WHIP endpoint | | Media server | | WHIP session |
| WHIP client | | WHIP endpoint | | Media Server | | WHIP session | +--+----------+ +---------+-----+ +------+-------+ +--------|------+
+--+----------+ +---------+-----+ +------+-------+ +--------|------+ | | | |
| | | | | | | |
| | | | |HTTP POST (SDP offer) | | |
|HTTP POST (SDP Offer) | | | +------------------------>+ | |
+------------------------>+ | | |201 Created (SDP answer) | | |
|201 Created (SDP answer) | | | +<------------------------+ | |
+<------------------------+ | | | ICE REQUEST | |
| ICE REQUEST | | +--------------------------------------->+ |
+--------------------------------------->+ | | ICE RESPONSE | |
| ICE RESPONSE | | |<---------------------------------------+ |
|<---------------------------------------+ | | DTLS SETUP | |
| DTLS SETUP | | |<======================================>| |
|<======================================>| | | RTP/RTCP FLOW | |
| RTP/RTCP FLOW | | +<-------------------------------------->+ |
+<-------------------------------------->+ | | HTTP DELETE |
| HTTP DELETE | +---------------------------------------------------------->+
+---------------------------------------------------------->+ | 200 OK |
| 200 OK | <-----------------------------------------------------------x
<-----------------------------------------------------------x
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The elements in <xref target="whip-protocol-operation"/> are described
as follows:</t> <!-- [rfced] The list after Figure 1 is introduced as definitions of the
<ul spacing="normal"> elements in Figure 1. However, "WHIP endpoint URL" and "WHIP session URL"
<li> appear in the list but not in the figure. Are any updates needed?
<t>WHIP client: This represents the WebRTC media encoder or producer,
which functions as a client of the WHIP protocol by encoding and delivering medi Original:
a to a remote media server.</t> The elements in Figure 1 are described as follows:
</li> -->
<li>
<t>WHIP endpoint: This denotes the ingest server that receives the ini <t>The elements in <xref target="whip-protocol-operation"/> are
tial WHIP request.</t> described as follows:</t>
</li> <dl spacing="normal">
<li> <dt>WHIP client:</dt><dd>This represents the WebRTC media encoder or
<t>WHIP endpoint URL: Refers to the URL of the WHIP endpoint responsib producer, which functions as a client of the WHIP protocol by
le for creating the WHIP session.</t> encoding and delivering media to a remote media server.</dd>
</li> <dt>WHIP endpoint:</dt><dd>This denotes the ingest server that
<li> receives the initial WHIP request.</dd>
<t>Media server: This is the WebRTC media server or consumer responsib <dt>WHIP endpoint URL:</dt><dd>This refers to the URL of the WHIP endp
le for establishing the media session with the WHIP client and receiving the med oint responsible for creating the WHIP session.</dd>
ia content it produces.</t> <dt>Media server:</dt><dd>This is the WebRTC media server or
</li> consumer responsible for establishing the media session with the
<li> WHIP client and receiving the media content it produces.</dd>
<t>WHIP session: This indicates the server handling the allocated HTTP <dt>WHIP session:</dt><dd>This indicates the server handling the
resource by the WHIP endpoint for an ongoing ingest session.</t> allocated HTTP resource by the WHIP endpoint for an ongoing ingest
</li> session.</dd>
<li>
<t>WHIP session URL: Refers to the URL of the WHIP resource allocated <!-- [rfced] What does "such as ICE operations or termination" refer to?
by the WHIP endpoint for a specific media session. The WHIP client can send requ
ests to the WHIP session using this URL to modify the session, such as ICE opera Original:
tions or termination.</t> The WHIP
</li> client can send requests to the WHIP session using this URL to
</ul> modify the session, such as ICE operations or termination.
<t>The <xref target="whip-protocol-operation"/> illustrates the communicat -->
ion flow between a WHIP client, WHIP endpoint, media server, and WHIP session. T
his flow outlines the process of setting up and tearing down an ingestion sessio <dt>WHIP session URL:</dt><dd>This refers to the URL of the WHIP resou
n using the WHIP protocol, involving negotiation, ICE for Network Address Transl rce
ation (NAT) traversal, DTLS and Secure Real-time Transport Protocol (SRTP) for s allocated by the WHIP endpoint for a specific media session. The
ecurity, and RTP/RTCP for media transport:</t> WHIP client can send requests to the WHIP session using this URL to
modify the session, such as ICE operations or 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 session using the WHIP protocol, 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>
<!-- [rfced] If no objections, we will update these to be complete sentences
as shown below.
Original:
* WHIP client: Initiates the communication by sending an HTTP POST
with an SDP Offer to the WHIP endpoint.
* WHIP endpoint: Responds with a "201 Created" message containing an
SDP answer.
* WHIP client and media server: Establish an ICE and DTLS sessions
for NAT traversal and secure communication.
* RTP/RTCP Flow: Real-time Transport Protocol and Real-time
Transport Control Protocol flows are established for media
transmission from the WHIP client to the media server, secured by
the SRTP profile.
* WHIP client: Sends an HTTP DELETE to terminate the WHIP session.
* WHIP session: Responds with a "200 OK" to confirm the session
termination.
Perhaps:
* The WHIP client initiates the communication by sending an HTTP POST
with an SDP offer to the WHIP endpoint.
* The WHIP endpoint responds with a "201 Created" message containing an
SDP answer.
* The WHIP client and media server establish an ICE and DTLS sessions
for NAT traversal and secure communication.
* RTP/RTCP flows are established for media
transmission from the WHIP client to the media server, secured by
the SRTP profile.
* The WHIP client sends an HTTP DELETE to terminate the WHIP session.
* The WHIP session responds with a "200 OK" to confirm the session
termination.
-->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>WHIP client: Initiates the communication by sending an HTTP POST w
<t>WHIP client: Initiates the communication by sending an HTTP POST wi ith an SDP offer to the WHIP endpoint.</li>
th an SDP Offer to the WHIP endpoint.</t> <li>WHIP endpoint: Responds with a "201 Created" message containing an
</li> SDP answer.</li>
<li> <li>WHIP client and media server: Establish ICE and DTLS sessions for
<t>WHIP endpoint: Responds with a "201 Created" message containing an NAT traversal and secure communication.</li>
SDP answer.</t> <li>RTP/RTCP flow: RTP and RTCP flows are established for
</li> media transmission from the WHIP client to the media server, secured
<li> by the SRTP profile.</li>
<t>WHIP client and media server: Establish an ICE and DTLS sessions fo <li>WHIP client: Sends an HTTP DELETE to terminate the WHIP session.</
r NAT traversal and secure communication.</t> li>
</li> <li>WHIP session: Responds with a "200 OK" to confirm the session term
<li> ination.</li>
<t>RTP/RTCP Flow: Real-time Transport Protocol and Real-time Transport
Control Protocol flows are established for media transmission from the WHIP cli
ent to the media server, secured by the SRTP profile.</t>
</li>
<li>
<t>WHIP client: Sends an HTTP DELETE to terminate the WHIP session.</t
>
</li>
<li>
<t>WHIP session: Responds with a "200 OK" to confirm the session termi
nation.</t>
</li>
</ul> </ul>
</section> </section>
<section anchor="protocol-operation"> <section anchor="protocol-operation">
<name>Protocol Operation</name> <name>Protocol Operation</name>
<section anchor="http-usage"> <section anchor="http-usage">
<name>HTTP usage</name> <name>HTTP Usage</name>
<t>Following <xref target="BCP56"/> guidelines, WHIP clients <bcp14>MUST
NOT</bcp14> match error codes returned by the WHIP endpoints and resources to a <!-- [rfced] We were unable to find a "problem statement json object"
specific error cause indicated in this specification. WHIP clients <bcp14>MUST< mentioned in RFC 9457. However, a "problem details JSON object" is
/bcp14> be able to handle all applicable status codes gracefully falling back to defined. Should the text below be updated accordingly?
the generic n00 semantics of a given status code on unknown error codes. WHIP e
ndpoints and resources could convey finer-grained error information by a problem Original:
statement json object in the response message body of the failed request as per WHIP endpoints and resources could convey finer-grained error
<xref target="RFC9457"/>.</t> information by a problem statement json object in the response message body o
<t>The WHIP endpoints and sessions are origin servers as defined in <xre f
f section="3.6." sectionFormat="of" target="RFC9110"/> handling the requests and the failed request as per [RFC9457].
providing responses for the underlying HTTP resources. Those HTTP resources do
not have any representation defined in this specification, so the WHIP endpoints Perhaps:
and sessions <bcp14>MUST</bcp14> return a 2XX sucessfull response with no conte WHIP endpoints and resources could convey more finely grained error
nt when a GET request is received.</t> information with a problem details JSON object in the response message body
of the failed request as per [RFC9457].
-->
<t>Following the guidelines in <xref 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 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" sectionFormat="of" target="RFC9110"/>; they handle t
he
requests and 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 successful response with no content
when a GET request is received.</t>
</section> </section>
<section anchor="ingest-session-set-up"> <section anchor="ingest-session-set-up">
<name>Ingest session set up</name> <name>Ingest Session Setup</name>
<t>In order to set up an ingestion session, the WHIP client <bcp14>MUST<
/bcp14> generate an SDP offer according to the JSEP rules for an initial offer a <!-- [rfced] Are "perform" and "performing" the best word choice in these
s in <xref section="5.2.1" sectionFormat="of" target="RFC9429"/> and perform an sentences? Or would "send/sending" or "make/making" be better?
HTTP POST request as per <xref section="9.3.3" sectionFormat="of" target="RFC911
0"/> to the configured WHIP endpoint URL.</t> Original:
<t>The HTTP POST request <bcp14>MUST</bcp14> have a content type of "app In order to set up an ingestion session, the WHIP client MUST
lication/sdp" and contain the SDP offer as the body. The WHIP endpoint <bcp14>MU generate an SDP offer according to the JSEP rules for an initial
ST</bcp14> generate an SDP answer according to the JSEP rules for an initial ans offer as in Section 5.2.1 of [RFC9429] and perform an HTTP POST
wer as in <xref section="5.3.1" sectionFormat="of" target="RFC9429"/> and return request as per Section 9.3.3 of [RFC9110] to the configured WHIP
a "201 Created" response with a content type of "application/sdp", the SDP answ endpoint URL.
er as the body, and a Location header field pointing to the newly created WHIP s ...
ession. If the HTTP POST to the WHIP endpoint has a content type different than To explicitly terminate a WHIP session, the WHIP client MUST perform
"application/sdp" or the SDP is malformed, the WHIP endpoint <bcp14>MUST</bcp14> an HTTP DELETE request to the WHIP session URL returned in the
reject the HTTP POST request with an appropiate 4XX error response.</t> Location header field of the initial HTTP POST.
<t>As the WHIP protocol only supports the ingestion use case with unidir ...
ectional media, the WHIP client <bcp14>SHOULD</bcp14> use "sendonly" attribute i The generation of the TURN server credentials may require performing
n the SDP offer but <bcp14>MAY</bcp14> use the "sendrecv" attribute instead, "in a request to an external provider, which can both add latency to the
active" and "recvonly" attributes <bcp14>MUST NOT</bcp14> be used. The WHIP endp OPTIONS request processing and increase the processing required to
oint <bcp14>MUST</bcp14> use "recvonly" attribute in the SDP answer.</t> handle that request.
<t>Following <xref target="sdp-exchange-example"/> is an example of an H -->
TTP POST sent from a WHIP client to a WHIP endpoint and the "201 Created" respon
se from the WHIP endpoint containing the Location header pointing to the newly c <t>In order to set up an ingestion session, the WHIP client
reated WHIP session:</t> <bcp14>MUST</bcp14> generate an SDP offer according to the JSEP rules
for an initial offer as per <xref section="5.2.1" sectionFormat="of"
target="RFC9429"/> and perform 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 per <xref section="5.3.1"
sectionFormat="of" target="RFC9429"/> and return the following: a "201 C
reated"
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
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; 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><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>
<figure anchor="sdp-exchange-example"> <figure anchor="sdp-exchange-example">
<name>Example of SDP offer/answer exchange done via an HTTP POST</name <name>Example of the SDP Offer/Answer Exchange Done via an HTTP POST</
> name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
POST /whip/endpoint HTTP/1.1 POST /whip/endpoint HTTP/1.1
Host: whip.example.com Host: whip.example.com
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 1101 Content-Length: 1101
v=0 v=0
o=- 5228595038118931041 2 IN IP4 127.0.0.1 o=- 5228595038118931041 2 IN IP4 127.0.0.1
s=- s=-
t=0 0 t=0 0
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
skipping to change at line 255 skipping to change at line 473
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 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=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly a=recvonly
a=rtpmap:96 VP8/90000 a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96 a=fmtp:97 apt=96
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Once a session is set up, consent freshness as per <xref target="RFC7
675"/> <bcp14>SHALL</bcp14> be used to detect non-graceful disconnection by full <t>Once a session is set up, consent freshness as per <xref
ICE implementations and DTLS teardown for session termination by either side.</ target="RFC7675"/> <bcp14>SHALL</bcp14> be used to detect non-graceful
t> disconnection by full ICE implementations and DTLS teardown for
<t>To explicitly terminate a WHIP session, the WHIP client <bcp14>MUST</ session termination by either side.</t>
bcp14> perform an HTTP DELETE request to the WHIP session URL returned in the Lo
cation header field of the initial HTTP POST. Upon receiving the HTTP DELETE req <t>To explicitly terminate a WHIP session, the WHIP client
uest, the WHIP session will be removed and the resources freed on the media serv <bcp14>MUST</bcp14> perform an HTTP DELETE request to the WHIP session
er, terminating the ICE and DTLS sessions.</t> URL returned in the Location header field of the initial HTTP
<t>A media server terminating a session <bcp14>MUST</bcp14> follow the p POST. Upon receiving the HTTP DELETE request, the WHIP session will be
rocedures in <xref section="5.2" sectionFormat="of" target="RFC7675"/> for imme removed and the resources freed on the media server, terminating the
diate revocation of consent.</t> ICE and DTLS sessions.</t>
<t>The WHIP endpoints <bcp14>MUST</bcp14> support OPTIONS requests for C
ross-Origin Resource Sharing (CORS) as defined in <xref target="FETCH"/>. The "2 <t>A media server terminating a session <bcp14>MUST</bcp14> follow the
00 OK" response to any OPTIONS request <bcp14>SHOULD</bcp14> include an "Accept- procedures in <xref section="5.2" sectionFormat="of"
Post" header with a media type value of "application/sdp" as per <xref target="W target="RFC7675"/> for immediate revocation of consent.</t>
3C.REC-ldp-20150226"/>.</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" header with a media
type value of "application/sdp" as per <xref
target="W3C.REC-ldp-20150226"/>.</t>
</section> </section>
<section anchor="ice-support"> <section anchor="ice-support">
<name>ICE support</name> <name>ICE Support</name>
<t>ICE <xref target="RFC8845"/> is a protocol addressing the complexitie
s of NAT traversal, commonly encountered in Internet communication. NATs hinder <!-- [rfced] Are the citations for RFC 8445 correct in the following
direct communication between devices on different local networks, posing challen sentences? We ask because "ICE" does not appear in RFC 8445. Was the
ges for real-time applications. ICE facilitates seamless connectivity by employi intent to cite RFC 8445 (titled "Interactive Connectivity Establishment
ng techniques to discover and negotiate efficient communication paths.</t> (ICE): A Protocol for Network Address Translator (NAT) Traversal")?
<t>Trickle ICE <xref target="RFC8838"/> optimizes the connectivity proce
ss by incrementally sharing potential communication paths, reducing latency, and Original:
facilitating quicker establishment.</t> ICE [RFC8845] is a protocol addressing the complexities of NAT
<t>ICE Restarts are crucial for maintaining connectivity in dynamic netw traversal, commonly encountered in Internet communication.
ork conditions or disruptions, allowing devices to re-establish communication pa ...
ths without complete renegotiation. This ensures minimal latency and reliable re Depending on the Trickle ICE support on the WHIP client, the initial
al-time communication.</t> offer by the WHIP client MAY be sent after the full ICE gathering is
<t>Trickle ICE and ICE restart support are <bcp14>RECOMMENDED</bcp14> fo complete with the full list of ICE candidates, or it MAY only contain
r both WHIP sessions and clients.</t> local candidates (or even an empty list of candidates) as per
[RFC8845].
-->
<t>ICE <xref target="RFC8845"/> is a protocol that addresses the
complexities of NAT 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 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"> <section anchor="http-patch-usage">
<name>HTTP PATCH request usage</name> <name>HTTP PATCH Request Usage</name>
<t>The WHIP client <bcp14>MAY</bcp14> perform trickle ICE or ICE resta
rts by sending an HTTP PATCH request as per <xref target="RFC5789"/> to the WHIP <!-- [rfced] For ease of the reader, may we update this sentence as follows
session URL, with a body containing an SDP fragment with media type "applicatio (i.e., split into two sentences and update "carrying" to ", which carries")?
n/trickle-ice-sdpfrag" as specified in <xref target="RFC8840"/> carrying the rel
evant ICE information. If the HTTP PATCH to the WHIP session has a content type Original:
different than "application/trickle-ice-sdpfrag" or the SDP fragment is malforme The WHIP client MAY perform trickle ICE or ICE restarts by sending an
d, the WHIP session <bcp14>MUST</bcp14> reject the HTTP PATCH with an appropiate HTTP PATCH request as per [RFC5789] to the WHIP session URL, with a
4XX error response.</t> body containing an SDP fragment with media type "application/trickle-
<t>If the WHIP session supports either Trickle ICE or ICE restarts, bu ice-sdpfrag" as specified in [RFC8840] carrying the relevant ICE
t not both, it <bcp14>MUST</bcp14> return a "422 Unprocessable Content" error re information.
sponse for the HTTP PATCH requests that are not supported as per <xref section="
15.5.21" sectionFormat="of" target="RFC9110"/>.</t> Perhaps:
<t>The WHIP client <bcp14>MAY</bcp14> send overlapping HTTP PATCH requ The WHIP client MAY perform Trickle ICE or ICE restarts by sending an HTTP
ests to one WHIP session. Consequently, as those HTTP PATCH requests may be rece PATCH request (as per [RFC5789]) to the WHIP session URL. This HTTP PATCH
ived out-of-order by the WHIP session, if WHIP session supports ICE restarts, it request contains a body containing an SDP fragment with media type
<bcp14>MUST</bcp14> generate a unique strong entity-tag identifying the ICE ses "application/trickle-ice-sdpfrag" as specified in [RFC8840], which carries the
sion as per <xref section="8.8.3" sectionFormat="of" target="RFC9110"/>, being < relevant ICE information.
bcp14>OPTIONAL</bcp14> otherwise. The initial value of the entity-tag identifyin -->
g the initial ICE session <bcp14>MUST</bcp14> be returned in an ETag header fiel
d in the "201 Created" response to the initial POST request to the WHIP endpoint <!-- [rfced] Please review "If the HTTP PATCH to the WHIP session". Should
.</t> this be updated as shown below? The previous sentence uses "WHIP session URL".
<t>WHIP clients <bcp14>SHOULD NOT</bcp14> use entity-tag validation wh
en matching a specific ICE session is not required, such as for example when ini Original:
tiating a DELETE request to terminate a session. WHIP sessions <bcp14>MUST</bcp1 If the HTTP PATCH to the WHIP session has a content
4> ignore any entity-tag value sent by the WHIP client when ICE session matching type different than "application/trickle-ice-sdpfrag" or the SDP
is not required, as in the HTTP DELETE request.</t> fragment is malformed, the WHIP session MUST reject the HTTP PATCH
<t>Missing or outdated ETags in the PATCH requests from WHIP clients w with an appropiate 4XX error response.
ill be answered by WHIP sessions as per <xref section="13.1.1" sectionFormat="of
" target="RFC9110"/> and <xref section="3" sectionFormat="of" target="RFC6585"/> Perhaps:
, with a "428 Precondition Required" response for a missing entity tag, and a "4 If the HTTP PATCH request sent to the WHIP session URL has a content
12 Precondition Failed" response for a non-matching entity tag.</t> type different than "application/trickle-ice-sdpfrag" or the SDP
fragment is malformed, the WHIP session MUST reject the HTTP PATCH
with an appropriate 4xx error response.
-->
<t>The WHIP client <bcp14>MAY</bcp14> perform Trickle ICE or ICE
restarts by sending an HTTP PATCH request as per <xref
target="RFC5789"/> to the WHIP session URL, with a body containing
an SDP fragment with media type "application/trickle-ice-sdpfrag" as
specified in <xref target="RFC8840"/> carrying the relevant ICE
information. If the HTTP PATCH to the WHIP session 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 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>
<!-- [rfced] May we update "being OPTIONAL otherwise" at the end of this
sentence as follows to improve clarity?
Original:
Consequently, as those HTTP PATCH requests may be received
out-of-order by the WHIP session, if WHIP session supports ICE
restarts, it MUST generate a unique strong entity-tag identifying the
ICE session as per Section 8.8.3 of [RFC9110], being OPTIONAL
otherwise.
Perhaps:
Consequently, those HTTP PATCH requests may be received
out of order by the WHIP session. Thus, if WHIP session supports ICE
restarts, it MUST generate a unique strong entity-tag identifying the
ICE session as per Section 8.8.3 of [RFC9110];
if the WHIP session does not support ICE restarts, this is OPTIONAL.
-->
<t>The WHIP client <bcp14>MAY</bcp14> send overlapping HTTP PATCH
requests to one WHIP session. Consequently, those HTTP PATCH
requests may be received out of order by the WHIP session. Thus, if th
e 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, for example, whe
n
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 and a "412 Precondition
Failed" response for a non-matching entity-tag.</t>
</section> </section>
<section anchor="trickle-ice"> <section anchor="trickle-ice">
<name>Trickle ICE</name> <name>Trickle ICE</name>
<t>Depending on the Trickle ICE support on the WHIP client, the initia
l offer by the WHIP client <bcp14>MAY</bcp14> be sent after the full ICE gatheri <t>Depending on the Trickle ICE support on the WHIP client, the
ng is complete with the full list of ICE candidates, or it <bcp14>MAY</bcp14> on initial offer by the WHIP client <bcp14>MAY</bcp14> be sent after
ly contain local candidates (or even an empty list of candidates) as per <xref t the full ICE gathering is complete with the full list of ICE
arget="RFC8845"/>. For the purpose of reducing setup times, when using Trickle I candidates, or it <bcp14>MAY</bcp14> only contain local candidates
CE the WHIP client <bcp14>SHOULD</bcp14> send the SDP offer as soon as possible, (or even an empty list of candidates) as per <xref
containing either locally gathered ICE candidates or an empty list of candidate target="RFC8845"/>. For the purpose of reducing setup times, when
s.</t> using Trickle ICE, the WHIP client <bcp14>SHOULD</bcp14> send the SDP
<t>In order to simplify the protocol, the WHIP session cannot signal a offer (containing either locally gathered ICE
dditional ICE candidates to the WHIP client after the SDP answer has been sent. candidates or an empty list of candidates) as soon as possible.</t>
The WHIP endpoint <bcp14>SHALL</bcp14> gather all the ICE candidates for the med <t>In order to simplify the protocol, the WHIP session cannot signal
ia server before responding to the client request and the SDP answer <bcp14>SHAL additional ICE candidates to the WHIP client after the SDP answer
L</bcp14> contain the full list of ICE candidates of the media server.</t> has been sent. The WHIP endpoint <bcp14>SHALL</bcp14> gather all the
<t>As the WHIP client needs to know the WHIP session URL associated wi ICE candidates for the media server before responding to the client
th the ICE session in order to send a PATCH request containing new ICE candidate request, and the SDP answer <bcp14>SHALL</bcp14> contain the full
s, it <bcp14>MUST</bcp14> wait and buffer any gathered candidates until the "201 list of ICE candidates of the media server.</t>
Created" HTTP response to the initial POST request is received.
In order to lower the HTTP traffic and processing time required the WHIP client <t>As the WHIP client needs to know the WHIP session URL associated
<bcp14>SHOULD</bcp14> send a single aggregated HTTP PATCH request with all the b with the ICE session in order to send a PATCH request containing new
uffered ICE candidates once the response is received. ICE candidates, it <bcp14>MUST</bcp14> wait and buffer any gathered
Additionally, if ICE restarts are supported by the WHIP session, the WHIP client candidates until the "201 Created" HTTP response to the initial POST
needs to know the entity-tag associated with the ICE session in order to send a request is received. In order to reduce the HTTP traffic and
PATCH request containing new ICE candidates, so it <bcp14>MUST</bcp14> also wai processing time required, the WHIP client <bcp14>SHOULD</bcp14> send
t and buffer any gathered candidates until it receives the HTTP response with th a single aggregated HTTP PATCH request with all the buffered ICE
e new entity-tag value to the last PATCH request performing an ICE restart.</t> candidates once the response is received. Additionally, if ICE
<t>WHIP clients generating the HTTP PATCH body with the SDP fragment a restarts are supported by the WHIP session, the WHIP client needs to
nd its subsequent processing by WHIP sessions <bcp14>MUST</bcp14> follow to the know the entity-tag associated with the ICE session in order to send
guidelines defined in <xref section="4.4" sectionFormat="of" target="RFC8840"/> a PATCH request containing new ICE candidates; thus, it
with the following considerations:</t> <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 the guidelines defined in <xref section="4.4"
sectionFormat="of" target="RFC8840"/> with the following
considerations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>As per <xref target="RFC9429"/>, only m-sections not marked as <t>As per <xref target="RFC9429"/>, only "m=" sections not marked
bundle-only can gather ICE candidates, so given that the "max-bundle" policy is as bundle-only can gather ICE candidates, so given that the
being used, the SDP fragment will contain only the offerer-tagged m-line of the "max-bundle" policy is being used, the SDP fragment will contain
bundle group.</t> only the offerer-tagged "m=" line of the bundle group.</t>
</li> </li>
<li> <li>
<t>The WHIP client <bcp14>MAY</bcp14> exclude ICE candidates from <t>The WHIP client <bcp14>MAY</bcp14> exclude ICE candidates
the HTTP PATCH body if they have already been confirmed by the WHIP session with from the HTTP PATCH body if they have already been confirmed by
a successful HTTP response to a previous HTTP PATCH request.</t> the WHIP session with a successful HTTP response to a previous
HTTP PATCH request.</t>
</li> </li>
</ul> </ul>
<t>WHIP sessions and clients that support Trickle ICE <bcp14>MUST</bcp <t>WHIP sessions and clients that support Trickle ICE
14> make use of entity-tags and conditional requests as explained in <xref targe <bcp14>MUST</bcp14> make use of entity-tags and conditional requests
t="http-patch-usage"/>.</t> as explained in <xref target="http-patch-usage"/>.</t>
<t>When a WHIP session receives a PATCH request that adds new ICE cand <t>When a WHIP session receives a PATCH request that adds new ICE
idates without performing an ICE restart, it <bcp14>MUST</bcp14> return a "204 N candidates without performing an ICE restart, it <bcp14>MUST</bcp14>
o Content" response without a body and <bcp14>MUST NOT</bcp14> include an ETag h return a "204 No Content" response without a body and <bcp14>MUST
eader in the response. If the WHIP session does not support a candidate transpor NOT</bcp14> include an ETag header in the response. If the WHIP
t or is not able to resolve the connection address, it <bcp14>MUST</bcp14> silen session does not support a candidate transport or is not able to
tly discard the candidate and continue processing the rest of the request normal resolve the connection address, it <bcp14>MUST</bcp14> silently
ly.</t> discard the candidate and continue processing the rest of the
request normally.</t>
<!-- [rfced] If no objections, we will move the following sentences to appear
before Figures 3 and 5, respectively, as the text introduces the figures.
Original:
Figure 3 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.
...
Figure 5 illustrates the Link headers included in a 201 Created
response, providing the ICE server URLs and associated credentials.
-->
<figure anchor="trickle-ice-example"> <figure anchor="trickle-ice-example">
<name>Example of a Trickle ICE request and response</name> <name>Example of a Trickle ICE Request and Response</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
PATCH /session/id HTTP/1.1 PATCH /session/id HTTP/1.1
Host: whip.example.com Host: whip.example.com
If-Match: "xyzzy" If-Match: "xyzzy"
Content-Type: application/trickle-ice-sdpfrag Content-Type: application/trickle-ice-sdpfrag
Content-Length: 576 Content-Length: 576
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0 a=mid:0
a=ice-ufrag:EsAw a=ice-ufrag:EsAw
a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1 a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1
a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host generation 0 uf rag EsAw network-id 1 a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host generation 0 uf rag 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: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 gener ation 0 ufrag EsAw network-id 1 a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype active gener ation 0 ufrag EsAw network-id 1
a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host tcptype active g eneration 0 ufrag EsAw network-id 2 a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host tcptype active g eneration 0 ufrag EsAw network-id 2
a=end-of-candidates a=end-of-candidates
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="trickle-ice-example"/> shows an example of the Trickl
e ICE procedure where the WHIP client sends a PATCH request with updated ICE can <t><xref target="trickle-ice-example"/> shows an example of the
didate information and receives a successful response from the WHIP session.</t> 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>
<section anchor="ice-restarts"> <section anchor="ice-restarts">
<name>ICE Restarts</name> <name>ICE Restarts</name>
<t>As defined in <xref target="RFC8839"/>, when an ICE restart occurs, <t>As defined in <xref target="RFC8839"/>, when an ICE restart
a new SDP offer/answer exchange is triggered. However, as WHIP does not support occurs, a new SDP offer/answer exchange is triggered. However, as
renegotiation of non-ICE related SDP information, a WHIP client will not send a WHIP does not support renegotiation of non-ICE-related SDP
new offer when an ICE restart occurs. Instead, the WHIP client and WHIP session information, a WHIP client will not send a new offer when an ICE
will only exchange the relevant ICE information via an HTTP PATCH request as de restart occurs. Instead, the WHIP client and WHIP session will only
fined in <xref target="http-patch-usage"/> and <bcp14>MUST</bcp14> assume that t exchange the relevant ICE information via an HTTP PATCH request as
he previously negotiated non-ICE related SDP information still apply after the I defined in <xref target="http-patch-usage"/> and <bcp14>MUST</bcp14>
CE restart.</t> assume that the previously negotiated non-ICE-related SDP
<t>When performing an ICE restart, the WHIP client <bcp14>MUST</bcp14> information still applies after the ICE restart.</t>
include the updated "ice-pwd" and "ice-ufrag" in the SDP fragment of the HTTP P <t>When performing an ICE restart, the WHIP client
ATCH request body as well as the new set of gathered ICE candidates as defined i <bcp14>MUST</bcp14> include the updated "ice-pwd" and "ice-ufrag" in
n <xref target="RFC8840"/>. the SDP fragment of the HTTP PATCH request body as well as the new
Similar what is defined in <xref target="trickle-ice"/>, as per <xref target="RF set of gathered ICE candidates as defined in <xref
C9429"/> only m-sections not marked as bundle-only can gather ICE candidates, so target="RFC8840"/>. Similar to what is defined in <xref
given that the "max-bundle" policy is being used, the SDP fragment will contain target="trickle-ice"/>, as per <xref target="RFC9429"/>, only
only the offerer-tagged m-line of the bundle group. "m=" sections not marked as bundle-only can gather ICE candidates, so
A WHIP client sending a PATCH request for performing ICE restart <bcp14>MUST</bc given that the "max-bundle" policy is being used, the SDP fragment
p14> contain an "If-Match" header field with a field-value "*" as per <xref sect will contain only the offerer-tagged "m=" line of the bundle group. A
ion="13.1.1" sectionFormat="of" target="RFC9110"/>.</t> WHIP client sending a PATCH request for performing ICE restart
<t><xref target="RFC8840"/> states that an agent <bcp14>MUST</bcp14> d <bcp14>MUST</bcp14> contain an "If-Match" header field with a
iscard any received requests containing "ice-pwd" and "ice-ufrag" attributes tha field-value of "*" as per <xref section="13.1.1" sectionFormat="of"
t do not match those of the current ICE Negotiation Session, however, any WHIP s target="RFC9110"/>.</t>
ession receiving an updated "ice-pwd" and "ice-ufrag" attributes <bcp14>MUST</bc <t><xref target="RFC8840"/> states that an agent <bcp14>MUST</bcp14>
p14> consider the request as performing an ICE restart instead and, if supported discard any received requests containing "ice-pwd" and "ice-ufrag"
, <bcp14>SHALL</bcp14> return a "200 OK" with an "application/trickle-ice-sdpfra attributes that do not match those of the current ICE Negotiation
g" body containing the new ICE username fragment and password and a new set of I Session. However, any WHIP session receiving updated "ice-pwd"
CE candidates for the WHIP session. Also, the "200 OK" response for a successful and "ice-ufrag" attributes <bcp14>MUST</bcp14> consider the request
ICE restart <bcp14>MUST</bcp14> contain the new entity-tag corresponding to the as performing an ICE restart instead and, if supported,
new ICE session in an ETag response header field and <bcp14>MAY</bcp14> contain <bcp14>SHALL</bcp14> return a "200 OK" with an
a new set of ICE candidates for the media server.</t> "application/trickle-ice-sdpfrag" body containing the new ICE
<t>As defined in <xref section="4.4.1.1.1" sectionFormat="of" target=" username fragment and password and a new set of ICE candidates for
RFC8839"/> the set of candidates after an ICE restart may include some, none, or the WHIP session. Also, the "200 OK" response for a successful ICE
all of the previous candidates for that data stream and may include a totally n restart <bcp14>MUST</bcp14> contain the new entity-tag corresponding
ew set of candidates. So after performing a successful ICE restart, both the WHI to the new ICE session in an ETag response header field and
P client and the WHIP session <bcp14>MUST</bcp14> replace the previous set of re <bcp14>MAY</bcp14> contain a new set of ICE candidates for the media
mote candidates with the new set exchanged in the HTTP PATCH request and respons server.</t>
e, discarding any remote ICE candidate not present on the new set. Both the WHIP <t>As defined in <xref section="4.4.1.1.1" sectionFormat="of"
client and the WHIP session <bcp14>MUST</bcp14> ensure that the HTTP PATCH requ target="RFC8839"/>, the set of candidates after an ICE restart may
ests and response bodies include the same 'ice-options,' 'ice-pacing,' and 'ice- include some, none, or all of the previous candidates for that data
lite' attributes as those used in the SDP offer or answer.</t> stream and may include a totally new set of candidates. Therefore, aft
<t>If the ICE restart request cannot be satisfied by the WHIP session, er
the resource <bcp14>MUST</bcp14> return an appropriate HTTP error code and <bcp performing a successful ICE restart, both the WHIP client and the
14>MUST NOT</bcp14> terminate the session immediately and keep the existing ICE WHIP session <bcp14>MUST</bcp14> replace the previous set of remote
session. The WHIP client <bcp14>MAY</bcp14> retry performing a new ICE restart o candidates with the new set exchanged in the HTTP PATCH request and
r terminate the session by issuing an HTTP DELETE request instead. In any case, response, discarding any remote ICE candidate not present on the new
the session <bcp14>MUST</bcp14> be terminated if the ICE consent expires as a co set. Both the WHIP client and the WHIP session <bcp14>MUST</bcp14>
nsequence of the failed ICE restart as per <xref section="5.1" sectionFormat="of ensure that the HTTP PATCH request and response bodies include the
" target="RFC7675"/>.</t> same "ice-options," "ice-pacing," and "ice-lite" attributes as those
<t>In case of unstable network conditions, the ICE restart HTTP PATCH used in the SDP offer or answer.</t>
requests and responses might be received out of order. In order to mitigate this <t>If the ICE restart request cannot be satisfied by the WHIP
scenario, when the client performs an ICE restart, it <bcp14>MUST</bcp14> disca session, the resource <bcp14>MUST</bcp14> return an appropriate HTTP
rd any previous ICE username and passwords fragments and ignore any further HTTP error code and <bcp14>MUST NOT</bcp14> terminate the session
PATCH response received from a pending HTTP PATCH request. WHIP clients <bcp14> immediately and keep the existing ICE session. The WHIP client
MUST</bcp14> apply only the ICE information received in the response to the last <bcp14>MAY</bcp14> retry performing a new ICE restart or terminate
sent request. If there is a mismatch between the ICE information at the WHIP cl the session by issuing an HTTP DELETE request instead. In any case,
ient and at the WHIP session (because of an out-of-order request), the STUN requ the session <bcp14>MUST</bcp14> be terminated if the ICE consent
ests will contain invalid ICE information and will be dropped by the receiving s expires as a consequence of the failed ICE restart as per <xref
ide. If this situation is detected by the WHIP client, it <bcp14>MUST</bcp14> se section="5.1" sectionFormat="of" target="RFC7675"/>.</t>
nd a new ICE restart request to the server.</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 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 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>
<figure anchor="trickle-restart-example"> <figure anchor="trickle-restart-example">
<name>Example of an ICE restart request and response</name> <name>Example of an ICE Restart Request and Response</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
PATCH /session/id HTTP/1.1 PATCH /session/id HTTP/1.1
Host: whip.example.com Host: whip.example.com
If-Match: "*" If-Match: "*"
Content-Type: application/trickle-ice-sdpfrag Content-Type: application/trickle-ice-sdpfrag
Content-Length: 82 Content-Length: 82
a=ice-options:trickle ice2 a=ice-options:trickle ice2
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0 a=mid:0
skipping to change at line 363 skipping to change at line 848
a=ice-lite a=ice-lite
a=ice-options:trickle ice2 a=ice-options:trickle ice2
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0 a=mid:0
a=ice-ufrag:289b31b754eaa438 a=ice-ufrag:289b31b754eaa438
a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a
a=candidate:1 1 udp 2130706431 198.51.100.1 39132 typ host a=candidate:1 1 udp 2130706431 198.51.100.1 39132 typ host
a=end-of-candidates a=end-of-candidates
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="trickle-ice-example"/> demonstrates a Trickle ICE res
tart procedure example. The WHIP client sends a PATCH request containing updated <!-- [rfced] We have a few questions about this text:
ICE information, including a new ufrag and password, along with newly gathered
ICE candidates. In response, the WHIP session provides ICE information for the s Original:
ession after the ICE restart, including the updated ufrag and password, as well Figure 3 demonstrates a Trickle ICE restart procedure example. The
as the previous ICE candidate.</t> 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.
a) We updated "Figure 3" to "Figure 4". This text comes immediately after
Figure 4. If no objections, we will also move this text to appear before
Figure 4, as it introduces the figure.
b) Is 'ufrag and password' correct, or should these be updated to '"ice-pwd"
and "ice-ufrag"' (used earlier in the same section)?
-->
<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 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> </section>
<section anchor="webrtc-constraints"> <section anchor="webrtc-constraints">
<name>WebRTC constraints</name> <name>WebRTC Constraints</name>
<t>To simplify the implementation of WHIP in both clients and media serv <t>To simplify the implementation of WHIP in both clients and media
ers, WHIP introduces specific restrictions on WebRTC usage. The following subsec servers, WHIP introduces specific restrictions on WebRTC usage. The
tions will explain these restrictions in detail:</t> following subsections will explain these restrictions in detail.</t>
<section anchor="sdp-bundle"> <section anchor="sdp-bundle">
<name>SDP Bundle</name> <name>SDP Bundle</name>
<t>Both the WHIP client and the WHIP endpoint <bcp14>SHALL</bcp14> sup <t>Both the WHIP client and the WHIP endpoint <bcp14>SHALL</bcp14>
port <xref target="RFC9143"/> and use "max-bundle" policy as defined in <xref ta support <xref target="RFC9143"/> and use the "max-bundle" policy as
rget="RFC9429"/>. The WHIP client and the media server <bcp14>MUST</bcp14> suppo defined in <xref target="RFC9429"/>. The WHIP client and the media
rt multiplexed media associated with the BUNDLE group as per <xref section="9" s server <bcp14>MUST</bcp14> support multiplexed media associated with
ectionFormat="of" target="RFC9143"/>. In addition, per <xref target="RFC9143"/> the BUNDLE group as per <xref section="9" sectionFormat="of"
the WHIP client and media server <bcp14>SHALL</bcp14> use RTP/RTCP multiplexing target="RFC9143"/>. In addition, per <xref target="RFC9143"/>, the
for all bundled media. In order to reduce the network resources required at the WHIP client and media server <bcp14>SHALL</bcp14> use RTP/RTCP
media server, both The WHIP client and WHIP endpoints <bcp14>MUST</bcp14> includ multiplexing for all bundled media. In order to reduce the network
e the "rtcp-mux-only" attribute in each bundled "m=" sections as per <xref secti resources required at the media server, both the WHIP client and
on="3" sectionFormat="of" target="RFC8858"/>.</t> WHIP endpoints <bcp14>MUST</bcp14> include the "rtcp-mux-only"
attribute in each bundled "m=" section as per <xref section="3"
sectionFormat="of" target="RFC8858"/>.</t>
</section> </section>
<section anchor="single-mediastream"> <section anchor="single-mediastream">
<name>Single MediaStream</name> <name>Single MediaStream</name>
<t>WHIP only supports a single MediaStream as defined in <xref target=
"RFC8830"/> and therefore all "m=" sections <bcp14>MUST</bcp14> contain a "msid" <!-- [rfced] Is "proving" the correct word choice here? Would "providing" or
attribute with the same value. The MediaStream <bcp14>MUST</bcp14> contain at l "that provides" be better? (Note that this sentence appears in both
east one MediaStreamTrack of any media kind and it <bcp14>MUST NOT</bcp14> have Section 4.4.2 and 4.4.3.)
two or more than MediaStreamTracks for the same media (audio or video). However,
it would be possible for future revisions of this spec to allow more than a sin Original:
gle MediaStream or MediaStreamTrack of each media kind, so in order to ensure fo The WHIP endpoint MAY also return a problem statement as
rward compatibility, if the number of audio and or video MediaStreamTracks or nu recommended in Section 4.1 proving further error details about the
mber of MediaStreams are not supported by the WHIP endpoint, it <bcp14>MUST</bcp failed request.
14> reject the HTTP POST request with an "422 Unprocessable Content" or "400 Bad
Request" error response. The WHIP endpoint <bcp14>MAY</bcp14> also return a pro Perhaps:
blem statement as recommended in <xref target="http-usage"/> proving further err The WHIP endpoint MAY also return a problem statement that provides
or details about the failed request.</t> further error details about the failed request, as
recommended in Section 4.1.
-->
<t>WHIP only supports a single MediaStream as defined in <xref
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, and it <bcp14>MUST NOT</bcp14> have two or more
MediaStreamTracks for the same media (audio or video). However, it
would be possible for future revisions of this specification to allow
more
than a single MediaStream or MediaStreamTrack of each media
kind. Therefore, in order to ensure forward compatibility, if the
number of audio 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 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 further error
details about the failed request.</t>
</section> </section>
<!-- [rfced] We have a few questions about the sentence below.
a) The first part of the sentence includes "The WHIP endpoint SHOULD NOT
reject". Should "but reject" in the second part of the sentence be updated to
"but SHOULD reject" (i.e., include SHOULD)?
b) Is a word missing in the phrase 'in case there is any error processing the
"m=" section'?
Original:
The WHIP endpoint SHOULD NOT reject individual "m=" sections as per
Section 5.3.1 of [RFC9429] in case there is any error processing the
"m=" section, but reject the HTTP POST request with an "422
Unprocessable Content" or "400 Bad Request" error response to prevent
having partially successful ingest sessions which can be misleading
to end users.
Perhaps:
The WHIP endpoint SHOULD NOT reject individual "m=" sections as per
Section 5.3.1 of [RFC9429] in case there is any error processing of the
"m=" section, but it SHOULD reject the HTTP POST request with a
"422 Unprocessable Content" or "400 Bad Request" error response to
prevent having partially successful ingest sessions, which can be
misleading to end users.
-->
<section anchor="no-partially-successful-answers"> <section anchor="no-partially-successful-answers">
<name>No partially successful answers</name> <name>No Partially Successful Answers</name>
<t>The WHIP endpoint <bcp14>SHOULD NOT</bcp14> reject individual "m=" <t>The WHIP endpoint <bcp14>SHOULD NOT</bcp14> reject individual
sections as per <xref section="5.3.1" sectionFormat="of" target="RFC9429"/> in c "m=" sections as per <xref section="5.3.1" sectionFormat="of"
ase there is any error processing the "m=" section, but reject the HTTP POST req target="RFC9429"/> in case there is any error processing the "m="
uest with an "422 Unprocessable Content" or "400 Bad Request" error response to section, but reject the HTTP POST request with a "422 Unprocessable
prevent having partially successful ingest sessions which can be misleading to e Content" or "400 Bad Request" error response to prevent having
nd users. The WHIP endpoint <bcp14>MAY</bcp14> also return a problem statement a partially successful ingest sessions, which can be misleading to end
s recommended in <xref target="http-usage"/> proving further error details about users. The WHIP endpoint <bcp14>MAY</bcp14> also return a problem
the failed request.</t> statement as recommended in <xref target="http-usage"/> proving
further error details about the failed request.</t>
</section> </section>
<section anchor="dtls-setup-role-and-sdp-setup-attribute"> <section anchor="dtls-setup-role-and-sdp-setup-attribute">
<name>DTLS setup role and SDP "setup" attribute</name> <name>DTLS Setup Role and SDP "setup" Attribute</name>
<t>When a WHIP client sends an SDP offer, it <bcp14>SHOULD</bcp14> ins <t>When a WHIP client sends an SDP offer, it <bcp14>SHOULD</bcp14>
ert an SDP "setup" attribute with an "actpass" attribute value, as defined in <x insert an SDP "setup" attribute with an "actpass" attribute value,
ref target="RFC8842"/>. However, if the WHIP client only implements the DTLS cli as defined in <xref target="RFC8842"/>. However, if the WHIP client
ent role, it <bcp14>MAY</bcp14> use an SDP "setup" attribute with an "active" at only implements the DTLS client role, it <bcp14>MAY</bcp14> use an
tribute value. If the WHIP endpoint does not support an SDP offer with an SDP "s SDP "setup" attribute with an "active" attribute value. If the WHIP
etup" attribute with an "active" attribute value, it <bcp14>SHOULD</bcp14> rejec endpoint does not support an SDP offer with an SDP "setup" attribute
t the request with an "422 Unprocessable Content" or "400 Bad Request" error res with an "active" attribute value, it <bcp14>SHOULD</bcp14> reject
ponse.</t> the request with a "422 Unprocessable Content" or "400 Bad Request"
<t>NOTE: <xref target="RFC8842"/> defines that the offerer must insert error response.</t>
an SDP "setup" attribute with an "actpass" attribute value. However, the WHIP c <t>NOTE: <xref target="RFC8842"/> defines that the offerer
lient will always communicate with a media server that is expected to support th must insert an SDP "setup" attribute with an "actpass" attribute
e DTLS server role, in which case the client might choose to only implement supp value. However, the WHIP client will always communicate with a media
ort for the DTLS client role.</t> 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>
<section anchor="trickle-ice-and-ice-restarts"> <section anchor="trickle-ice-and-ice-restarts">
<name>Trickle ICE and ICE restarts</name> <name>Trickle ICE and ICE Restarts</name>
<t>The media server <bcp14>SHOULD</bcp14> support full ICE, unless it <t>The media server <bcp14>SHOULD</bcp14> support full ICE, unless
is connected to the Internet with an IP address that is accessible by each WHIP it is connected to the Internet with an IP address that is
client that is authorized to use it, in which case it <bcp14>MAY</bcp14> support accessible by each WHIP client that is authorized to use it, in
only ICE lite. The WHIP client <bcp14>MUST</bcp14> implement and use full ICE.< which case it <bcp14>MAY</bcp14> support only ICE lite. The WHIP
/t> client <bcp14>MUST</bcp14> implement and use full ICE.</t>
<t>Trickle ICE and ICE restarts support is <bcp14>OPTIONAL</bcp14> for <t>Trickle ICE and ICE restart support is <bcp14>OPTIONAL</bcp14>
both the WHIP clients and media servers as explained in <xref target="ice-suppo for both the WHIP clients and media servers as explained in <xref
rt"/>.</t> target="ice-support"/>.</t>
</section> </section>
</section> </section>
<section anchor="load-balancing-and-redirections"> <section anchor="load-balancing-and-redirections">
<name>Load balancing and redirections</name> <name>Load Balancing and Redirections</name>
<t>WHIP endpoints and media servers might not be colocated on the same s <t>WHIP endpoints and media servers might not be colocated on the same
erver, so it is possible to load balance incoming requests to different media se server, so it is possible to load balance incoming requests to
rvers.</t> different media servers.</t>
<t>WHIP clients <bcp14>SHALL</bcp14> support HTTP redirections as per <x
ref section="15.4" sectionFormat="of" target="RFC9110"/>. In order to avoid POST <!-- [rfced] Most status codes mentioned in this document include a
requests to be redirected as GET requests, status codes 301 and 302 <bcp14>MUST description in addition to the number. Would you like to add that for 301
NOT</bcp14> be used and the preferred method for performing load balancing is v and 302 below? If so, please confirm that the "301 Moved Permanently" and
ia the "307 Temporary Redirect" response status code as described in <xref secti "302 Found" are correct.
on="15.4.8" sectionFormat="of" target="RFC9110"/>. Redirections are not required
to be supported for the PATCH and DELETE requests.</t> Original:
<t>In case of high load, the WHIP endpoints <bcp14>MAY</bcp14> return a In order to avoid POST requests to be redirected as GET
"503 Service Unavailable" response indicating that the server is currently unabl requests, status codes 301 and 302 MUST NOT be used and the preferred
e to handle the request due to a temporary overload or scheduled maintenance as method for performing load balancing is via the "307 Temporary
described in <xref section="15.6.4" sectionFormat="of" target="RFC9110"/>, which Redirect" response status code as described in Section 15.4.8 of
will likely be alleviated after some delay. The WHIP endpoint might send a Retr [RFC9110].
y-After header field indicating the minimum time that the user agent ought to wa
it before making a follow-up request as described in <xref section="10.2.3" sect Perhaps:
ionFormat="of" target="RFC9110"/>.</t> In order to avoid POST requests being redirected as GET
requests, status codes "301 Moved Permanently" and "302 Found" MUST NOT be us
ed;
the preferred method for performing load balancing is via the "307 Temporary
Redirect" response status code as described in Section 15.4.8 of
[RFC9110].
-->
<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 being redirected as GET requests, status codes
301 and 302 <bcp14>MUST NOT</bcp14> be 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>
<section anchor="stunturn-server-configuration"> <section anchor="stunturn-server-configuration">
<name>STUN/TURN server configuration</name> <name>STUN/TURN Server Configuration</name>
<t>The WHIP endpoint <bcp14>MAY</bcp14> return STUN/TURN server configur ation URLs and credentials usable by the client in the "201 Created" response to the HTTP POST request to the WHIP endpoint URL.</t> <t>The WHIP endpoint <bcp14>MAY</bcp14> return STUN/TURN server configur ation 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 " header field <xref target="RFC8288"/> with a "rel" attribute value of "ice-ser ver". 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> <t>A reference to each STUN/TURN server will be returned using the "Link " header field <xref target="RFC8288"/> with a "rel" attribute value of "ice-ser ver". 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"> <ul spacing="normal">
<li> <li>username: If the Link header field represents a Traversal
<t>username: If the Link header field represents a TURN server, and Using Relays around NAT (TURN) server and the "credential-type" attr
credential-type is "password", then this attribute specifies the username to use ibute has a
with that TURN server.</t> "password" value, then this attribute specifies the username to use
</li> with
<li> that TURN server.</li>
<t>credential: If the "credential-type" attribute is missing or has <li>credential: If the "credential-type" attribute is missing or
a "password" value, the credential attribute represents a long-term authenticati has a "password" value, this attribute represents a
on password, as described in <xref section="9.2" sectionFormat="of" target="RFC8 long-term authentication password, as described in <xref
489"/>.</t> section="9.2" sectionFormat="of" target="RFC8489"/>.</li>
</li> <li>credential-type: If the Link header field represents a TURN
<li> server, then this attribute specifies how the "credential" attribute
<t>credential-type: If the Link header field represents a TURN serve value should be used when that TURN server requests
r, then this attribute specifies how the credential attribute value should be us authorization. The default value if the attribute is not present
ed when that TURN server requests authorization. The default value if the attrib is "password".</li>
ute is not present is "password".</t>
</li>
</ul> </ul>
<figure anchor="stun-server-example"> <figure anchor="stun-server-example">
<name>Example of a STUN/TURN servers configuration</name> <name>Example of a STUN/TURN Server's Configuration</name>
<artwork><![CDATA[ <sourcecode><![CDATA[
Link: <stun:stun.example.net>; rel="ice-server" Link: <stun:stun.example.net>; rel="ice-server"
Link: <turn:turn.example.net?transport=udp>; rel="ice-server"; Link: <turn:turn.example.net?transport=udp>; rel="ice-server";
username="user"; credential="myPassword"; credential-type="password" username="user"; credential="myPassword"; credential-type="password"
Link: <turn:turn.example.net?transport=tcp>; rel="ice-server"; Link: <turn:turn.example.net?transport=tcp>; rel="ice-server";
username="user"; credential="myPassword"; credential-type="password" username="user"; credential="myPassword"; credential-type="password"
Link: <turns:turn.example.net?transport=tcp>; rel="ice-server"; Link: <turns:turn.example.net?transport=tcp>; rel="ice-server";
username="user"; credential="myPassword"; credential-type="password" username="user"; credential="myPassword"; credential-type="password"
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="stun-server-example"/> illustrates the Link headers inc <t><xref target="stun-server-example"/> illustrates the Link headers inc
luded in a 201 Created response, providing the ICE server URLs and associated cr luded in a "201 Created" response, providing the ICE server URLs and associated
edentials.</t> credentials.</t>
<t>NOTE: The naming of both the "rel" attribute value of "ice-server" an
d the target attributes follows the one used on the W3C WebRTC recommendation <x <t>NOTE: The naming of both the "rel" attribute value of
ref target="W3C.REC-webrtc-20210126"/> RTCConfiguration dictionary in section 4. "ice-server" and the target attributes follows that used in the
2.1. "rel" attribute value of "ice-server" is not prepended with the "urn:ietf:p RTCConfiguration dictionary in Section 4.2.1 of the W3C WebRTC
arams:whip:" so it can be reused by other specifications which may use this mech recommendation (see <xref target="W3C.REC-webrtc-20210126"/>). The "rel"
anism to configure the usage of STUN/TURN servers.</t> attribute value of "ice-server" is not prepended with the
<t>NOTE: Depending on the ICE Agent implementation, the WHIP client may "urn:ietf:params:whip:" so it can be reused by other specifications,
need to call the setConfiguration method before calling the setLocalDescription which may use this mechanism to configure the usage of STUN/TURN
method with the local SDP offer in order to avoid having to perform an ICE resta servers.</t>
rt for applying the updated STUN/TURN server configuration on the next ICE gathe <t>NOTE: Depending on the ICE agent implementation, the WHIP
ring phase.</t> client may need to call the setConfiguration method before calling the
<t>There are some WebRTC implementations that do not support updating th setLocalDescription method with the local SDP offer in order
e STUN/TURN server configuration after the local offer has been created as speci to avoid having to perform an ICE restart for applying the updated
fied in <xref section="4.1.18" sectionFormat="of" target="RFC9429"/>. In order t STUN/TURN server configuration on the next ICE gathering
o support these clients, the WHIP endpoint <bcp14>MAY</bcp14> also include the S phase.</t>
TUN/TURN server configuration on the responses to OPTIONS request sent to the WH
IP endpoint URL before the POST request is sent. However, this method is <bcp14> <t>There are some WebRTC implementations that do not support updating
NOT RECOMMENDED</bcp14> to be used by the WHIP clients and, if supported by the the STUN/TURN server configuration after the local offer has been
underlying WHIP client's webrtc implementation, the WHIP client <bcp14>SHOULD</b created as specified in <xref section="4.1.18" sectionFormat="of"
cp14> wait for the information to be returned by the WHIP endpoint on the respon target="RFC9429"/>. In order to support these clients, the WHIP
se of the HTTP POST request instead.</t> endpoint <bcp14>MAY</bcp14> also include the STUN/TURN server
<t>The generation of the TURN server credentials may require performing configuration in the responses to OPTIONS requests sent to the WHIP
a request to an external provider, which can both add latency to the OPTIONS req endpoint URL before the POST request is sent. However, this method is
uest processing and increase the processing required to handle that request. In <bcp14>NOT RECOMMENDED</bcp14> to be used by the WHIP clients, and if it
order to prevent this, the WHIP endpoint <bcp14>SHOULD NOT</bcp14> return the ST is
UN/TURN server configuration if the OPTIONS request is a preflight request for C supported by the underlying WHIP client's WebRTC implementation, the
ORS as defined in <xref target="FETCH"/>, that is, if The OPTIONS request does n WHIP client <bcp14>SHOULD</bcp14> wait for the information to be
ot contain an Access-Control-Request-Method with "POST" value and the Access-Con returned by the WHIP endpoint in the response of the HTTP POST request
trol-Request-Headers HTTP header does not contain the "Link" value.</t> instead.</t>
<t>The WHIP clients <bcp14>MAY</bcp14> also support configuring the STUN <t>The generation of the TURN server credentials may require
/TURN server URIs with long term credentials provided by either the broadcasting performing a request to an external provider, which can both add
service or an external TURN provider, overriding the values provided by the WHI latency to the OPTIONS request processing and increase the processing
P endpoint.</t> 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 OPTIONS request
does not contain an Access-Control-Request-Method with a "POST" value
and the Access-Control-Request-Headers HTTP header does not contain
the "Link" value.</t>
<t>The WHIP clients <bcp14>MAY</bcp14> also support configuring the
STUN/TURN server URIs with 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"> <section anchor="congestion-control">
<name>Congestion control</name> <name>Congestion Control</name>
<t><xref target="RFC8836"/> defines the congestion control requirement
s for interactive Real-Time media to be used in WebRTC. These requirements are b <!-- [rfced] FYI - For clarity, we have updated the text starting with
ased on the assumption of the need to provide the data continuously, within a ve "assumption..." as follows. Please review to ensure this does not change
ry limited time window (no more delay than hundreds of milliseconds end-to-end). your intended meaning.
If the latency target is higher, some of the requirements present in RFC8836 co
uld be relaxed to allow more flexible implementations.</t> Original:
These requirements are based
on the assumption of the need to provide the data continuously,
within a very limited time window (no more delay than hundreds of
milliseconds end-to-end).
Current:
These requirements are based
on the assumption that the data needs to be provided continuously,
within a very limited time window (a delay of no more than hundreds
of milliseconds end-to-end).
-->
<t><xref target="RFC8836"/> defines the congestion control
requirements for interactive real-time media to be used in
WebRTC. These requirements are based on the assumption that the data
needs to be provided continuously within a very limited time window
(a delay of no more than hundreds of milliseconds end-to-end). If
the latency target is higher, some of the requirements present in
<xref target="RFC8836"/> could be relaxed to allow more flexible
implementations.</t>
</section> </section>
</section> </section>
<section anchor="authentication-and-authorization"> <section anchor="authentication-and-authorization">
<name>Authentication and authorization</name> <name>Authentication and Authorization</name>
<t>All WHIP endpoints, sessions and clients <bcp14>MUST</bcp14> support <t>All WHIP endpoints, sessions, and clients <bcp14>MUST</bcp14>
HTTP Authentication as per <xref section="11" sectionFormat="of" target="RFC9110 support HTTP authentication as per <xref section="11"
"/> and in order to ensure interoperability, bearer token authentication as defi sectionFormat="of" target="RFC9110"/>. Additionally, in order to
ned in the next section <bcp14>MUST</bcp14> be supported by all WHIP entities. H ensure interoperability, bearer token authentication as defined in the
owever, this does not preclude the support of additional HTTP authentication sch next section <bcp14>MUST</bcp14> be supported by all WHIP
emes as defined in <xref section="11.6" sectionFormat="of" target="RFC9110"/>.</ entities. However, this does not preclude the support of additional
t> HTTP authentication schemes as defined in <xref section="11.6"
sectionFormat="of" target="RFC9110"/>.</t>
<section anchor="bearer-token-authentication"> <section anchor="bearer-token-authentication">
<name>Bearer token authentication</name> <name>Bearer Token Authentication</name>
<t>WHIP endpoints and sessions <bcp14>MAY</bcp14> require the HTTP req
uest to be authenticated using an HTTP Authorization header field with a Bearer <t>WHIP endpoints and sessions <bcp14>MAY</bcp14> require the HTTP
token as specified in <xref section="2.1" sectionFormat="of" target="RFC6750"/>. request to be authenticated using an HTTP Authorization header field
WHIP clients <bcp14>MUST</bcp14> implement this authentication and authorizatio with a bearer token as specified in <xref section="2.1"
n mechanism and send the HTTP Authorization header field in all HTTP requests se sectionFormat="of" target="RFC6750"/>. WHIP clients
nt to either the WHIP endpoint or session except the preflight OPTIONS requests <bcp14>MUST</bcp14> implement this authentication and authorization
for CORS.</t> mechanism and send the HTTP Authorization header field in all HTTP
<t>The nature, syntax, and semantics of the bearer token, as well as h requests sent to either the WHIP endpoint or session (except the
ow to distribute it to the client, is outside the scope of this document. Some e preflight OPTIONS requests for CORS).</t>
xamples of the kind of tokens that could be used are, but are not limited to, JW
T tokens as per <xref target="RFC6750"/> and <xref target="RFC8725"/> or a share <!-- [rfced] We were unable to find either "JWT tokens" or "JSON Web Tokens"
d secret stored on a database. The tokens are typically made available to the en mentioned explicitly in RFC 6750. Are any updates needed to the citation
d user alongside the WHIP endpoint URL and configured on the WHIP clients (simil in the text below?
ar to the way RTMP URLs and Stream Keys are distributed).</t>
<t>WHIP endpoints and sessions could perform the authentication and au Original:
thorization by encoding an authentication token within the URLs for the WHIP end Some examples of the kind of tokens that could be used
points or sessions instead. In case the WHIP client is not configured to use a b are, but are not limited to, JWT tokens as per [RFC6750] and
earer token, the HTTP Authorization header field <bcp14>MUST NOT</bcp14> be sent [RFC8725] or a shared secret stored on a database.
in any request.</t> -->
<t>The nature, syntax, and semantics of the bearer token, as well as
how to distribute it to the client, are outside the scope of this
document. Examples of tokens that could be used
include, but are not limited to, JSON Web Tokens (JWTs) as per <xref
target="RFC6750"/> and <xref target="RFC8725"/> 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 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> </section>
<section anchor="simulcast-and-scalable-video-coding"> <section anchor="simulcast-and-scalable-video-coding">
<name>Simulcast and scalable video coding</name> <name>Simulcast and Scalable Video Coding</name>
<t>Simulcast as per <xref target="RFC8853"/> <bcp14>MAY</bcp14> be suppo <t>Simulcast as per <xref target="RFC8853"/> <bcp14>MAY</bcp14> be
rted by both the media servers and WHIP clients through negotiation in the SDP o supported by both the media servers and WHIP clients through
ffer/answer.</t> negotiation in the SDP offer/answer.</t>
<t>If the client supports simulcast and wants to enable it for ingesting <t>If the client supports simulcast and wants to enable it for
, it <bcp14>MUST</bcp14> negotiate the support in the SDP offer according to the ingesting, it <bcp14>MUST</bcp14> negotiate the support in the SDP
procedures in <xref section="5.3" sectionFormat="of" target="RFC8853"/>. A serv offer according to the procedures in <xref section="5.3"
er accepting a simulcast offer <bcp14>MUST</bcp14> create an answer according to sectionFormat="of" target="RFC8853"/>. A server accepting a simulcast
the procedures in <xref section="5.3.2" sectionFormat="of" target="RFC8853"/>.< offer <bcp14>MUST</bcp14> create an answer according to the procedures
/t> in <xref section="5.3.2" sectionFormat="of" target="RFC8853"/>.</t>
<t>It is possible for both media servers and WHIP clients to support Sca <t>It is possible for both media servers and WHIP clients to support
lable Video Coding (SVC). However, as there is no universal negotiation mechanis Scalable Video Coding (SVC). However, as there is no universal
m in SDP for SVC, the encoder must consider the negotiated codec(s), intended us negotiation mechanism in SDP for SVC, the encoder must consider the
age, and SVC support in available decoders when configuring SVC.</t> negotiated codec(s), intended usage, and SVC support in available
decoders when configuring SVC.</t>
</section> </section>
<section anchor="protocol-extensions"> <section anchor="protocol-extensions">
<name>Protocol extensions</name> <name>Protocol Extensions</name>
<t>In order to support future extensions to be defined for the WHIP prot <t>In order to support future extensions to be defined for the WHIP
ocol, a common procedure for registering and announcing the new extensions is de protocol, a common procedure for registering and announcing the new
fined.</t> extensions is defined.</t>
<t>Protocol extensions supported by the WHIP sessions <bcp14>MUST</bcp14 <t>Protocol extensions supported by the WHIP sessions
> be advertised to the WHIP client in the "201 Created" response to the initial <bcp14>MUST</bcp14> be advertised to the WHIP client in the "201
HTTP POST request sent to the WHIP endpoint. Created" response to the initial HTTP POST request sent to the WHIP
The WHIP endpoint <bcp14>MUST</bcp14> return one "Link" header field for each ex endpoint. The WHIP endpoint <bcp14>MUST</bcp14> return one "Link"
tension that it supports, with the extension "rel" attribute value containing th header field for each extension that it supports, with the extension
e extension URN and the URL for the HTTP resource that will be available for rec "rel" attribute value containing the extension URN and the URL for the
eiving requests related to that extension.</t> HTTP resource that will be available for receiving requests related to
<t>Protocol extensions are optional for both WHIP clients and servers. W that extension.</t>
HIP clients <bcp14>MUST</bcp14> ignore any Link attribute with an unknown "rel" <t>Protocol extensions are optional for both WHIP clients and
attribute value and WHIP sessions <bcp14>MUST NOT</bcp14> require the usage of a servers. WHIP clients <bcp14>MUST</bcp14> ignore any Link attribute
ny extension.</t> with an unknown "rel" attribute value, and WHIP sessions <bcp14>MUST
<t>Each protocol extension <bcp14>MUST</bcp14> register a unique "rel" a NOT</bcp14> require the usage of any extension.</t>
ttribute value at IANA starting with the prefix: "urn:ietf:params:whip:ext" as d
efined in <xref target="urn-whip-subspace"/>.</t> <!-- [rfced] FYI - We updated this sentence as follows to include the name of
<t>For example, considering a potential extension of server-to-client co the IANA registry.
mmunication using server-sent events as specified in https://html.spec.whatwg.or
g/multipage/server-sent-events.html#server-sent-events, the URL for connecting t Original:
o the server-sent event resource for the ingested stream could be returned in th Each protocol extension MUST register a unique "rel" attribute value
e initial HTTP "201 Created" response with a "Link" header field and a "rel" att at IANA starting with the prefix: "urn:ietf:params:whip:ext" as
ribute of "urn:ietf:params:whip:ext:example:server-sent-events" (this document d defined in Section 6.4.
oes not specify such an extension, and uses it only as an example).</t>
<t>In this theoretical case, the "201 Created" response to the HTTP POST Updated:
request would look like:</t> Each protocol extension MUST register a unique "rel" attribute value
that starts with the prefix "urn:ietf:params:whip:ext" (as defined in
Section 6.4) in the "WebRTC-HTTP Ingestion Protocol (WHIP) Extension
URNs" registry (Section 6.3.2).
-->
<t>Each protocol extension <bcp14>MUST</bcp14> register a unique "rel"
attribute value that starts with the prefix
"urn:ietf:params:whip:ext" (as defined in <xref
target="urn-whip-subspace"/>) in the "WebRTC-HTTP Ingestion Protocol (WH
IP)
Extension URNs" registry (<xref
target="urn-whip-ext-registry"/>).</t>
<t>For example, consider a potential extension of server-to-client
communication using server-sent events as specified in 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" header field and a "rel"
attribute of "urn:ietf:params:whip:ext:example:server-sent-events"
(this document does not specify such an 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>
<!-- [rfced] The first sentence below appears immediately before Figure 6, and
the second sentence appears after. We suggest combining them and placing
before the figure. Which of the following suggestions do you prefer?
Original:
In this theoretical case, the "201 Created" response to the HTTP POST
request would look like:
...
Figure 6 shows an example of a WHIP protocol extension supported by
the WHIP session, as indicated in the Link header of the 201 Created
response.
Perhaps:
In this theoretical case, the "201 Created" response to the HTTP POST request
would look like the following (i.e., a WHIP protocol extension supported by
the WHIP session, as indicated in the Link header of the "201 Created"
response).
Or:
Figure 6 shows 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).
-->
<figure anchor="protocol-extension-example"> <figure anchor="protocol-extension-example">
<name>Example of a WHIP protocol extension</name> <name>Example of a WHIP Protocol Extension</name>
<artwork><![CDATA[ <sourcecode type=""><![CDATA[
HTTP/1.1 201 Created HTTP/1.1 201 Created
Content-Type: application/sdp Content-Type: application/sdp
Location: https://whip.example.com/session/id Location: https://whip.example.com/session/id
Link: <https://whip.example.com/session/id/sse>; Link: <https://whip.example.com/session/id/sse>;
rel="urn:ietf:params:whip:ext:example:server-sent-events" rel="urn:ietf:params:whip:ext:example:server-sent-events"
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="protocol-extension-example"/> shows an example of a WHI
P protocol extension supported by the WHIP session, as indicated in the Link hea <t><xref target="protocol-extension-example"/> shows an example of a
der of the 201 Created response.</t> WHIP protocol extension supported by the WHIP session, as indicated in
the Link header of the "201 Created" response.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document specifies a new protocol on top of HTTP and WebRTC, thus, <t>This document specifies a new protocol on top of HTTP and WebRTC;
security protocols and considerations from related specifications apply to the thus, security protocols and considerations from related specifications
WHIP specification. These include:</t> apply to the WHIP specification. These include:</t>
<ul spacing="normal">
<li> <ul>
<t>WebRTC security considerations: <xref target="RFC8826"/>. HTTPS <bc <li>WebRTC security considerations: See <xref
p14>SHALL</bcp14> be used in order to preserve the WebRTC security model.</t> target="RFC8826"/>. HTTPS <bcp14>SHALL</bcp14> be used in order to
</li> preserve the WebRTC security model.</li>
<li> <li>Transport Layer Security (TLS): See <xref target="RFC8446"/> and
<t>Transport Layer Security (TLS): <xref target="RFC8446"/> and <xref <xref target="RFC9147"/>.</li>
target="RFC9147"/>.</t> <li>HTTP security: See <xref section="11" sectionFormat="of"
</li> target="RFC9112"/> and <xref section="17" sectionFormat="of"
<li> target="RFC9110"/>.</li>
<t>HTTP security: <xref section="11" sectionFormat="of" target="RFC911 <li>URI security: See <xref section="7" sectionFormat="of" target="RFC
2"/> and <xref section="17" sectionFormat="of" target="RFC9110"/>.</t> 3986"/>.</li>
</li>
<li>
<t>URI security: <xref section="7" sectionFormat="of" target="RFC3986"
/>.</t>
</li>
</ul> </ul>
<t>On top of that, the WHIP protocol exposes a thin new attack surface spe <t>On top of that, the WHIP protocol exposes a thin new attack surface
cific of the REST API methods used within it:</t> specific to the REST API methods used within it:</t>
<!-- [rfced] FYI - We updated "HTTP POST" (singular) here to be "HTTP POST
requests" (plural). Let us know any concerns.
Original:
It would be possible
for an attacker in possession of authentication credentials valid
for ingesting a WHIP stream to make multiple HTTP POST to the
WHIP endpoint.
Current:
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.
-->
<!-- [rfced] What does "it" refers to in this sentence? If "it" refers to
"servers", we will update to "they"?
Original:
If the connection rate is high
enough, this could lead to resource exhaustion on the servers
handling the requests and it will not be able to process
legitimate incoming ingests.
Perhaps:
If the connection rate is high
enough, this could lead to resource exhaustion on the servers
handling the requests, and they will not be able to process
legitimate incoming ingests.
-->
<ul spacing="normal"> <ul spacing="normal">
<li> <li>HTTP POST flooding and resource exhaustion: It would be possible
<t>HTTP POST flooding and resource exhaustion: for an attacker in possession of authentication credentials valid
It would be possible for an attacker in possession of authentication credentials for ingesting a WHIP stream to make multiple HTTP POST requests to the
valid for ingesting a WHIP stream to make multiple HTTP POST to the WHIP endpoi WHIP
nt. endpoint. This will force the WHIP endpoint to process the incoming
This will force the WHIP endpoint to process the incoming SDP and allocate resou SDP and allocate resources for being able to set up the DTLS/ICE
rces for being able to set up the DTLS/ICE connection. connection. While the malicious client does not need to initiate
While the malicious client does not need to initiate the DTLS/ICE connection at the DTLS/ICE connection at all, the WHIP session will have to wait
all, the WHIP session will have to wait for the DTLS/ICE connection timeout in o for the DTLS/ICE connection timeout in order to release the
rder to release the associated resources. associated resources. If the connection rate is high enough, this
If the connection rate is high enough, this could lead to resource exhaustion on could lead to resource exhaustion on the servers handling the
the servers handling the requests and it will not be able to process legitimate requests, and it will not be able to process legitimate incoming
incoming ingests. ingests. In order to prevent this scenario, WHIP endpoints
In order to prevent this scenario, WHIP endpoints <bcp14>SHOULD</bcp14> implemen <bcp14>SHOULD</bcp14> implement a rate limit and avalanche control
t a rate limit and avalanche control mechanism for incoming initial HTTP POST re mechanism for incoming initial HTTP POST requests.</li>
quests.</t>
</li> <!-- [rfced] How may we update the phrases below for consistency? Perhaps as
<li> "location of WHIP sessions" as shown below?
<t>Insecure direct object references (IDOR) on the WHIP session locati
ons: WHIP session locations (plural "locations")
If the URLs returned by the WHIP endpoint for the WHIP sessions location are eas WHIP sessions location (plural "sessions")
y to guess, it would be possible for an attacker to send multiple HTTP DELETE re WHIP sessions location URL
quests and terminate all the WHIP sessions currently running.
In order to prevent this scenario, WHIP endpoints <bcp14>SHOULD</bcp14> generate Original:
URLs with enough randomness, using a cryptographically secure pseudorandom numb * Insecure direct object references (IDOR) on the WHIP session
er generator following the best practices in Randomness Requirements for Securit locations: If the URLs returned by the WHIP endpoint for the WHIP
y <xref target="RFC4086"/>, and implement a rate limit and avalanche control mec sessions location are easy to guess, it would be possible for an
hanism for HTTP DELETE requests. attacker to send multiple HTTP DELETE requests and terminate all
The security considerations for Universally Unique IDentifier (UUID) <xref secti the WHIP sessions currently running.
on="8" sectionFormat="comma" target="RFC9562"/> are applicable for generating th ...
e WHIP sessions location URL.</t> The security
</li> considerations for Universally Unique IDentifier (UUID) [RFC9562],
<li> Section 8 are applicable for generating the WHIP sessions location
<t>HTTP PATCH flooding: URL.
Similar to the HTTP POST flooding, a malicious client could also create a resour
ce exhaustion by sending multiple HTTP PATCH request to the WHIP session, althou Perhaps:
gh the WHIP sessions can limit the impact by not allocating new ICE candidates a * Insecure direct object references (IDOR) for the location of WHIP
nd reusing the existing ICE candidates when doing ICE restarts. sessions: If the URLs returned by the WHIP endpoint for the location of WH
In order to prevent this scenario, WHIP endpoints <bcp14>SHOULD</bcp14> implemen IP
t a rate limit and avalanche control mechanism for incoming HTTP PATCH requests. sessions are easy to guess, it would be possible for an
</t> attacker to send multiple HTTP DELETE requests and terminate all
</li> the WHIP sessions currently running.
...
The security
considerations for Universally Unique IDentifiers (UUIDs) in Section 8 of
[RFC9562]
are applicable for generating the URL for the location of WHIP sessions.
-->
<li>Insecure Direct Object References (IDORs) on the WHIP session
locations: If the URLs returned by the WHIP endpoint for the 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 Requirements
for Security" <xref target="RFC4086"/>, and implement a rate limit and
avalanche control
mechanism for HTTP DELETE requests. The security considerations for
Universally Unique IDentifiers (UUIDs) in <xref section="8"
sectionFormat="of" target="RFC9562"/> are applicable for generating
the WHIP sessions location URL.</li>
<li>HTTP PATCH flooding: Similar to the HTTP POST flooding, a
malicious client could also create resource exhaustion by sending
multiple HTTP PATCH 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.</li>
</ul> </ul>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This specification adds a new link relation type and a registry for URN
sub-namespaces for WHIP protocol extensions.</t> <!-- [rfced] We have included some specific questions about the IANA text in
the document. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know if any
changes are needed.
-->
<!-- [rfced] For the questions below, we will request that IANA update the
registries to match the edited document prior to publication.
a) Section 6.1: FYI - We made a minor edit (lowercased "Agent") in the
Description field of the "Link Relation Types" registry.
Link to registry: https://www.iana.org/assignments/link-relations
Original ("Agent"):
Description: Conveys the STUN and TURN servers that can be used by an
ICE Agent to establish a connection with a peer.
Current ("agent"):
Description: Conveys the STUN and TURN servers that can be used by
an ICE agent to establish a connection with a peer.
b) Section 6.2: FYI - We capitalized the title of the registry
group (https://www.iana.org/assignments/whip).
Original:
WebRTC-HTTP ingestion protocol (WHIP)
Current:
WebRTC-HTTP Ingestion Protocol (WHIP)
c) Section 6.2, 6.3, and elsewhere: We also capitalized the titles of the
following registries (https://www.iana.org/assignments/whip). May we further
update to use just the acronym WHIP rather than the expansion? WHIP is already
expanded in the title of the registry group.
Original:
WebRTC-HTTP ingestion protocol (WHIP) URNs
WebRTC-HTTP ingestion protocol (WHIP) Extension URNs
Current (capitalized "Ingestion Protocol"):
WebRTC-HTTP Ingestion Protocol (WHIP) URNs
WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs
Perhaps (use acronym):
WHIP URNs
WHIP Extension URNs
d) Section 6.3.1: Similar to the above, may we shorten the Description below
in the "WebRTC-HTTP ingestion protocol (WHIP) URNs" registry
(https://www.iana.org/assignments/whip)?
Original:
Description: WebRTC-HTTP ingestion protocol (WHIP) extension URNs
Perhaps:
Description: WHIP extension URNs
e) Section 6.3.1: After discussion with IANA, the "IANA Registry Reference"
field in the first registry at <https://www.iana.org/assignments/whip> will be
updated as follows.
Current:
[https://www.iana.org/assignments/whip]
Should be:
See "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" on [https://www.ian
a.org/assignments/whip]
Or (depending on your response to question c above):
See "WHIP Extension URNs" on [https://www.iana.org/assignments/whip]
-->
<!-- [rfced] Other questions about IANA text
a) Section 6: May we either remove this sentence or expand it to include all
the IANA actions in the document?
Original:
This specification adds a new link relation type and a registry for
URN sub-namespaces for WHIP protocol extensions.
Perhaps:
Per this specification, IANA has added a new link relation type and
a new Registered Parameter Identifier for WHIP. IANA has also created registr
ies
to manage entries within the "urn:ietf:params:whip" and
"urn:ietf:params:whip:ext" namespaces.
b) If no objections, we will reorganize the sections in the IANA
Considerations section as follows. The suggested organization corresponds to
the IANA actions and groups information about each registry together in a
section.
Original:
6. IANA Considerations
6.1. Link Relation Type: ice-server
6.2. WebRTC-HTTP Ingestion Protocol (WHIP) registry group
6.3. Registration of WHIP URN Sub-namespace and WHIP registries
6.3.1. WebRTC-HTTP ingestion protocol (WHIP) URNs registry
6.3.2. WebRTC-HTTP ingestion protocol (WHIP) extension URNs registry
6.4. URN Sub-namespace for WHIP
6.4.1. Specification Template
6.5. Registering WHIP Protocol Extensions URNs
6.5.1. Registration Procedure
6.5.2. Guidance for Designated Experts
6.5.3. WHIP Protocol Extension Registration Template
Perhaps:
6. IANA Considerations
6.1. Link Relation Type: ice-server
6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip)
6.3. WebRTC-HTTP Ingestion Protocol (WHIP) URNs Registry
6.4. WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs Registry
6.4.1. Registration Procedure
6.4.2. Guidance for Designated Experts
6.4.3. Registration Template
c) Sections 6.3 and 6.4: It looks like Section 6.4.1 includes a template from
Appendix A of RFC 3406. However, entries in the "IETF URN Sub-namespace for
Registered Protocol Parameter Identifiers" registry
(https://www.iana.org/assignments/params/) should use the template in Section 4
of RFC 3553.
For examples, see:
Section 10.1.2 of RFC 9162 (urn:ietf:params:trans)
Section 9.3 of RFC 8620 (urn:ietf:params:jmap)
Section 9.6 of RFC 8555 (urn:ietf:params:acme)
After discussion with IANA, we recommend 1) updating the text in Section 6.3
to include the template from RFC 3553 as follows and 2) removing Section 6.4.
The text in Section 6.4 already appears in Section 4.9, and if needed,
information from the template in Section 6.4.1 can be folded into Section 4.9.
(Note that we would need you to provide text for the "Index value" field in
the suggested text below.)
Original:
6.3. Registration of WHIP URN Sub-namespace and WHIP registries
IANA is asked to add an entry to the "IETF URN Sub-namespace for
Registered Protocol Parameter Identifiers" registry and create a sub-
namespace for the Registered Parameter Identifier as per [RFC3553]:
"urn:ietf:params:whip".
To manage this sub-namespace, IANA is asked to create the "WebRTC-
HTTP ingestion protocol (WHIP) URNs" and "WebRTC-HTTP ingestion
protocol (WHIP) extension URNs".
Perhaps (section numbers per suggested organization in previous question):
6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip)
IANA has added a new entry in the "IETF URN Sub-namespace for
Registered Protocol Parameter Identifiers" registry, following the
template in [RFC3553]:
Registry name: whip
Specification: RFC 9725
Repository: <https://www.iana.org/assignments/whip>
Index value: TBD
To manage this sub-namespace, IANA has created two registries within
a new registry group called "WebRTC-HTTP Ingestion Protocol (WHIP)":
* "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry (Section 6.3)
* "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry (Section 6.
4)
d) If the template in Section 6.4 is removed per the question above, please
let us know how to update the following pointers to Section 6.4. Perhaps these
should be updated to "Section 4.9"?
Original:
Each protocol extension MUST register a unique "rel" attribute value
at IANA starting with the prefix: "urn:ietf:params:whip:ext" as
defined in Section 6.4.
...
WHIP Protocol Extensions URNs have an "ext" type as defined in
Section 6.4.
e) Section 6.3.1: Is this section number correct? Or should it be Section 6.3.1?
Original:
* Reference: this document (RFC TBD) Section Section 6.3.2
Perhaps:
Reference: RFC 9725, Section 6.3.2
f) Section 6.4.1: Should "designated contact" here be updated to "designated
expert"?
Original:
* The designated contact shall be responsible for reviewing and
enforcing uniqueness.
g) Section 6.5: FYI - We updated "Section 6.4" here be to "Section 6.3.2",
which is where the registry is defined.
Original:
This section defines the process for registering new WHIP protocol
extensions URNs with IANA in the "WebRTC-HTTP ingestion protocol
(WHIP) extension URNs" registry (see Section 6.4).
Updated:
This section defines the process for registering new WHIP protocol
extension URNs with IANA in the "WebRTC-HTTP Ingestion Protocol
(WHIP) Extension URNs" registry (see Section 6.3.2).
h) Section 6.5.2: We updated this text to be a bulleted list as shown
below. Please confirm that the placement of this sentence is correct:
"Specifications should be documented in an Internet-Draft."
Original:
The Designated Expert (DE) is expected to ascertain the existence of
suitable documentation (a specification) as described in [RFC8126]
and to verify that the document is permanently and publicly
available.
The DE is also expected to check the clarity of purpose and use of
the requested registration.
Additionally, the DE must verify that any request for one of these
registrations has been made available for review and comment by
posting the request to the WebRTC Ingest Signaling over HTTPS (wish)
Working Group mailing list.
Specifications should be documented in an Internet-Draft. Lastly,
the DE must ensure that any other request for a code point does not
conflict with work that is active in or already published by the
IETF.
Perhaps:
The designated expert (DE) is expected to do the following:
* Ascertain the existence of suitable documentation (a specification)
as described in [RFC8126] and to verify that the document is permanently
and publicly available. Specifications should be documented in an
Internet-Draft.
* Check the clarity of purpose and use of the requested registration.
* Verify that any request for one of these registrations has been made
available for review and comment by posting the request to the WebRTC Inge
st
Signaling over HTTPS (wish) Working Group mailing list.
* Ensure that any other request for a code point does not
conflict with work that is active in or already published by the
IETF.
i) Section 6.5.3: The template in this section and the fields on the IANA
registry do not exactly match, as shown below. Is it correct that the template
should be updated to match the registry?
Link to registy: https://www.iana.org/assignments/whip/
Template:
URN
Reference
Name
Description
Contact Information
Registry:
URI
Description
Reference
IANA Registry Reference
Change Controller
j) This document includes a lot of detail about registering URNs in the
"WebRTC-HTTP ingestion Protocol (WHIP) Extension URNs" registry. Is any
additional information necessary for registering in the other WHIP registry?
Both are "Specification Required".
-->
<t>This specification adds a new link relation type and a registry for
URN sub-namespaces for WHIP protocol extensions.</t>
<section anchor="link-relation-type-ice-server"> <section anchor="link-relation-type-ice-server">
<name>Link Relation Type: ice-server</name> <name>Link Relation Type: ice-server</name>
<t>The link relation type below has been registered by IANA per <xref se <t>The link relation type below has been registered by IANA in the
ction="4.2" sectionFormat="of" target="RFC8288"/>.</t> "Link Relation Types" registry per <xref section="4.2"
<t>Relation Name: ice-server</t> sectionFormat="of" target="RFC8288"/>:</t>
<t>Description: Conveys the STUN and TURN servers that can be used by an
ICE Agent to establish a connection with a peer.</t> <dl newline="false" spacing="normal">
<t>Reference: TBD</t> <dt>Relation Name:</dt><dd>ice-server</dd>
<dt>Description:</dt><dd>Conveys the STUN and TURN servers that can be u
sed by
an ICE agent to establish a connection with a peer.</dd>
<dt>Reference:</dt><dd>RFC 9725</dd>
</dl>
</section> </section>
<section anchor="webrtc-http-ingestion-protocol-whip-registry-group"> <section anchor="webrtc-http-ingestion-protocol-whip-registry-group">
<name>WebRTC-HTTP Ingestion Protocol (WHIP) registry group</name> <name>WebRTC-HTTP Ingestion Protocol (WHIP) Registry Group</name>
<t>IANA is asked to create a new registry group called "WebRTC-HTTP Ing <t>IANA has created a new registry group called "WebRTC-HTTP
estion Protocol (WHIP)". This group includes the "WebRTC-HTTP ingestion protocol Ingestion Protocol (WHIP)". This group includes the "WebRTC-HTTP
(WHIP) URNs" and "WebRTC-HTTP ingestion protocol (WHIP) extension URNs" registr Ingestion Protocol (WHIP) URNs" and "WebRTC-HTTP Ingestion Protocol
ies described below.</t> (WHIP) Extension URNs" registries described in Sections <xref target="ur
n-whip-registry" format="counter"/> and <xref target="urn-whip-ext-registry" for
mat="counter"/>.</t>
</section> </section>
<section anchor="registration-of-whip-urn-sub-namespace-and-whip-registrie s"> <section anchor="registration-of-whip-urn-sub-namespace-and-whip-registrie s">
<name>Registration of WHIP URN Sub-namespace and WHIP registries</name> <name>Registration of WHIP URN Sub-Namespace and WHIP Registries</name>
<t>IANA is asked to add an entry to the "IETF URN Sub-namespace for Regi <t>IANA has added an entry in the "IETF URN Sub-namespace for Registered
stered Protocol Parameter Identifiers" registry and create a sub-namespace for t Protocol Parameter Identifiers" registry
he Registered Parameter Identifier as per <xref target="RFC3553"/>: "urn:ietf:pa <xref target="RFC3553"/> for "urn:ietf:params:whip" as follows:</t>
rams:whip".</t>
<t>To manage this sub-namespace, IANA is asked to create the "WebRTC-HTT <dl>
P ingestion protocol (WHIP) URNs" and "WebRTC-HTTP ingestion protocol (WHIP) ext <dt>Registered Parameter Identifier:</dt><dd>whip</dd>
ension URNs".</t> <dt>Reference:</dt><dd>RFC 9725</dd>
<dt>IANA Registry Reference:</dt><dd>&lt;https://www.iana.org/assignments/whip&g
t;
</dd>
</dl>
<t>To manage this sub-namespace, IANA has created the
"WebRTC-HTTP Ingestion Protocol (WHIP) URNs" and "WebRTC-HTTP
Ingestion Protocol (WHIP) Extension URNs" registries described below.</t
>
<section anchor="urn-whip-registry"> <section anchor="urn-whip-registry">
<name>WebRTC-HTTP ingestion protocol (WHIP) URNs registry</name> <name>WebRTC-HTTP Ingestion Protocol (WHIP) URNs Registry</name>
<t>The "WebRTC-HTTP ingestion protocol (WHIP) URNs" registry is used t <t>The "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry is used
o manage entries within the "urn:ietf:params:whip" namespace. The registry descr to manage entries within the "urn:ietf:params:whip" namespace. The
iptions is as follows:</t> registration procedure is "Specification Required" <xref target="RFC81
<ul spacing="normal"> 26"/>. The registry contains the following fields:
<li> URI, Description, Reference, IANA Registry Reference, and Change Contro
<t>Registry group: WebRTC-HTTP ingestion protocol (WHIP)</t> ller. This document is listed as the reference.</t>
</li>
<li> <t>The registry contains a single initial entry:</t>
<t>Registry name: WebRTC-HTTP ingestion protocol (WHIP) URNs</t> <dl spacing="normal">
</li> <dt>URI:</dt><dd>urn:ietf:params:whip:ext</dd>
<li> <dt>Description:</dt><dd>WebRTC-HTTP ingestion protocol (WHIP) ext
<t>Specification: this document (RFC TBD)</t> ension URNs</dd>
</li> <dt>Reference:</dt><dd><xref target="urn-whip-ext-registry"/> of R
<li> FC 9725</dd>
<t>Registration procedure: Specification Required</t> <dt>IANA Registry Reference:</dt><dd>See "WebRTC-HTTP Ingestion Pr
</li> otocol (WHIP) Extension URNs" on &lt;https://www.iana.org/assignments/whip&gt;</
<li> dd>
<t>Field names: URI, description, change controller, reference and <dt>Change Controller:</dt><dd>IETF</dd>
IANA registry reference</t>
</li> </dl>
</ul>
<t>The registry contains a single initial value:</t>
<ul spacing="normal">
<li>
<t>URI: urn:ietf:params:whip:ext</t>
</li>
<li>
<t>Description: WebRTC-HTTP ingestion protocol (WHIP) extension UR
Ns</t>
</li>
<li>
<t>Change Controller: IETF</t>
</li>
<li>
<t>Reference: this document (RFC TBD) Section <xref target="urn-wh
ip-ext-registry"/></t>
</li>
<li>
<t>IANA registry reference: WebRTC-HTTP ingestion protocol (WHIP)
extension URNs registry.</t>
</li>
</ul>
</section> </section>
<section anchor="urn-whip-ext-registry"> <section anchor="urn-whip-ext-registry">
<name>WebRTC-HTTP ingestion protocol (WHIP) extension URNs registry</n <name>WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs Registry</n
ame> ame>
<t>The "WebRTC-HTTP ingestion protocol (WHIP) Extension URNs" is used <t>The "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" is
to manage entries within the "urn:ietf:params:whip:ext" namespace. The registry used to manage entries within the "urn:ietf:params:whip:ext"
descriptions is as follows:</t> namespace. The registration procedure is "Specification Required"
<ul spacing="normal"> <xref target="RFC8126"/>.
<li> The registry contains the following fields:
<t>Registry group: WebRTC-HTTP ingestion protocol (WHIP)</t> URI, Description, Reference, IANA Registry Reference, and Change Contro
</li> ller. This document is listed as the reference.
<li> </t>
<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: URI, description, change controller, reference and
IANA registry reference</t>
</li>
</ul>
</section> </section>
</section> </section>
<section anchor="urn-whip-subspace"> <section anchor="urn-whip-subspace">
<name>URN Sub-namespace for WHIP</name> <name>URN Sub-Namespace for WHIP</name>
<t>WHIP endpoint utilizes URNs to identify the supported WHIP protocol e <t>A WHIP endpoint utilizes URNs to identify the supported WHIP
xtensions on the "rel" attribute of the Link header as defined in <xref target=" protocol extensions on the "rel" attribute of the Link header as
protocol-extensions"/>.</t> defined in <xref target="protocol-extensions"/>.</t>
<t>This section creates and registers an IETF URN Sub-namespace for use <t>This section creates and registers an IETF URN sub-namespace for use
in the WHIP specifications and future extensions.</t> in the WHIP specifications and future extensions.</t>
<section anchor="specification-template"> <section anchor="specification-template">
<name>Specification Template</name> <name>Specification Template</name>
<t>Namespace ID:</t>
<ul spacing="normal"> <dl newline="true">
<li> <dt>Namespace ID:</dt><dd>whip</dd>
<t>The Namespace ID "whip" has been assigned.</t> <dt>Registration Information:</dt>
</li> <dd>
</ul> <dl newline="false">
<t>Registration Information:</t> <dt>Version:</dt><dd>1</dd>
<ul spacing="normal"> <dt>Date:</dt><dd>TBD</dd>
<li> </dl></dd>
<t>Version: 1</t> <dt>Declared registrant of the namespace:</dt>
</li> <dd><dl newline="false">
<li> <dt>Registering organization:</dt><dd>IETF</dd>
<t>Date: TBD</t> <dt>Designated contact:</dt><dd>A designated expert (DE) will moni
</li> tor the public mailing list &lt;wish@ietf.org&gt;.</dd>
</ul> </dl></dd>
<t>Declared registrant of the namespace:</t> <dt>Declaration of Syntactic Structure:</dt><dd>
<ul spacing="normal">
<li>
<t>Registering organization: The Internet Engineering Task Force.<
/t>
</li>
<li>
<t>Designated contact: A designated expert will monitor the WHIP p
ublic 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 URNs that use the "w hip" Namespace ID shall have the following structure: urn:ietf:params:whip:{type }:{name}:{other}.</t> <t>The Namespace Specific String (NSS) of all URNs that use the "w hip" Namespace ID shall have the following structure: urn:ietf:params:whip:{type }:{name}:{other}.</t>
</li>
<li> <t>The keywords have the following meanings: </t>
<t>The keywords have the following meaning: </t> <dl spacing="normal">
<ul spacing="normal"> <dt>type:</dt><dd>The entity type. This specification only def
<li> ines the "ext" type.</dd>
<t>type: The entity type. This specification only defines the <dt>name:</dt><dd>A required ASCII string that conforms to the
"ext" type.</t> URN syntax requirements (see <xref target="RFC8141"/>) and defines a major name
</li> space of a WHIP protocol extension. The value <bcp14>MAY</bcp14> also be an indu
<li> stry name or organization name.</dd>
<t>name: A required ASCII string that conforms to the URN synt <dt>other:</dt><dd>Any ASCII string that conforms to the URN s
ax requirements (see <xref target="RFC8141"/>) and defines a major namespace of yntax requirements (see <xref target="RFC8141"/>) and defines the sub-namespace
a WHIP protocol extension. The value <bcp14>MAY</bcp14> also be an industry name (which <bcp14>MAY</bcp14> be further broken down in namespaces delimited by colo
or organization name.</t> ns) as needed to uniquely identify a WHIP protocol extension.</dd>
</li> </dl></dd>
<li> <dt>Relevant Ancillary Documentation:</dt>
<t>other: Any ASCII string that conforms to the URN syntax req <dd>None</dd>
uirements (see <xref target="RFC8141"/>) and defines the sub-namespace (which <b <dt>Identifier Uniqueness Considerations:</dt>
cp14>MAY</bcp14> be further broken down in namespaces delimited by colons) as ne <dd>The designated contact shall be responsible for reviewing and
eded to uniquely identify an WHIP protocol extension.</t> enforcing uniqueness.</dd>
</li> <dt>Identifier Persistence Considerations:</dt>
</ul> <dd><ul>
</li> <li>Once a name has been allocated, it <bcp14>MUST NOT</bcp14> be real
</ul> located for a different purpose.</li>
<t>Relevant Ancillary Documentation:</t> <li>The rules provided for assignments of values within a sub-name
<ul spacing="normal"> space <bcp14>MUST</bcp14> be constructed so that the meanings of values cannot c
<li> hange.</li>
<t>None</t> <li>This registration mechanism is not appropriate for naming values
</li> whose meanings may change over time.</li>
</ul> </ul></dd>
<t>Identifier Uniqueness Considerations:</t> <dt>Process of Identifier Assignment:</dt>
<ul spacing="normal"> <dd>
<li> <t>The namespace with type "ext" (e.g., "urn:ietf:params:whip:ext"
<t>The designated contact shall be responsible for reviewing and e ) is reserved for IETF-approved WHIP specifications.</t>
nforcing uniqueness.</t> </dd>
</li> <dt>Process of Identifier Resolution:</dt>
</ul> <dd>
<t>Identifier Persistence Considerations:</t> <t>None specified</t>
<ul spacing="normal"> </dd>
<li> <dt>Rules for Lexical Equivalence:</dt>
<t>Once a name has been allocated, it <bcp14>MUST NOT</bcp14> be r <dd><t>No special considerations; the rules for lexical equivalence sp
eallocated for a different purpose.</t> ecified in <xref target="RFC8141"/> apply.</t>
</li> </dd>
<li> <dt>Conformance with URN Syntax:</dt>
<t>The rules provided for assignments of values within a sub-names <dd><t>No special considerations</t>
pace <bcp14>MUST</bcp14> be constructed so that the meanings of values cannot ch </dd>
ange.</t> <dt>Validation Mechanism:</dt>
</li> <dd>None specified</dd>
<li> <dt>Scope:</dt>
<t>This registration mechanism is not appropriate for naming value <dd>
s whose meanings may change over time.</t> Global</dd>
</li> </dl>
</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 sp
ecified 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> </section>
</section> </section>
<section anchor="registering-whip-protocol-extensions-urns"> <section anchor="registering-whip-protocol-extensions-urns">
<name>Registering WHIP Protocol Extensions URNs</name> <name>Registering WHIP Protocol Extension URNs</name>
<t>This section defines the process for registering new WHIP protocol ex <t>This section defines the process for registering new WHIP protocol ex
tensions URNs with IANA in the "WebRTC-HTTP ingestion protocol (WHIP) extension tension URNs with IANA in the "WebRTC-HTTP Ingestion Protocol (WHIP) Extension U
URNs" registry (see <xref target="urn-whip-subspace"/>).</t> RNs" registry (see <xref target="urn-whip-ext-registry"/>).</t>
<t>A WHIP Protocol Extension URNs is used as a value in the "rel" attrib <t>A WHIP Protocol Extension URN is used as a value in the "rel" attribu
ute of the Link header as defined in <xref target="protocol-extensions"/> for th te of the Link header as defined in <xref target="protocol-extensions"/> for the
e purpose of signaling the WHIP protocol extensions supported by the WHIP endpoi purpose of signaling the WHIP protocol extensions supported by the WHIP endpoin
nts.</t> t.</t>
<t>WHIP Protocol Extensions URNs have an "ext" type as defined in <xref <t>WHIP Protocol Extension URNs have an "ext" type as defined in <xref t
target="urn-whip-subspace"/>.</t> arget="urn-whip-subspace"/>.</t>
<section anchor="registration-procedure"> <section anchor="registration-procedure">
<name>Registration Procedure</name> <name>Registration Procedure</name>
<t>The IETF has created a mailing list, "wish@ietf.org", which can be <t>The IETF has created a mailing list, &lt;wish@ietf.org&gt;, which c
used an
for public discussion of WHIP protocol extensions proposals prior to registra be used for public discussion of proposals regarding WHIP protocol ext
tion. ensions
Use of the mailing list is strongly encouraged. The IESG has prior to registration. Use of the mailing list is strongly
appointed a designated expert as per <xref target="RFC8126"/> who will monito encouraged. A designated expert (DE) <xref
r the target="RFC8126"/>, appointed by the IESG, will monitor the &lt;wish@
wish@ietf.org mailing list and review registrations.</t> ietf.org&gt; mailing list
<t>Registration of new "ext" type URNs (in the namespace "urn:ietf:par and review registrations.</t>
ams:whip:ext") belonging to a WHIP Protocol Extension <bcp14>MUST</bcp14> be doc <t>Registration of new "ext" type URNs (in the namespace
umented in a permanent and readily available public specification, in sufficient "urn:ietf:params:whip:ext") belonging to a WHIP Protocol Extension
detail so that interoperability between independent implementations is possible <bcp14>MUST</bcp14> be documented in a permanent and readily
and reviewed by the designated expert as per Section 4.6 of <xref target="RFC81 available public specification, in sufficient detail so that
26"/>. interoperability between independent implementations is possible, and
An Standards Track RFC is <bcp14>REQUIRED</bcp14> for the registration of new reviewed by the DE as per <xref section="4.6"
value data types that modify existing properties. sectionFormat="of" target="RFC8126"/>. A Standards Track RFC is
An Standards Track RFC is also <bcp14>REQUIRED</bcp14> for registration of WH <bcp14>REQUIRED</bcp14> for the registration of new value data types
IP Protocol Extensions URNs that modify WHIP Protocol Extensions previously docu that modify existing properties. A Standards Track RFC is also
mented in an existing RFC.</t> <bcp14>REQUIRED</bcp14> for registration of WHIP Protocol Extension
<t>The registration procedure begins when a completed registration tem URNs that modify WHIP Protocol Extensions previously documented in
plate, defined in the sections below, is sent to iana@iana.org. an existing RFC.</t>
Decisions made by the designated expert can be appealed to an Applications an
d Real Time (ART) Area Director, then to the IESG. <!-- [rfced] This sentence cites [BCP9], but it seems that only RFC 2026
within BCP 9 contains information about the procedure for appeals. May we
update in one of the following ways to direct the reader to the RFC that
contains the applicable information? Note that the reference entry for
[BCP9] contains all RFCs that comprise BCP 9 (which has of now is eight).
Original:
The normal appeals
procedure described in [BCP9] is to be followed.
Perhaps:
The normal appeals
procedure described in RFC 2026 [BCP9] is to be followed.
Or:
The normal appeals
procedure described in [RFC2026] is to be followed.
-->
<t>The registration procedure begins when a completed registration tem
plate, defined in <xref target="whip-protocol-extension-registration-template"/>
, is sent to &lt;iana@iana.org&gt;.
Decisions made by the DE can be appealed to an Applications and Real-Time (AR
T) Area Director, then to the IESG.
The normal appeals procedure described in <xref target="BCP9"/> is to be foll owed.</t> The normal appeals procedure described in <xref target="BCP9"/> is to be foll owed.</t>
<t>Once the registration procedure concludes successfully, IANA create s <t>Once the registration procedure concludes successfully, IANA create s
or modifies the corresponding record in the WHIP Protocol Extension registry. </t> or modifies the corresponding record in the "WebRTC-HTTP ingestion protocol ( WHIP) Extension URNs" registry.</t>
<t>An RFC specifying one or more new WHIP Protocol Extension URNs <bcp 14>MUST</bcp14> include the <t>An RFC specifying one or more new WHIP Protocol Extension URNs <bcp 14>MUST</bcp14> include the
completed registration templates, which <bcp14>MAY</bcp14> be expanded with completed registration template(s), which <bcp14>MAY</bcp14> be expanded with
additional information. These completed templates are intended to go additional information. These completed template(s) are intended to go
in the body of the document, not in the IANA Considerations section. 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 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> field advertising the extension.</t>
</section> </section>
<section anchor="guidance-for-designated-experts"> <section anchor="guidance-for-designated-experts">
<name>Guidance for Designated Experts</name> <name>Guidance for the Designated Expert</name>
<t>The Designated Expert (DE) is expected to ascertain the existence o <t>The DE is expected to do the following:</t>
f suitable documentation (a specification) as described in <xref target="RFC8126 <ul>
"/> and to verify that the document is permanently and publicly available.</t> <li>Ascertain the existence of suitable documentation (a
<t>The DE is also expected to check the clarity of purpose and use of specification) as described in <xref target="RFC8126"/> and verify
the requested registration.</t> that the document is permanently and publicly
<t>Additionally, the DE must verify that any request for one of these available. Specifications should be documented in an
registrations has been made available for review and comment by posting the requ Internet-Draft.</li>
est to the WebRTC Ingest Signaling over HTTPS (wish) Working Group mailing list. <li>Check the clarity of purpose and use of the requested
</t> registration.</li> <li>Verify that any request for one of these
<t>Specifications should be documented in an Internet-Draft. Lastly, t registrations has been made available for review and comments by
he DE must ensure that any other request for a code point does not conflict with posting the request to the &lt;wish@ietf.org&gt; mailing list.</li>
work that is active in or already published by the IETF.</t> <li>Ensure that any other request for a code point does not conflict w
ith work that is active or already published by the IETF.</li>
</ul>
</section> </section>
<section anchor="whip-protocol-extension-registration-template"> <section anchor="whip-protocol-extension-registration-template">
<name>WHIP Protocol Extension Registration Template</name> <name>Registration Template</name>
<t>A WHIP Protocol Extension URNs is defined by completing the followi <t>A WHIP Protocol Extension URN is defined by completing the followin
ng template:</t> g template:</t>
<ul spacing="normal"> <dl spacing="normal">
<li> <dt>URN:</dt><dd>A unique URN for the WHIP Protocol Extension (e.g
<t>URN: A unique URN for the WHIP Protocol Extension (e.g., "urn:i ., "urn:ietf:params:whip:ext:example:server-sent-events")</dd>
etf:params:whip:ext:example:server-sent-events").</t> <dt>Reference:</dt><dd>A formal reference to the publicly availabl
</li> e specification</dd>
<li> <dt>Name:</dt><dd>A descriptive name of the WHIP Protocol Extensio
<t>Reference: A formal reference to the publicly available specifi n (e.g., "Sender Side events")</dd>
cation</t> <dt>Description:</dt><dd>A brief description of the function of th
</li> e extension (short paragraph or two)</dd>
<li> <dt>Contact information:</dt><dd>Contact information for the organ
<t>Name: A descriptive name of the WHIP Protocol Extension (e.g., ization or person making the registration</dd>
"Sender Side events").</t> </dl>
</li>
<li>
<t>Description: A brief description of the function of the extensi
on, in a short paragraph or two</t>
</li>
<li>
<t>Contact information: Contact information for the organization o
r person making the registration</t>
</li>
</ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>The authors wish to thank Lorenzo Miniero, Juliusz Chroboczek, Adam Roa
ch, Nils Ohlmeier, Christer Holmberg, Cameron Elliott, Gustavo Garcia, Jonas Bir
me, Sandro Gauci, Christer Holmberg and everyone else in the WebRTC community th
at have provided comments, feedback, text and improvement proposals on the docum
ent and contributed early implementations of the spec.</t>
</section>
</middle> </middle>
<back> <back>
<!-- [rfced] Please review the following questions and changes regarding the
references used in this document.
a.) This W3C recommendation has a new version dated October 2024. Would you
like to cite the latest version? If so, please confirm that the text in this
document citing Section 4.2.1 of the W3C recommendation is still correct.
Original:
[W3C.REC-webrtc-20210126]
Jennings, C., Ed., Boström, H., Ed., and J. Bruaroey, Ed.,
"WebRTC 1.0: Real-Time Communication Between Browsers",
W3C REC REC-webrtc-20210126, W3C REC-webrtc-20210126, 26
January 2021,
<https://www.w3.org/TR/2021/REC-webrtc-20210126/>.
Perhaps:
[W3C.REC-webrtc-20210126]
Jennings, C., Ed., Castelli, F., Ed., Boström, H., Ed., and J. Bru
aroey, Ed.,
"WebRTC: Real-Time Communication in Browsers",
W3C Recommendation, 8 October 2024,
<https://www.w3.org/TR/2024/REC-webrtc-20241008/>. Latest
version available at: <https://www.w3.org/TR/webrtc/>.
Here is where this recommendation is cited in the text of this document:
Original:
NOTE: The naming of both the "rel" attribute value of "ice-server"
and the target attributes follows the one used on the W3C WebRTC
recommendation [W3C.REC-webrtc-20210126] RTCConfiguration dictionary
in section 4.2.1.
b.) FYI - We have updated the text below as follows and provided a citation in
the reference section for this URL. Please review and let us know any
objections.
Original:
For example, considering 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,
Current:
For example, consider a potential extension of server-to-client
communication using server-sent events as specified in Section 9.2 of
[HTML].
...
[HTML] WHATWG, "HTML", WHATWG Living Standard,
<https://html.spec.whatwg.org/>. Commit snapshot:
<https://html.spec.whatwg.org/commit-
snapshots/09db56ba9343c597340b2c7715f43ff9b10826f6/>.
-->
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="FETCH" target="https://fetch.spec.whatwg.org"> <reference anchor="FETCH" target="https://fetch.spec.whatwg.org">
<front> <front>
<title>Fetch - Living Standard</title> <title>Fetch</title>
<author> <author>
<organization>WHATWG</organization> <organization>WHATWG</organization>
</author> </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 JavaScrip
t application to control the signaling plane of a multimedia session via the int
erface 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> </front>
<seriesInfo name="RFC" value="9429"/> <refcontent>WHATWG Living Standard</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9429"/> <annotation>Commit snapshot: <eref
</reference> target="https://fetch.spec.whatwg.org/commit-snapshots/edfa8d100cf1ecf
<reference anchor="RFC3264"> de385f65c172e0e8d018fcd98/"
<front> brackets="angle"/>.</annotation>
<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 mak
e 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 parti
cipant answers with the desired session from their perspective. This offer/answe
r model is most useful in unicast sessions where information from both participa
nts is needed for the complete view of the session. The offer/answer model is us
ed 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</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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</ti
tle>
<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 protoco
l 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="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, 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, 7
232, 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="Ravindrana
th"/>
<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 launchin
g attacks by sending traffic to unwilling victims, periodic consent to send need
s 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> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
429.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
264.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
675.xml"/>
<reference anchor="W3C.REC-ldp-20150226" target="https://www.w3.org/TR/2 015/REC-ldp-20150226/"> <reference anchor="W3C.REC-ldp-20150226" target="https://www.w3.org/TR/2 015/REC-ldp-20150226/">
<front> <front>
<title>Linked Data Platform 1.0</title> <title>Linked Data Platform 1.0</title>
<author fullname="Ashok Malhotra" role="editor"/>
<author fullname="John Arwe" role="editor"/> <author fullname="John Arwe" role="editor"/>
<author fullname="Steve Speicher" role="editor"/> <author fullname="Steve Speicher" role="editor"/>
<author fullname="Ashok Malhotra" role="editor"/>
<date day="26" month="February" year="2015"/> <date day="26" month="February" year="2015"/>
</front> </front>
<seriesInfo name="W3C REC" value="REC-ldp-20150226"/> <refcontent>W3C Recommendation</refcontent>
<seriesInfo name="W3C" value="REC-ldp-20150226"/> <annotation>Latest version available at: <eref target="https://www.w3.
</reference> org/TR/ldp/" brackets="angle"/>.</annotation>
<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 devi
ces in a telepresence conference to interoperate. The protocol enables communica
tion of information about multiple media streams so a sending system and receivi
ng system can make reasonable decisions about transmitting, selecting, and rende
ring the media streams. This protocol is used in addition to SIP signaling and S
ession Description Protocol (SDP) negotiation for setting up a telepresence sess
ion.</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 I
nteractive 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 Inte
ractive Connectivity Establishment (ICE) protocol that enables ICE agents to beg
in connectivity checks while they are still gathering candidates, by incremental
ly exchanging candidates over time instead of all at once. This method can consi
derably 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 Pro
visioning 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 descr
ibes a Network Address Translator (NAT) traversal mechanism for UDP-based multim
edia sessions established with the Offer/Answer model. The ICE extension for Inc
remental Provisioning of Candidates (Trickle ICE) defines a mechanism that allow
s ICE Agents to shorten session establishment delays by making the candidate gat
hering and connectivity checking phases of ICE non-blocking and by executing the
m 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 Pack
age to support this usage together with the corresponding media type. Additional
ly, 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 fo
r Interactive Connectivity Establishment (ICE)</title>
<author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Hu
guenin"/>
<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) Offe
r/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 wit
h 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 descript
ions ("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 BUN
DLE transport form a BUNDLE group.</t>
<t>This specification defines a new RTP Control Protocol (RTCP) So
urce 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 indic
ate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The d
ocument 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) gr
ouping mechanism for RTP media streams that can be used to specify relations bet
ween media streams.</t>
<t>This mechanism is used to signal the association between the SD
P concept of "media description" and the Web Real-Time Communication (WebRTC) co
ncept 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 Consideration
s 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) of
fer/answer procedures for negotiating and establishing a Datagram Transport Laye
r Security (DTLS) association. The document also defines the criteria for when a
new DTLS association must be established. The document updates RFCs 5763 and 73
45 by replacing common SDP offer/answer procedures with a reference to this spec
ification.</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 us
ed 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 betwee
n resources on the Web ("links") and the type of those relationships ("link rela
tion 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-Hu
guenin"/>
<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 (S
TUN) 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 Ide
ntifiers</title>
<author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Hu
guenin"/>
<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 Identifi
er (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It d
efines 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-Hu
guenin"/>
<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 s
erves as a tool for other protocols in dealing with NAT traversal. It can be use
d 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-al
ive protocol to maintain NAT bindings. STUN works with many existing NATs and do
es 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</ti
tle>
<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 r
equests to access OAuth 2.0 protected resources. Any party in possession of a be
arer token (a "bearer") can use it to get access to the associated resources (wi
thout demonstrating possession of a cryptographic key). To prevent misuse, beare
r tokens need to be protected from disclosure in storage and in transport. [STAN
DARDS-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 se
curity 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 num
erous protocols and applications, both in the area of digital identity and in ot
her application areas. This Best Current Practices document updates RFC 7519 to
provide actionable guidance leading to secure implementation and deployment of J
WTs.</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 mult
iple differently encoded versions of the same media source in different RTP stre
ams. This is called simulcast. This document describes how to accomplish simulca
st in RTP and how to signal it in the Session Description Protocol (SDP). The de
scribed 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 tha
t those RTP streams are different simulcast formats of that media source. The SD
P extension consists of a new media-level SDP attribute that expresses capabilit
y 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 d
ocument defines the WebRTC threat model and analyzes the security threats of Web
RTC 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</titl
e>
<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 Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</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 version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, 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 exceptio
n 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="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n 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 ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; 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 3
rd"/>
<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 t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e 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 u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re 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 Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s 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 IDentifier
s) --
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 wi
th the
kind permission of the OSF (now known as "The Open Group"). Information from ear
lier 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. T
his document specifies an Internet Best Current Practices for the Internet Commu
nity, 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> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
845.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
838.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
789.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
840.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
585.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
839.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
143.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
858.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
830.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
842.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
288.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
064.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
065.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
489.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
750.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
725.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
853.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
826.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
112.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
562.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
553.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC3261">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<title>SIP: Session Initiation Protocol</title> 261.xml"/>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne 120.xml"/>
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="G. Camarillo" initials="G." surname="Camarillo"/> 826.xml"/>
<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 a
pplication-layer control (signaling) protocol for creating, modifying, and termi
nating sessions with one or more participants. These sessions include Internet t
elephone 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</titl
e>
<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 app
lication profile of the Extensible Markup Language (XML) that enables the near-r
eal-time exchange of structured yet extensible data between any two or more netw
ork entities. This document defines XMPP's core protocol methods: setup and tear
down of XML streams, channel encryption, authentication, error handling, and com
munication primitives for messaging, network availability ("presence"), and requ
est-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" surnam
e="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 au
dio 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>
<referencegroup anchor="BCP56" target="https://www.rfc-editor.org/info/b cp56"> <referencegroup anchor="BCP56" target="https://www.rfc-editor.org/info/b cp56">
<reference anchor="RFC9205" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
c9205"> .9205.xml"/>
<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-bas
ed APIs. This document specifies best practices for writing specifications that
use HTTP to define new application protocols. It is written primarily to guide I
ETF efforts to define application protocols using HTTP for deployment on the Int
ernet 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>
</referencegroup> </referencegroup>
<reference anchor="RFC9457"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
457.xml"/>
<reference anchor="HTML" target="https://html.spec.whatwg.org/">
<front> <front>
<title>Problem Details for HTTP APIs</title> <title>HTML</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ <author>
> <organization>WHATWG</organization>
<author fullname="E. Wilde" initials="E." surname="Wilde"/> </author>
<author fullname="S. Dalal" initials="S." surname="Dalal"/>
<date month="July" year="2023"/>
<abstract>
<t>This document defines a "problem detail" to carry machine-reada
ble details of errors in HTTP response content to avoid the need to define new e
rror response formats for HTTP APIs.</t>
<t>This document obsoletes RFC 7807.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9457"/> <refcontent>WHATWG Living Standard</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9457"/> <annotation>Commit snapshot: <eref target="https://html.spec.whatwg.or
g/commit-snapshots/09db56ba9343c597340b2c7715f43ff9b10826f6/" brackets="angle"/>
.</annotation>
</reference> </reference>
<reference anchor="W3C.REC-webrtc-20210126" target="https://www.w3.org/T R/2021/REC-webrtc-20210126/"> <reference anchor="W3C.REC-webrtc-20210126" target="https://www.w3.org/T R/2021/REC-webrtc-20210126/">
<front> <front>
<title>WebRTC 1.0: Real-Time Communication Between Browsers</title> <title>WebRTC 1.0: Real-Time Communication Between Browsers</title>
<author fullname="Cullen Jennings" role="editor"/> <author fullname="Cullen Jennings" role="editor"/>
<author fullname="Henrik Boström" role="editor"/> <author fullname="Henrik Boström" role="editor"/>
<author fullname="Jan-Ivar Bruaroey" role="editor"/> <author fullname="Jan-Ivar Bruaroey" role="editor"/>
<date day="26" month="January" year="2021"/> <date day="26" month="January" year="2021"/>
</front> </front>
<seriesInfo name="W3C REC" value="REC-webrtc-20210126"/> <refcontent>W3C Recommendation</refcontent>
<seriesInfo name="W3C" value="REC-webrtc-20210126"/> <annotation>Latest version available at: <eref target="https://www.w3.
</reference> org/TR/webrtc/" brackets="angle"/>.</annotation>
<reference anchor="RFC8836">
<front>
<title>Congestion Control Requirements for Interactive Real-Time Med
ia</title>
<author fullname="R. Jesup" initials="R." surname="Jesup"/>
<author fullname="Z. Sarker" initials="Z." role="editor" surname="Sa
rker"/>
<date month="January" year="2021"/>
<abstract>
<t>Congestion control is needed for all data transported across th
e Internet, in order to promote fair usage and prevent congestion collapse. The
requirements for interactive, point-to-point real-time multimedia, which needs l
ow-delay, semi-reliable data delivery, are different from the requirements for b
ulk transfer like FTP or bursty transfers like web pages. Due to an increasing a
mount of RTP-based real-time media traffic on the Internet (e.g., with the intro
duction 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 fit
ness for this purpose, and in particular to provide a set of possible requiremen
ts 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 resour
ce identifier. With regard to URN syntax, this document defines the canonical sy
ntax for URNs (in a way that is consistent with URI syntax), specifies methods f
or determining URN-equivalence, and discusses URI conformance. With regard to UR
N namespaces, this document specifies a method for defining a URN namespace and
associating it with a namespace identifier, and it describes procedures for regi
stering 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 con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations 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 des
cribing the conditions under which new values should be assigned, as well as whe
n 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 Consideratio
ns 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 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
836.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
141.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<referencegroup anchor="BCP9" target="https://www.rfc-editor.org/info/bc p9"> <referencegroup anchor="BCP9" target="https://www.rfc-editor.org/info/bc p9">
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
c2026"> .2026.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<title>The Internet Standards Process -- Revision 3</title> .5657.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<date month="October" year="1996"/> .6410.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<t>This memo documents the process used by the Internet communit .7100.xml"/>
y for the standardization of protocols and procedures. It defines the stages in <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
the standardization process, the requirements for moving a document between stag .7127.xml"/>
es and the types of documents used during this process. This document specifies <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
an Internet Best Current Practices for the Internet Community, and requests disc .7475.xml"/>
ussion and suggestions for improvements.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
</abstract> .8789.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<seriesInfo name="BCP" value="9"/> .9282.xml"/>
<seriesInfo name="RFC" value="2026"/>
<seriesInfo name="DOI" value="10.17487/RFC2026"/>
</reference>
<reference anchor="RFC5657" target="https://www.rfc-editor.org/info/rf
c5657">
<front>
<title>Guidance on Interoperation and Implementation Reports for A
dvancement 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 availab
le to new report preparers. This document updates the existing processes and pro
vides more detail on what is appropriate in an interoperability and implementati
on report. This document specifies an Internet Best Current Practices for the In
ternet Community, and requests discussion 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/rf
c6410">
<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 (IE
TF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards P
rocess 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/rf
c7100">
<front>
<title>Retirement of the "Internet Official Protocol Standards" Su
mmary 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 su
mmary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and reque
sts 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/rf
c7127">
<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 Engin
eering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes th
e maturity level of those documents. This document updates RFC 2026 by providing
a current 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/rf
c7475">
<front>
<title>Increasing the Number of Area Directors in an IETF Area</ti
tle>
<author fullname="S. Dawkins" initials="S." surname="Dawkins"/>
<date month="March" year="2015"/>
<abstract>
<t>This document removes a limit 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/rf
c8789">
<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 S
tream 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/rf
c9282">
<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 R
FC Series Working Group and the RFC Series Approval Board. It is no longer the r
esponsibility of the RFC Editor, and the role of the IAB in the RFC Series is al
tered. Accordingly, in Section 2.1 of RFC 2026, the sentence "RFC publication is
the direct responsibility of the RFC Editor, under the general direction 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> </referencegroup>
</references> </references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The authors wish to 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 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>
</back> </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==
<!-- [rfced] Please review the following questions regarding the terminology
used in this document.
a.) Quotation marks appear around some of these terms but not others. Please
review and let us know if quotes should be added or removed from any of these
instances for consistency within the document.
Access-Control-Request-Headers HTTP header
"Accept-Post" header
HTTP Authorization header field
"If-Match" header field
Retry-After header field
Location header
Location header field
Link header
"Link" header field
Link header field
ETag header
ETag header field
ETag response header field
entity-tag value
"password" value
"POST" value
"Link" value
b.) Both "Link attribute" and "Link target attributes" appear in the sentences
below. Are these the same thing? If so, Let us know if updates are needed for
consistency.
Original:
WHIP clients MUST ignore any Link attribute with an unknown "rel"
attribute value and WHIP sessions MUST NOT require the usage of any
extension.
...
The credentials are encoded in the Link
target attributes as follows:
c.) We note a number of instances of "WHIP protocol". As the "P" in "WHIP"
already stands for "protocol", this is repetitive when expanded (i.e.,
"WebRTC-HTTP Ingestion Protocol protocol".
If no objections, we will update the following instances as shown below to
avoid repetition. We will also update to use the lowercase "extension".
WHIP protocol > WHIP
WHIP protocol extension > WHIP extension
WHIP Protocol Extension URN > WHIP extension URN
d.) We see both of the following forms in the document. Should these be
uniform? If so, please let us know which form is preferred.
ingestion session
ingest session
-->
<!-- [rfced] FYI - We have updated the terms below as follows. Please review
and let us know any objections.
a.) We updated the occurrence of line names as follows to match the use in
RFCs 9429 and 8866.
m-line > "m=" line
m-sections > "m=" sections
b.) We updated "2XX" and "4XX" to "2xx" and "4xx", respectively, per usage in
RFC 9110.
c.) We updated the single quotes to double quotes below for consistency with
the other attributes in this document. Please let us know any objections.
Original:
'ice-options'
'ice-pacing'
'ice-lite'
Current:
"ice-options"
"ice-pacing"
"ice-lite"
d.) In Section 4.6, we added quotation marks for "credential-type" and
"credential" as attribute names elsewhere in the document are enclosed in
quotation marks.
e.) We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
JavaScript Session Establishment Protocol (JSEP)
Extensible Messaging and Presence Protocol (XMPP)
Real-Time Streaming Protocol (RTSP)
Session Traversal Utilities for NAT (STUN)
Traversal Using Relays around NAT (TURN)
JSON Web Tokens (JWTs)
Real Time Messaging Protocol (RTMP)
-->
<!-- [rfced] Questions about XML formatting
a.) Please review whether any of the notes in this document should be in the
<aside> element. It is defined as "a container for content that is
semantically less important or tangential to the content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
b.) We updated <artwork> to <sourcecode> for Figures 2-6. Please consider
whether the "type" attribute of any sourcecode element should be set.
The current list of preferred values for "type" is available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration.
Note that it is also acceptable to leave the "type" attribute not set.
c.) Figures 2-5 in this document are too wide for the text output. Please
review and let us know how we should update. Note that RFC 8792 may be a
helpful resource for this.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 112 change blocks. 
2330 lines changed or deleted 2043 lines changed or added

This html diff was produced by rfcdiff 1.48.