rfc9218.original.xml   rfc9218.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!-- [CS] updated by Chris 01/21/22 -->
<!-- draft submitted in xml v3 -->
<!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-rfc2629 version 1.5.24 --> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.24 -->
<?rfc docindent="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc strict="yes"?> -ietf-httpbis-priority-12" number="9218" submissionType="IETF" category="std" co
<?rfc compact="yes"?> nsensus="true" tocInclude="true" sortRefs="true" symRefs="true" obsoletes="" upd
<?rfc comments="yes"?> ates="" xml:lang="en" version="3">
<?rfc inline="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-httpbis-priority-12" category="std" consensus="true" tocInclude="true" sor
tRefs="true" symRefs="true" obsoletes="" updates="" submissionType="IETF" xml:la
ng="en" version="3">
<!-- xml2rfc v2v3 conversion 3.12.0 --> <!-- xml2rfc v2v3 conversion 3.12.0 -->
<front> <front>
<title abbrev="HTTP Priorities">Extensible Prioritization Scheme for HTTP</t itle> <title abbrev="HTTP Priorities">Extensible Prioritization Scheme for HTTP</t itle>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-priority-12"/> <seriesInfo name="RFC" value="9218"/>
<author initials="K." surname="Oku" fullname="Kazuho Oku"> <author asciiFullname="Kazuho Oku" fullname="奥 一穂">
<organization>Fastly</organization> <organization>Fastly</organization>
<address> <address>
<email>kazuhooku@gmail.com</email> <email>kazuhooku@gmail.com</email>
</address> </address>
</author> </author>
<author initials="L." surname="Pardue" fullname="Lucas Pardue"> <author initials="L." surname="Pardue" fullname="Lucas Pardue">
<organization>Cloudflare</organization> <organization>Cloudflare</organization>
<address> <address>
<email>lucaspardue.24.7@gmail.com</email> <email>lucaspardue.24.7@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022" month="January" day="18"/> <date year="2022" month="June"/>
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTP</workgroup> <workgroup>HTTP</workgroup>
<keyword>Internet-Draft</keyword> <keyword>Response priority</keyword>
<keyword>Stream multiplexing</keyword>
<keyword>Reprioritization</keyword>
<keyword>Server scheduling</keyword>
<abstract> <abstract>
<t>This document describes a scheme that allows an HTTP client to communic ate its <t>This document describes a scheme that allows an HTTP client to communic ate its
preferences for how the upstream server prioritizes responses to its requests, preferences for how the upstream server prioritizes responses to its requests,
and also allows a server to hint to a downstream intermediary how its responses and also allows a server to hint to a downstream intermediary how its responses
should be prioritized when they are forwarded. This document defines the should be prioritized when they are forwarded. This document defines the
Priority header field for communicating the initial priority in an HTTP Priority header field for communicating the initial priority in an HTTP
version-independent manner, as well as HTTP/2 and HTTP/3 frames for version-independent manner, as well as HTTP/2 and HTTP/3 frames for
reprioritizing responses. These share a common format structure that is designed reprioritizing responses. These share a common format structure that is designed
to provide future extensibility.</t> to provide future extensibility.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-httpbis-priority/"/>.
</t>
<t>
Discussion of this document takes place on the
HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.or
g"/>),
which is archived at <eref target="https://lists.w3.org/Archives/Public/
ietf-http-wg/"/>.
Working Group information can be found at <eref target="https://httpwg.o
rg/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http-extensions/labels/prioritie
s"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>It is common for representations of an HTTP <xref target="HTTP" format= "default"/> <t>It is common for representations of an HTTP <xref target="HTTP" format= "default"/>
resource to have relationships to one or more other resources. Clients will resource to have relationships to one or more other resources. Clients will
often discover these relationships while processing a retrieved representation, often discover these relationships while processing a retrieved representation,
which may lead to further retrieval requests. Meanwhile, the nature of the which may lead to further retrieval requests. Meanwhile, the nature of the
relationship determines whether the client is blocked from continuing to process relationships determines whether a client is blocked from continuing to process
locally available resources. An example of this is visual rendering of an HTML locally available resources. An example of this is the visual rendering of an H
document, which could be blocked by the retrieval of a CSS file that the TML
document, which could be blocked by the retrieval of a Cascading Style Sheets (C
SS) file that the
document refers to. In contrast, inline images do not block rendering and get dr awn document refers to. In contrast, inline images do not block rendering and get dr awn
incrementally as the chunks of the images arrive.</t> incrementally as the chunks of the images arrive.</t>
<t>HTTP/2 <xref target="HTTP2" format="default"/> and HTTP/3 <t>HTTP/2 <xref target="HTTP2" format="default"/> and HTTP/3
<xref target="HTTP3" format="default"/> support multiplexing of requests and res ponses in <xref target="HTTP3" format="default"/> support multiplexing of requests and res ponses in
a single connection. An important feature of any implementation of a protocol a single connection. An important feature of any implementation of a protocol
that provides multiplexing is the ability to prioritize the sending of that provides multiplexing is the ability to prioritize the sending of
information. For example, to provide meaningful presentation of an HTML document information. For example, to provide meaningful presentation of an HTML document
at the earliest moment, it is important for an HTTP server to prioritize the at the earliest moment, it is important for an HTTP server to prioritize the
HTTP responses, or the chunks of those HTTP responses, that it sends to a HTTP responses, or the chunks of those HTTP responses, that it sends to a
client.</t> client.</t>
skipping to change at line 93 skipping to change at line 78
successfully serve HTTP responses. However, servers that operate in ignorance successfully serve HTTP responses. However, servers that operate in ignorance
of how clients issue requests and consume responses can cause suboptimal client of how clients issue requests and consume responses can cause suboptimal client
application performance. Priority signals allow clients to communicate their application performance. Priority signals allow clients to communicate their
view of request priority. Servers have their own needs that are independent of view of request priority. Servers have their own needs that are independent of
client needs, so they often combine priority signals with other available client needs, so they often combine priority signals with other available
information in order to inform scheduling of response data.</t> information in order to inform scheduling of response data.</t>
<t>RFC 7540 <xref target="RFC7540" format="default"/> stream priority allo wed a client to send a series of <t>RFC 7540 <xref target="RFC7540" format="default"/> stream priority allo wed a client to send a series of
priority signals that communicate to the server a "priority tree"; the structure priority signals that communicate to the server a "priority tree"; the structure
of this tree represents the client's preferred relative ordering and weighted of this tree represents the client's preferred relative ordering and weighted
distribution of the bandwidth among HTTP responses. Servers could use these distribution of the bandwidth among HTTP responses. Servers could use these
priority signals as input into prioritization decision-making.</t> priority signals as input into prioritization decisions.</t>
<t>The design and implementation of RFC 7540 stream priority was observed <t>The design and implementation of RFC 7540 stream priority were observed
to have to have
shortcomings, explained in <xref target="motivation" format="default"/>. HTTP/2 shortcomings, as explained in <xref target="motivation" format="default"/>. HTTP
/2
<xref target="HTTP2" format="default"/> has consequently deprecated the use of <xref target="HTTP2" format="default"/> has consequently deprecated the use of
these stream priority signals. The prioritization scheme and priority signals these stream priority signals. The prioritization scheme and priority signals
defined herein can act as a substitute for RFC 7540 stream priority.</t> defined herein can act as a substitute for RFC 7540 stream priority.</t>
<t>This document describes an extensible scheme for prioritizing HTTP resp onses <t>This document describes an extensible scheme for prioritizing HTTP resp onses
that uses absolute values. <xref target="parameters" format="default"/> defines priority parameters, which are that uses absolute values. <xref target="parameters" format="default"/> defines priority parameters, which are
a standardized and extensible format of priority information. <xref target="head er-field" format="default"/> a standardized and extensible format of priority information. <xref target="head er-field" format="default"/>
defines the Priority HTTP header field, a protocol-version-independent and defines the Priority HTTP header field, which is an
end-to-end priority signal. Clients can send this header field to signal their end-to-end priority signal that is independent of protocol version. Clients can
send this header field to signal their
view of how responses should be prioritized. Similarly, servers behind an view of how responses should be prioritized. Similarly, servers behind an
intermediary can use it to signal priority to the intermediary. After sending a intermediary can use it to signal priority to the intermediary. After sending a
request, a client can change their view of response priority (see request, a client can change their view of response priority (see
<xref target="reprioritization" format="default"/>) by sending HTTP-version-spec <xref target="reprioritization" format="default"/>) by sending HTTP-version-spec
ific frames defined in ific frames as defined in
<xref target="h2-update-frame" format="default"/> and <xref target="h3-update-fr Sections&nbsp;<xref target="h2-update-frame" format="counter"/> and <xref target
ame" format="default"/>.</t> ="h3-update-frame" format="counter"/>.</t>
<t>Header field and frame priority signals are input to a server's respons e <t>Header field and frame priority signals are input to a server's respons e
prioritization process. They are only a suggestion and do not guarantee any prioritization process. They are only a suggestion and do not guarantee any
particular processing or transmission order for one response relative to any particular processing or transmission order for one response relative to any
other response. <xref target="server-scheduling" format="default"/> and <xref ta other response. Sections&nbsp;<xref target="server-scheduling" format="counter"/
rget="retransmission-scheduling" format="default"/> provide > and <xref target="retransmission-scheduling" format="counter"/> provide
consideration and guidance about how servers might act upon signals.</t> considerations and guidance about how servers might act upon signals.</t>
<section anchor="notational-conventions" numbered="true" toc="default"> <section anchor="notational-conventions" numbered="true" toc="default">
<name>Notational Conventions</name> <name>Notational Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8 are to be interpreted as described in BCP&nbsp;14
174" format="default"/> when, and only when, they <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
<t>The terms Dictionary, sf-boolean, sf-dictionary, and sf-integer are i <t>This document uses the following terminology from <xref section="3" s
mported from ectionFormat="of" target="STRUCTURED-FIELDS"/> to specify syntax and parsing: "B
<xref target="STRUCTURED-FIELDS" format="default"/>.</t> oolean", "Dictionary", and "Integer".</t>
<t>Example HTTP requests and responses use the HTTP/2-style formatting f rom <t>Example HTTP requests and responses use the HTTP/2-style formatting f rom
<xref target="HTTP2" format="default"/>.</t> <xref target="HTTP2" format="default"/>.</t>
<t>This document uses the variable-length integer encoding from <t>This document uses the variable-length integer encoding from
<xref target="QUIC" format="default"/>.</t> <xref target="QUIC" format="default"/>.</t>
<t>The term control stream is used to describe both the HTTP/2 stream wi th <t>The term "control stream" is used to describe both the HTTP/2 stream with
identifier 0x0 and the HTTP/3 control stream; see <xref section="6.2.1" sectionF ormat="of" target="HTTP3" format="default"/>.</t> identifier 0x0 and the HTTP/3 control stream; see <xref section="6.2.1" sectionF ormat="of" target="HTTP3" format="default"/>.</t>
<t>The term HTTP/2 priority signal is used to describe the priority info rmation <t>The term "HTTP/2 priority signal" is used to describe the priority in formation
sent from clients to servers in HTTP/2 frames; see <xref section="5.3.2" section Format="of" target="HTTP2" format="default"/>.</t> sent from clients to servers in HTTP/2 frames; see <xref section="5.3.2" section Format="of" target="HTTP2" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="motivation" numbered="true" toc="default"> <section anchor="motivation" numbered="true" toc="default">
<name>Motivation for Replacing RFC 7540 Priorities</name> <name>Motivation for Replacing RFC 7540 Stream Priorities</name>
<t>RFC 7540 stream priority (see <xref section="5.3" sectionFormat="of" ta rget="RFC7540" format="default"/>) is a complex system <t>RFC 7540 stream priority (see <xref section="5.3" sectionFormat="of" ta rget="RFC7540" format="default"/>) is a complex system
where clients signal stream dependencies and weights to describe an unbalanced where clients signal stream dependencies and weights to describe an unbalanced
tree. It suffered from limited deployment and interoperability and was deprecate d tree. It suffered from limited deployment and interoperability and has been depr ecated
in a revision of HTTP/2 <xref target="HTTP2" format="default"/>. HTTP/2 retains these protocol elements in in a revision of HTTP/2 <xref target="HTTP2" format="default"/>. HTTP/2 retains these protocol elements in
order to maintain wire compatibility (see <xref section="5.3.2" sectionFormat="o f" target="HTTP2" format="default"/>), which order to maintain wire compatibility (see <xref section="5.3.2" sectionFormat="o f" target="HTTP2" format="default"/>), which
means that they might still be used even in the presence of alternative signalin g, means that they might still be used even in the presence of alternative signalin g,
such as the scheme this document describes.</t> such as the scheme this document describes.</t>
<t>Many RFC 7540 server implementations do not act on HTTP/2 priority <t>Many RFC 7540 server implementations do not act on HTTP/2 priority
signals.</t> signals.</t>
<t>Prioritization can use information that servers have about resources or <t>Prioritization can use information that servers have about resources or
the order in which requests are generated. For example, a server, with knowledge the order in which requests are generated. For example, a server, with knowledge
of an HTML document structure, might want to prioritize the delivery of images of an HTML document structure, might want to prioritize the delivery of images
that are critical to user experience above other images. With RFC 7540 it is that are critical to user experience above other images. With RFC 7540, it is
difficult for servers to interpret signals from clients for prioritization as difficult for servers to interpret signals from clients for prioritization, as
the same conditions could result in very different signaling from different the same conditions could result in very different signaling from different
clients. This document describes signaling that is simpler and more constrained, clients. This document describes signaling that is simpler and more constrained,
requiring less interpretation and allowing less variation.</t> requiring less interpretation and allowing less variation.</t>
<t>RFC 7540 does not define a method that can be used by a server to provi de a <t>RFC 7540 does not define a method that can be used by a server to provi de a
priority signal for intermediaries.</t> priority signal for intermediaries.</t>
<t>RFC 7540 priority is expressed relative to other requests sharing the s <t>RFC 7540 stream priority is expressed relative to other requests sharin
ame g the same
connection at the same time. It is difficult to incorporate such design into connection at the same time. It is difficult to incorporate such a design into
applications that generate requests without knowledge of how other requests applications that generate requests without knowledge of how other requests
might share a connection, or into protocols that do not have strong ordering might share a connection, or into protocols that do not have strong ordering
guarantees across streams, like HTTP/3 <xref target="HTTP3" format="default"/>.< /t> guarantees across streams, like HTTP/3 <xref target="HTTP3" format="default"/>.< /t>
<t>Experiments from independent research (<xref target="MARX" format="defa ult"/>) have shown <t>Experiments from independent research <xref target="MARX" format="defau lt"/> have shown
that simpler schemes can reach at least equivalent performance characteristics that simpler schemes can reach at least equivalent performance characteristics
compared to the more complex RFC 7540 setups seen in practice, at least for the compared to the more complex RFC 7540 setups seen in practice, at least for the
web use case.</t> Web use case.</t>
<section anchor="disabling" numbered="true" toc="default"> <section anchor="disabling" numbered="true" toc="default">
<name>Disabling RFC 7540 Priorities</name> <name>Disabling RFC 7540 Stream Priorities</name>
<t>The problems and insights set out above provided the motivation for a n <t>The problems and insights set out above provided the motivation for a n
alternative to RFC 7540 stream priority (see <xref section="5.3" sectionFormat=" of" target="HTTP2" format="default"/>).</t> alternative to RFC 7540 stream priority (see <xref section="5.3" sectionFormat=" of" target="HTTP2" format="default"/>).</t>
<t>The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this document in <t>The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this document in
order to allow endpoints to omit or ignore HTTP/2 priority signals (see order to allow endpoints to omit or ignore HTTP/2 priority signals (see
<xref section="5.3.2" sectionFormat="of" target="HTTP2" format="default"/>), as described below. The value of <xref section="5.3.2" sectionFormat="of" target="HTTP2" format="default"/>), as described below. The value of
SETTINGS_NO_RFC7540_PRIORITIES <bcp14>MUST</bcp14> be 0 or 1. Any value other th an 0 or 1 <bcp14>MUST</bcp14> SETTINGS_NO_RFC7540_PRIORITIES <bcp14>MUST</bcp14> be 0 or 1. Any value other th an 0 or 1 <bcp14>MUST</bcp14>
be treated as a connection error (see <xref section="5.4.1" sectionFormat="of" t arget="HTTP2" format="default"/>) of type be treated as a connection error (see <xref section="5.4.1" sectionFormat="of" t arget="HTTP2" format="default"/>) of type
PROTOCOL_ERROR. The initial value is 0.</t> PROTOCOL_ERROR. The initial value is 0.</t>
<t>If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they <bcp14>MUST</bcp 14> send it in the first <t>If endpoints use SETTINGS_NO_RFC7540_PRIORITIES, they <bcp14>MUST</bc p14> send it in the first
SETTINGS frame. Senders <bcp14>MUST NOT</bcp14> change the SETTINGS_NO_RFC7540_P RIORITIES value SETTINGS frame. Senders <bcp14>MUST NOT</bcp14> change the SETTINGS_NO_RFC7540_P RIORITIES value
after the first SETTINGS frame. Receivers that detect a change <bcp14>MAY</bcp14 > treat it as a after the first SETTINGS frame. Receivers that detect a change <bcp14>MAY</bcp14 > treat it as a
connection error of type PROTOCOL_ERROR.</t> connection error of type PROTOCOL_ERROR.</t>
<t>Clients can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to indicate <t>Clients can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to indicate
that they are not using HTTP/2 priority signals. The SETTINGS frame precedes any that they are not using HTTP/2 priority signals. The SETTINGS frame precedes any
HTTP/2 priority signal sent from clients, so servers can determine whether they HTTP/2 priority signal sent from clients, so servers can determine whether they
need to allocate any resources to signal handling before signals arrive. A need to allocate any resources to signal handling before signals arrive. A
server that receives SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 <bcp14>MUS T</bcp14> server that receives SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 <bcp14>MUS T</bcp14>
ignore HTTP/2 priority signals.</t> ignore HTTP/2 priority signals.</t>
<t>Servers can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to indicate <t>Servers can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to indicate
that they will ignore HTTP/2 priority signals sent by clients.</t> that they will ignore HTTP/2 priority signals sent by clients.</t>
<t>Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to use <t>Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to use
alternative priority signals (for example, <xref target="header-field" format="d alternative priority signals (for example, see <xref target="header-field" forma
efault"/> or t="default"/> or
<xref target="h2-update-frame" format="default"/>) but there is no requirement t <xref target="h2-update-frame" format="default"/>), but there is no requirement
o use a specific signal type.</t> to use a specific signal type.</t>
<section anchor="advice-when-using-extensible-priorities-as-the-alternat ive" numbered="true" toc="default"> <section anchor="advice-when-using-extensible-priorities-as-the-alternat ive" numbered="true" toc="default">
<name>Advice when Using Extensible Priorities as the Alternative</name > <name>Advice when Using Extensible Priorities as the Alternative</name >
<t>Before receiving a SETTINGS frame from a server, a client does not know if the server <t>Before receiving a SETTINGS frame from a server, a client does not know if the server
is ignoring HTTP/2 priority signals. Therefore, until the client receives the is ignoring HTTP/2 priority signals. Therefore, until the client receives the
SETTINGS frame from the server, the client <bcp14>SHOULD</bcp14> send both the H TTP/2 SETTINGS frame from the server, the client <bcp14>SHOULD</bcp14> send both the H TTP/2
priority signals and the signals of this prioritization scheme (see priority signals and the signals of this prioritization scheme (see
<xref target="header-field" format="default"/> and <xref target="h2-update-frame " format="default"/>).</t> Sections&nbsp;<xref target="header-field" format="counter"/> and <xref target="h 2-update-frame" format="counter"/>).</t>
<t>Once the client receives the first SETTINGS frame that contains the <t>Once the client receives the first SETTINGS frame that contains the
SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it <bcp14>SHOULD</bcp1 4> stop sending SETTINGS_NO_RFC7540_PRIORITIES parameter with a value of 1, it <bcp14>SHOULD</bc p14> stop sending
the HTTP/2 priority signals. This avoids sending redundant signals that are the HTTP/2 priority signals. This avoids sending redundant signals that are
known to be ignored.</t> known to be ignored.</t>
<t>Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES wi th value of 0 <t>Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES wi th a value of 0
or if the settings parameter was absent, it <bcp14>SHOULD</bcp14> stop sending P RIORITY_UPDATE or if the settings parameter was absent, it <bcp14>SHOULD</bcp14> stop sending P RIORITY_UPDATE
frames (<xref target="h2-update-frame" format="default"/>), since those frames a re likely to be ignored. frames (<xref target="h2-update-frame" format="default"/>), since those frames a re likely to be ignored.
However, the client <bcp14>MAY</bcp14> continue sending the Priority header fiel d However, the client <bcp14>MAY</bcp14> continue sending the Priority header fiel d
(<xref target="header-field" format="default"/>), as it is an end-to-end signal that might be useful to nodes (<xref target="header-field" format="default"/>), as it is an end-to-end signal that might be useful to nodes
behind the server that the client is directly connected to.</t> behind the server that the client is directly connected to.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="applicability-of-the-extensible-priority-scheme" numbered=" true" toc="default"> <section anchor="applicability-of-the-extensible-priority-scheme" numbered=" true" toc="default">
<name>Applicability of the Extensible Priority Scheme</name> <name>Applicability of the Extensible Priority Scheme</name>
<t>The priority scheme defined by this document is primarily focused on th e <t>The priority scheme defined by this document is primarily focused on th e
prioritization of HTTP response messages (see <xref section="3.4" sectionFormat= "of" target="HTTP" format="default"/>). It prioritization of HTTP response messages (see <xref section="3.4" sectionFormat= "of" target="HTTP" format="default"/>). It
defines new priority parameters (<xref target="parameters" format="default"/>) a nd a means of conveying those defines new priority parameters (<xref target="parameters" format="default"/>) a nd a means of conveying those
parameters (<xref target="header-field" format="default"/> and <xref target="fra me" format="default"/>), which is intended to communicate parameters (Sections&nbsp;<xref target="header-field" format="counter"/> and <xr ef target="frame" format="counter"/>), which is intended to communicate
the priority of responses to a server that is responsible for prioritizing the priority of responses to a server that is responsible for prioritizing
them. <xref target="server-scheduling" format="default"/> provides consideration s for servers about acting on them. <xref target="server-scheduling" format="default"/> provides consideration s for servers about acting on
those signals in combination with other inputs and factors.</t> those signals in combination with other inputs and factors.</t>
<t>The CONNECT method (see <xref section="9.3.6" sectionFormat="of" target ="HTTP" format="default"/>) can be used to establish <t>The CONNECT method (see <xref section="9.3.6" sectionFormat="of" target ="HTTP" format="default"/>) can be used to establish
tunnels. Signaling applies similarly to tunnels; additional considerations for tunnels. Signaling applies similarly to tunnels; additional considerations for
server prioritization are given in <xref target="connect-scheduling" format="def ault"/>.</t> server prioritization are given in <xref target="connect-scheduling" format="def ault"/>.</t>
<t><xref target="client-scheduling" format="default"/> describes how clien ts can optionally apply elements of <t><xref target="client-scheduling" format="default"/> describes how clien ts can optionally apply elements of
this scheme locally to the request messages that they generate.</t> this scheme locally to the request messages that they generate.</t>
<t>Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream beha vior or <t>Some forms of HTTP extensions might change HTTP/2 or HTTP/3 stream beha vior or
define new data carriage mechanisms. Such extensions can define themselves how define new data carriage mechanisms. Such extensions can themselves define
this priority scheme is to be applied.</t> how this priority scheme is to be applied.</t>
</section> </section>
<section anchor="parameters" numbered="true" toc="default"> <section anchor="parameters" numbered="true" toc="default">
<name>Priority Parameters</name> <name>Priority Parameters</name>
<t>The priority information is a sequence of key-value pairs, providing ro om for <t>The priority information is a sequence of key-value pairs, providing ro om for
future extensions. Each key-value pair represents a priority parameter.</t> future extensions. Each key-value pair represents a priority parameter.</t>
<t>The Priority HTTP header field (<xref target="header-field" format="def ault"/>) is an end-to-end way to <t>The Priority HTTP header field (<xref target="header-field" format="def ault"/>) is an end-to-end way to
transmit this set of priority parameters when a request or a response is issued. transmit this set of priority parameters when a request or a response is issued.
After sending a request, a client can change their view of response priority After sending a request, a client can change their view of response priority
(<xref target="reprioritization" format="default"/>) by sending HTTP-version-spe (<xref target="reprioritization" format="default"/>) by sending HTTP-version-spe
cific PRIORITY_UPDATE frames cific PRIORITY_UPDATE frames as
defined in <xref target="h2-update-frame" format="default"/> and <xref target="h defined in Sections&nbsp;<xref target="h2-update-frame" format="counter"/> and <
3-update-frame" format="default"/>. Frames transmit priority xref target="h3-update-frame" format="counter"/>. Frames transmit priority
parameters on a single hop only.</t> parameters on a single hop only.</t>
<t>Intermediaries can consume and produce priority signals in a PRIORITY_U PDATE <t>Intermediaries can consume and produce priority signals in a PRIORITY_U PDATE
frame or Priority header field. Sending a PRIORITY_UPDATE frame preserves the frame or Priority header field. An intermediary that passes only the Priority
signal from the client carried by the Priority header field, but provides a request header field to the next hop preserves the original end-to-end signal
signal that overrides that for the next hop; see <xref target="header-field-rati from the client; see <xref target="header-field-rationale" format="default"/>.
onale" format="default"/>. An intermediary could pass the Priority header field and additionally send a PRI
Replacing or adding a Priority header field overrides any signal from a client ORITY_UPDATE frame. This would have the effect of preserving the original client
and can affect prioritization for all subsequent recipients.</t> end-to-end signal, while instructing the next hop to use a different priority,
per the guidance in <xref target="frame"/>. An intermediary that replaces or add
s a Priority request header field overrides the original client end-to-end signa
l, which can affect prioritization for all subsequent recipients of the request.
</t>
<t>For both the Priority header field and the PRIORITY_UPDATE frame, the s et of <t>For both the Priority header field and the PRIORITY_UPDATE frame, the s et of
priority parameters is encoded as a Structured Fields Dictionary (see priority parameters is encoded as a Dictionary (see
<xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS" format="defaul t"/>).</t> <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS" format="defaul t"/>).</t>
<t>This document defines the urgency(<tt>u</tt>) and incremental(<tt>i</tt >) priority parameters. <t>This document defines the urgency (<tt>u</tt>) and incremental (<tt>i</ tt>) priority parameters.
When receiving an HTTP request that does not carry these priority parameters, a When receiving an HTTP request that does not carry these priority parameters, a
server <bcp14>SHOULD</bcp14> act as if their default values were specified.</t> server <bcp14>SHOULD</bcp14> act as if their default values were specified.</t>
<t>An intermediary can combine signals from requests and responses that it forwards. <t>An intermediary can combine signals from requests and responses that it forwards.
Note that omission of priority parameters in responses is handled differently fr om Note that omission of priority parameters in responses is handled differently fr om
omission in requests; see <xref target="merging" format="default"/>.</t> omission in requests; see <xref target="merging" format="default"/>.</t>
<t>Receivers parse the Dictionary as defined in <xref section="4.2" sectio nFormat="of" target="STRUCTURED-FIELDS" format="default"/>. Where the Dictionary is successfully parsed, this document <t>Receivers parse the Dictionary as described in <xref section="4.2" sect ionFormat="of" target="STRUCTURED-FIELDS" format="default"/>. Where the Dictiona ry is successfully parsed, this document
places the additional requirement that unknown priority parameters, priority places the additional requirement that unknown priority parameters, priority
parameters with out-of-range values, or values of unexpected types <bcp14>MUST</ bcp14> be parameters with out-of-range values, or values of unexpected types <bcp14>MUST</ bcp14> be
ignored.</t> ignored.</t>
<section anchor="urgency" numbered="true" toc="default"> <section anchor="urgency" numbered="true" toc="default">
<name>Urgency</name> <name>Urgency</name>
<t>The urgency parameter (<tt>u</tt>) takes an integer between 0 and 7, <t>The urgency (<tt>u</tt>) parameter value is Integer (see <xref sectio
in descending n="3.3.1" sectionFormat="of" target="STRUCTURED-FIELDS"/>), between 0 and 7 incl
order of priority.</t> usive, in descending order of priority. The default is 3.</t>
<t>The value is encoded as an sf-integer. The default value is 3.</t>
<t>Endpoints use this parameter to communicate their view of the precede nce of <t>Endpoints use this parameter to communicate their view of the precede nce of
HTTP responses. The chosen value of urgency can be based on the expectation that HTTP responses. The chosen value of urgency can be based on the expectation that
servers might use this information to transmit HTTP responses in the order of servers might use this information to transmit HTTP responses in the order of
their urgency. The smaller the value, the higher the precedence.</t> their urgency. The smaller the value, the higher the precedence.</t>
<t>The following example shows a request for a CSS file with the urgency set to <t>The following example shows a request for a CSS file with the urgency set to
<tt>0</tt>:</t> <tt>0</tt>:</t>
<sourcecode type="example"><![CDATA[ <artwork type=""><![CDATA[
:method = GET :method = GET
:scheme = https :scheme = https
:authority = example.net :authority = example.net
:path = /style.css :path = /style.css
priority = u=0 priority = u=0
]]></sourcecode> ]]></artwork>
<t>A client that fetches a document that likely consists of multiple HTT P resources <t>A client that fetches a document that likely consists of multiple HTT P resources
(e.g., HTML) <bcp14>SHOULD</bcp14> assign the default urgency level to the main resource. This (e.g., HTML) <bcp14>SHOULD</bcp14> assign the default urgency level to the main resource. This
convention allows servers to refine the urgency using convention allows servers to refine the urgency using
knowledge specific to the web-site (see <xref target="merging" format="default"/ >).</t> knowledge specific to the website (see <xref target="merging" format="default"/> ).</t>
<t>The lowest urgency level (7) is reserved for background tasks such as delivery <t>The lowest urgency level (7) is reserved for background tasks such as delivery
of software updates. This urgency level <bcp14>SHOULD NOT</bcp14> be used for fe tching of software updates. This urgency level <bcp14>SHOULD NOT</bcp14> be used for fe tching
responses that have impact on user interaction.</t> responses that have any impact on user interaction.</t>
</section> </section>
<section anchor="incremental" numbered="true" toc="default"> <section anchor="incremental" numbered="true" toc="default">
<name>Incremental</name> <name>Incremental</name>
<t>The incremental parameter (<tt>i</tt>) takes an sf-boolean as the val ue that indicates <t>The incremental (<tt>i</tt>) parameter value is Boolean (see <xref se ction="3.3.6" sectionFormat="of" target="STRUCTURED-FIELDS"/>). It indicates
if an HTTP response can be processed incrementally, i.e., provide some if an HTTP response can be processed incrementally, i.e., provide some
meaningful output as chunks of the response arrive.</t> meaningful output as chunks of the response arrive.</t>
<t>The default value of the incremental parameter is false (<tt>0</tt>). </t> <t>The default value of the incremental parameter is <tt>false</tt> (<tt >0</tt>).</t>
<t>If a client makes concurrent requests with the incremental parameter set to <t>If a client makes concurrent requests with the incremental parameter set to
false, there is no benefit serving responses with the same urgency concurrently <tt>false</tt>, there is no benefit in serving responses with the same urgency c oncurrently
because the client is not going to process those responses incrementally. because the client is not going to process those responses incrementally.
Serving non-incremental responses with the same urgency one by one, in the order in which those Serving non-incremental responses with the same urgency one by one, in the order in which those
requests were generated is considered to be the best strategy.</t> requests were generated, is considered to be the best strategy.</t>
<t>If a client makes concurrent requests with the incremental parameter set to <t>If a client makes concurrent requests with the incremental parameter set to
true, serving requests with the same urgency concurrently might be beneficial. <tt>true</tt>, serving requests with the same urgency concurrently might be bene ficial.
Doing this distributes the connection bandwidth, meaning that responses take Doing this distributes the connection bandwidth, meaning that responses take
longer to complete. Incremental delivery is most useful where multiple longer to complete. Incremental delivery is most useful where multiple
partial responses might provide some value to clients ahead of a partial responses might provide some value to clients ahead of a
complete response being available.</t> complete response being available.</t>
<t>The following example shows a request for a JPEG file with the urgenc y parameter <t>The following example shows a request for a JPEG file with the urgenc y parameter
set to <tt>5</tt> and the incremental parameter set to <tt>true</tt>.</t> set to <tt>5</tt> and the incremental parameter set to <tt>true</tt>.</t>
<sourcecode type="example"><![CDATA[ <artwork type=""><![CDATA[
:method = GET :method = GET
:scheme = https :scheme = https
:authority = example.net :authority = example.net
:path = /image.jpg :path = /image.jpg
priority = u=5, i priority = u=5, i
]]></sourcecode> ]]></artwork>
</section> </section>
<section anchor="new-parameters" numbered="true" toc="default"> <section anchor="new-parameters" numbered="true" toc="default">
<name>Defining New Priority Parameters</name> <name>Defining New Priority Parameters</name>
<t>When attempting to define new priority parameters, care must be taken so that <t>When attempting to define new priority parameters, care must be taken so that
they do not adversely interfere with prioritization performed by existing they do not adversely interfere with prioritization performed by existing
endpoints or intermediaries that do not understand the newly defined priority endpoints or intermediaries that do not understand the newly defined priority
parameter. Since unknown priority parameters are ignored, new priority parameters. Since unknown priority parameters are ignored, new priority
parameters should not change the interpretation of, or modify, the urgency (see parameters should not change the interpretation of, or modify, the urgency (see
<xref target="urgency" format="default"/>) or incremental (see <xref target="inc remental" format="default"/>) priority parameters in a way <xref target="urgency" format="default"/>) or incremental (see <xref target="inc remental" format="default"/>) priority parameters in a way
that is not backwards compatible or fallback safe.</t> that is not backwards compatible or fallback safe.</t>
<t>For example, if there is a need to provide more granularity than eigh t urgency <t>For example, if there is a need to provide more granularity than eigh t urgency
levels, it would be possible to subdivide the range using an additional priority levels, it would be possible to subdivide the range using an additional priority
parameter. Implementations that do not recognize the parameter can safely parameter. Implementations that do not recognize the parameter can safely
continue to use the less granular eight levels.</t> continue to use the less granular eight levels.</t>
<t>Alternatively, the urgency can be augmented. For example, a graphical user agent <t>Alternatively, the urgency can be augmented. For example, a graphical user agent
could send a <tt>visible</tt> priority parameter to indicate if the resource bei ng requested is could send a <tt>visible</tt> priority parameter to indicate if the resource bei ng requested is
within the viewport.</t> within the viewport.</t>
<t>Generic priority parameters are preferred over vendor-specific, <t>Generic priority parameters are preferred over vendor-specific,
application-specific or deployment-specific values. If a generic value cannot be application-specific, or deployment-specific values. If a generic value cannot b e
agreed upon in the community, the parameter's name should be correspondingly agreed upon in the community, the parameter's name should be correspondingly
specific (e.g., with a prefix that identifies the vendor, application or specific (e.g., with a prefix that identifies the vendor, application, or
deployment).</t> deployment).</t>
<section anchor="register" numbered="true" toc="default"> <section anchor="register" numbered="true" toc="default">
<name>Registration</name> <name>Registration</name>
<t>New priority parameters can be defined by registering them in the H <t>New priority parameters can be defined by registering them in the "
TTP Priority HTTP Priority"
Parameters Registry. The registry governs the keys (short textual strings) used registry. This registry governs the keys (short textual strings) used
in the Structured Fields Dictionary (see <xref section="3.2" sectionFormat="of" in the Dictionary (see <xref section="3.2" sectionFormat="of" target="STRUCTURED
target="STRUCTURED-FIELDS" format="default"/>). -FIELDS" format="default"/>).
Since each HTTP request can have associated priority signals, there is value Since each HTTP request can have associated priority signals, there is value
in having short key lengths, especially single-character strings. In order to in having short key lengths, especially single-character strings. In order to
encourage extension while avoiding unintended conflict among attractive key encourage extensions while avoiding unintended conflict among attractive key
values, the HTTP Priority Parameters Registry operates two registration policies values, the "HTTP Priority" registry operates two registration policies,
depending on key length.</t> depending on key length.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Registration requests for priority parameters with a key length of one use the <li>Registration requests for priority parameters with a key length of one use the
Specification Required policy, as per <xref section="4.6" sectionFormat="of" tar get="RFC8126" format="default"/>.</li> Specification Required policy, per <xref section="4.6" sectionFormat="of" target ="RFC8126" format="default"/>.</li>
<li>Registration requests for priority parameters with a key length greater than <li>Registration requests for priority parameters with a key length greater than
one use the Expert Review policy, as per <xref section="4.5" sectionFormat="of" one use the Expert Review policy, per <xref section="4.5" sectionFormat="of" tar
target="RFC8126" format="default"/>. A get="RFC8126" format="default"/>. A
specification document is appreciated, but not required.</li> specification document is appreciated but not required.</li>
</ul> </ul>
<t>When reviewing registration requests, the designated expert(s) can consider the <t>When reviewing registration requests, the designated expert(s) can consider the
additional guidance provided in <xref target="new-parameters" format="default"/> but cannot use it as a basis additional guidance provided in <xref target="new-parameters" format="default"/> but cannot use it as a basis
for rejection.</t> for rejection.</t>
<t>Registration requests should use the following template:</t> <t>Registration requests should use the following template:</t>
<dl> <dl>
<dt> <dt>
Name: </dt> Name: </dt>
<dd> <dd>
<t>[a name for the Priority Parameter that matches key]</t> <t>[a name for the priority parameter that matches the parameter k ey]</t>
</dd> </dd>
<dt> <dt>
Description: </dt> Description: </dt>
<dd> <dd>
<t>[a description of the priority parameter semantics and value]</ t> <t>[a description of the priority parameter semantics and value]</ t>
</dd> </dd>
<dt> <dt>
Reference: </dt> Reference: </dt>
<dd> <dd>
<t>[to a specification defining this priority parameter]</t> <t>[to a specification defining this priority parameter]</t>
</dd> </dd>
</dl> </dl>
<t>See the registry at <eref target="https://iana.org/assignments/http -priority">https://iana.org/assignments/http-priority</eref> for details on <t>See the registry at <eref target="https://www.iana.org/assignments/ http-priority" brackets="angle"/> for details on
where to send registration requests.</t> where to send registration requests.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="header-field" numbered="true" toc="default"> <section anchor="header-field" numbered="true" toc="default">
<name>The Priority HTTP Header Field</name> <name>The Priority HTTP Header Field</name>
<t>The Priority HTTP header field carries priority parameters (see <xref t arget="parameters" format="default"/>). <t>The Priority HTTP header field is a Dictionary that carries priority pa rameters (see <xref target="parameters" format="default"/>).
It can appear in requests and responses. It is an end-to-end signal that It can appear in requests and responses. It is an end-to-end signal that
indicates the endpoint's view of how HTTP responses should be prioritized. indicates the endpoint's view of how HTTP responses should be prioritized.
<xref target="merging" format="default"/> describes how intermediaries can combi ne the priority information <xref target="merging" format="default"/> describes how intermediaries can combi ne the priority information
sent from clients and servers. Clients cannot interpret the appearance or sent from clients and servers. Clients cannot interpret the appearance or
omission of a Priority response header field as acknowledgement that any omission of a Priority response header field as acknowledgement that any
prioritization has occurred. Guidance for how endpoints can act on Priority prioritization has occurred. Guidance for how endpoints can act on Priority
header values is given in <xref target="client-scheduling" format="default"/> an header values is given in Sections&nbsp;<xref target="client-scheduling" format=
d <xref target="server-scheduling" format="default"/>.</t> "counter"/> and <xref target="server-scheduling" format="counter"/>.</t>
<t>Priority is a Dictionary (<xref section="3.2" sectionFormat="of" target <t>An HTTP request with a Priority header field might be cached and reused
="STRUCTURED-FIELDS" format="default"/>):</t> for
<sourcecode type="abnf"><![CDATA[
Priority = sf-dictionary
]]></sourcecode>
<t>An HTTP request with a Priority header field might be cached and re-use
d for
subsequent requests; see <xref target="CACHING" format="default"/>. When an orig in subsequent requests; see <xref target="CACHING" format="default"/>. When an orig in
server generates the Priority response header field based on properties of an server generates the Priority response header field based on properties of an
HTTP request it receives, the server is expected to control the cacheability or HTTP request it receives, the server is expected to control the cacheability or
the applicability of the cached response, by using header fields that control the applicability of the cached response by using header fields that control
the caching behavior (e.g., Cache-Control, Vary).</t> the caching behavior (e.g., Cache-Control, Vary).</t>
</section> </section>
<section anchor="reprioritization" numbered="true" toc="default"> <section anchor="reprioritization" numbered="true" toc="default">
<name>Reprioritization</name> <name>Reprioritization</name>
<t>After a client sends a request, it may be beneficial to change the prio rity of <t>After a client sends a request, it may be beneficial to change the prio rity of
the response. As an example, a web browser might issue a prefetch request for a the response. As an example, a web browser might issue a prefetch request for a
JavaScript file with the urgency parameter of the Priority request header field JavaScript file with the urgency parameter of the Priority request header field
set to <tt>u=7</tt> (background). Then, when the user navigates to a page which set to <tt>u=7</tt> (background). Then, when the user navigates to a page that
references the new JavaScript file, while the prefetch is in progress, the references the new JavaScript file, while the prefetch is in progress, the
browser would send a reprioritization signal with the priority field value set browser would send a reprioritization signal with the Priority Field Value set
to <tt>u=0</tt>. The PRIORITY_UPDATE frame (<xref target="frame" format="default "/>) can be used for such to <tt>u=0</tt>. The PRIORITY_UPDATE frame (<xref target="frame" format="default "/>) can be used for such
reprioritization.</t> reprioritization.</t>
</section> </section>
<section anchor="frame" numbered="true" toc="default"> <section anchor="frame" numbered="true" toc="default">
<name>The PRIORITY_UPDATE Frame</name> <name>The PRIORITY_UPDATE Frame</name>
<t>This document specifies a new PRIORITY_UPDATE frame for HTTP/2 <xref ta rget="HTTP2" format="default"/> <t>This document specifies a new PRIORITY_UPDATE frame for HTTP/2 <xref ta rget="HTTP2" format="default"/>
and HTTP/3 <xref target="HTTP3" format="default"/>. It carries priority paramete rs and and HTTP/3 <xref target="HTTP3" format="default"/>. It carries priority paramete rs and
references the target of the prioritization based on a version-specific references the target of the prioritization based on a version-specific
identifier. In HTTP/2, this identifier is the Stream ID; in HTTP/3, the identifier. In HTTP/2, this identifier is the stream ID; in HTTP/3, the
identifier is either the Stream ID or Push ID. Unlike the Priority header field, identifier is either the stream ID or push ID. Unlike the Priority header field,
the PRIORITY_UPDATE frame is a hop-by-hop signal.</t> the PRIORITY_UPDATE frame is a hop-by-hop signal.</t>
<t>PRIORITY_UPDATE frames are sent by clients on the control stream, allow ing them <t>PRIORITY_UPDATE frames are sent by clients on the control stream, allow ing them
to be sent independent of the stream that carries the response. This means to be sent independently of the stream that carries the response. This means
they can be used to reprioritize a response or a push stream; or signal the they can be used to reprioritize a response or a push stream, or to signal the
initial priority of a response instead of the Priority header field.</t> initial priority of a response instead of the Priority header field.</t>
<t>A PRIORITY_UPDATE frame communicates a complete set of all priority par ameters <t>A PRIORITY_UPDATE frame communicates a complete set of all priority par ameters
in the Priority Field Value field. Omitting a priority parameter is a signal to in the Priority Field Value field. Omitting a priority parameter is a signal to
use its default value. Failure to parse the Priority Field Value <bcp14>MAY</bcp 14> be treated use its default value. Failure to parse the Priority Field Value <bcp14>MAY</bcp 14> be treated
as a connection error. In HTTP/2 the error is of type PROTOCOL_ERROR; in HTTP/3 as a connection error. In HTTP/2, the error is of type PROTOCOL_ERROR; in HTTP/3 ,
the error is of type H3_GENERAL_PROTOCOL_ERROR.</t> the error is of type H3_GENERAL_PROTOCOL_ERROR.</t>
<t>A client <bcp14>MAY</bcp14> send a PRIORITY_UPDATE frame before the str eam that it references <t>A client <bcp14>MAY</bcp14> send a PRIORITY_UPDATE frame before the str eam that it references
is open (except for HTTP/2 push streams; see <xref target="h2-update-frame" form at="default"/>). Furthermore, is open (except for HTTP/2 push streams; see <xref target="h2-update-frame" form at="default"/>). Furthermore,
HTTP/3 offers no guaranteed ordering across streams, which could cause the frame HTTP/3 offers no guaranteed ordering across streams, which could cause the frame
to be received earlier than intended. Either case leads to a race condition to be received earlier than intended. Either case leads to a race condition
where a server receives a PRIORITY_UPDATE frame that references a request stream where a server receives a PRIORITY_UPDATE frame that references a request stream
that is yet to be opened. To solve this condition, for the purposes of that is yet to be opened. To solve this condition, for the purposes of
scheduling, the most recently received PRIORITY_UPDATE frame can be considered scheduling, the most recently received PRIORITY_UPDATE frame can be considered
as the most up-to-date information that overrides any other signal. Servers as the most up-to-date information that overrides any other signal. Servers
<bcp14>SHOULD</bcp14> buffer the most recently received PRIORITY_UPDATE frame an d apply it once <bcp14>SHOULD</bcp14> buffer the most recently received PRIORITY_UPDATE frame an d apply it once
skipping to change at line 445 skipping to change at line 426
<name>HTTP/2 PRIORITY_UPDATE Frame</name> <name>HTTP/2 PRIORITY_UPDATE Frame</name>
<t>The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to si gnal the <t>The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to si gnal the
initial priority of a response, or to reprioritize a response or push stream. It initial priority of a response, or to reprioritize a response or push stream. It
carries the stream ID of the response and the priority in ASCII text, using the carries the stream ID of the response and the priority in ASCII text, using the
same representation as the Priority header field value.</t> same representation as the Priority header field value.</t>
<t>The Stream Identifier field (see <xref section="5.1.1" sectionFormat= "of" target="HTTP2" format="default"/>) in the <t>The Stream Identifier field (see <xref section="5.1.1" sectionFormat= "of" target="HTTP2" format="default"/>) in the
PRIORITY_UPDATE frame header <bcp14>MUST</bcp14> be zero (0x0). Receiving a PRIO RITY_UPDATE PRIORITY_UPDATE frame header <bcp14>MUST</bcp14> be zero (0x0). Receiving a PRIO RITY_UPDATE
frame with a field of any other value <bcp14>MUST</bcp14> be treated as a connec tion error of frame with a field of any other value <bcp14>MUST</bcp14> be treated as a connec tion error of
type PROTOCOL_ERROR.</t> type PROTOCOL_ERROR.</t>
<figure anchor="fig-h2-reprioritization-frame"> <figure anchor="fig-h2-reprioritization-frame">
<name>HTTP/2 PRIORITY_UPDATE Frame Payload</name> <name>HTTP/2 PRIORITY_UPDATE Frame Format</name>
<sourcecode type="drawing"><![CDATA[ <artwork type=""><![CDATA[
HTTP/2 PRIORITY_UPDATE Frame { HTTP/2 PRIORITY_UPDATE Frame {
Length (24), Length (24),
Type (8) = 0x10, Type (8) = 0x10,
Unused Flags (8). Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Reserved (1), Reserved (1),
Prioritized Stream ID (31), Prioritized Stream ID (31),
Priority Field Value (..), Priority Field Value (..),
} }
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie lds are <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie lds are
described in <xref section="4" sectionFormat="of" target="HTTP2" format="default "/>. The PRIORITY_UPDATE frame payload described in <xref section="4" sectionFormat="of" target="HTTP2" format="default "/>. The PRIORITY_UPDATE frame payload
contains the following additional fields:</t> contains the following additional fields:</t>
<dl> <dl>
<dt> <dt>
Reserved: </dt>
<dd>
<t>A reserved 1-bit field. The semantics of this bit are undefined.
It <bcp14>MUST</bcp14>
remain unset (0x0) when sending and <bcp14>MUST</bcp14> be ignored when receivin
g.</t>
</dd>
<dt>
Prioritized Stream ID: </dt> Prioritized Stream ID: </dt>
<dd> <dd>
<t>A 31-bit stream identifier for the stream that is the target of t he priority <t>A 31-bit stream identifier for the stream that is the target of t he priority
update.</t> update.</t>
</dd> </dd>
<dt> <dt>
Priority Field Value: </dt> Priority Field Value: </dt>
<dd> <dd>
<t>The priority update value in ASCII text, encoded using Structured Fields. This <t>The priority update value in ASCII text, encoded using Structured Fields. This
is the same representation as the Priority header field value.</t> is the same representation as the Priority header field value.</t>
</dd> </dd>
</dl> </dl>
<t>When the PRIORITY_UPDATE frame applies to a request stream, clients < bcp14>SHOULD</bcp14> <t>When the PRIORITY_UPDATE frame applies to a request stream, clients < bcp14>SHOULD</bcp14>
provide a Prioritized Stream ID that refers to a stream in the "open", provide a prioritized stream ID that refers to a stream in the "open",
"half-closed (local)", or "idle" state. Servers can discard frames where the "half-closed (local)", or "idle" state (i.e., streams where data might still be
Prioritized Stream ID refers to a stream in the "half-closed (local)" or received). Servers can discard frames where the
"closed" state. The number of streams which have been prioritized but remain in prioritized stream ID refers to a stream in the "half-closed (local)" or
the "idle" state plus the number of active streams (those in the "open" or "closed" state (i.e., streams where no further data will be sent).
either "half-closed" state; see <xref section="5.1.2" sectionFormat="of" target= The number of streams that have been prioritized but remain in
"HTTP2" format="default"/>) <bcp14>MUST NOT</bcp14> exceed the "idle" state plus the number of active streams (those in the "open" state or
in either of the "half-closed" states; see <xref section="5.1.2" sectionFormat="
of" target="HTTP2" format="default"/>) <bcp14>MUST NOT</bcp14> exceed
the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter. Servers that receive the value of the SETTINGS_MAX_CONCURRENT_STREAMS parameter. Servers that receive
such a PRIORITY_UPDATE <bcp14>MUST</bcp14> respond with a connection error of ty pe such a PRIORITY_UPDATE <bcp14>MUST</bcp14> respond with a connection error of ty pe
PROTOCOL_ERROR.</t> PROTOCOL_ERROR.</t>
<t>When the PRIORITY_UPDATE frame applies to a push stream, clients <bcp 14>SHOULD</bcp14> provide <t>When the PRIORITY_UPDATE frame applies to a push stream, clients <bcp 14>SHOULD</bcp14> provide
a Prioritized Stream ID that refers to a stream in the "reserved (remote)" or a prioritized stream ID that refers to a stream in the "reserved (remote)" or
"half-closed (local)" state. Servers can discard frames where the Prioritized "half-closed (local)" state. Servers can discard frames where the prioritized
Stream ID refers to a stream in the "closed" state. Clients <bcp14>MUST NOT</bcp stream ID refers to a stream in the "closed" state. Clients <bcp14>MUST NOT</bcp
14> provide a 14> provide a
Prioritized Stream ID that refers to a push stream in the "idle" state. Servers prioritized stream ID that refers to a push stream in the "idle" state. Servers
that receive a PRIORITY_UPDATE for a push stream in the "idle" state <bcp14>MUST </bcp14> that receive a PRIORITY_UPDATE for a push stream in the "idle" state <bcp14>MUST </bcp14>
respond with a connection error of type PROTOCOL_ERROR.</t> respond with a connection error of type PROTOCOL_ERROR.</t>
<t>If a PRIORITY_UPDATE frame is received with a Prioritized Stream ID o f 0x0, the <t>If a PRIORITY_UPDATE frame is received with a prioritized stream ID o f 0x0, the
recipient <bcp14>MUST</bcp14> respond with a connection error of type PROTOCOL_E RROR.</t> recipient <bcp14>MUST</bcp14> respond with a connection error of type PROTOCOL_E RROR.</t>
<t>Servers <bcp14>MUST NOT</bcp14> send PRIORITY_UPDATE frames. If a cli ent receives a <t>Servers <bcp14>MUST NOT</bcp14> send PRIORITY_UPDATE frames. If a cli ent receives a
PRIORITY_UPDATE frame, it <bcp14>MUST</bcp14> respond with a connection error of type PRIORITY_UPDATE frame, it <bcp14>MUST</bcp14> respond with a connection error of type
PROTOCOL_ERROR.</t> PROTOCOL_ERROR.</t>
</section> </section>
<section anchor="h3-update-frame" numbered="true" toc="default"> <section anchor="h3-update-frame" numbered="true" toc="default">
<name>HTTP/3 PRIORITY_UPDATE Frame</name> <name>HTTP/3 PRIORITY_UPDATE Frame</name>
<t>The HTTP/3 PRIORITY_UPDATE frame (type=0xF0700 or 0xF0701) is used by clients to <t>The HTTP/3 PRIORITY_UPDATE frame (type=0xF0700 or 0xF0701) is used by clients to
signal the initial priority of a response, or to reprioritize a response or push signal the initial priority of a response, or to reprioritize a response or push
stream. It carries the identifier of the element that is being prioritized and stream. It carries the identifier of the element that is being prioritized and
the updated priority in ASCII text that uses the same representation as that of the updated priority in ASCII text that uses the same representation as that of
the Priority header field value. PRIORITY_UPDATE with a frame type of 0xF0700 is the Priority header field value. PRIORITY_UPDATE with a frame type of 0xF0700 is
used for request streams, while PRIORITY_UPDATE with a frame type of 0xF0701 is used for request streams, while PRIORITY_UPDATE with a frame type of 0xF0701 is
used for push streams.</t> used for push streams.</t>
<t>The PRIORITY_UPDATE frame <bcp14>MUST</bcp14> be sent on the client c ontrol stream <t>The PRIORITY_UPDATE frame <bcp14>MUST</bcp14> be sent on the client c ontrol stream
(see <xref section="6.2.1" sectionFormat="of" target="HTTP3" format="default"/>) . Receiving a PRIORITY_UPDATE frame on a (see <xref section="6.2.1" sectionFormat="of" target="HTTP3" format="default"/>) . Receiving a PRIORITY_UPDATE frame on a
stream other than the client control stream <bcp14>MUST</bcp14> be treated as a connection stream other than the client control stream <bcp14>MUST</bcp14> be treated as a connection
error of type H3_FRAME_UNEXPECTED.</t> error of type H3_FRAME_UNEXPECTED.</t>
<figure anchor="fig-h3-reprioritization-frame"> <figure anchor="fig-h3-reprioritization-frame">
<name>HTTP/3 PRIORITY_UPDATE Frame</name> <name>HTTP/3 PRIORITY_UPDATE Frame</name>
<sourcecode type="drawing"><![CDATA[ <artwork type=""><![CDATA[
HTTP/3 PRIORITY_UPDATE Frame { HTTP/3 PRIORITY_UPDATE Frame {
Type (i) = 0xF0700..0xF0701, Type (i) = 0xF0700..0xF0701,
Length (i), Length (i),
Prioritized Element ID (i), Prioritized Element ID (i),
Priority Field Value (..), Priority Field Value (..),
} }
]]></sourcecode> ]]></artwork>
</figure> </figure>
<t>The PRIORITY_UPDATE frame payload has the following fields:</t> <t>The PRIORITY_UPDATE frame payload has the following fields:</t>
<dl> <dl>
<dt> <dt>
Prioritized Element ID: </dt> Prioritized Element ID: </dt>
<dd> <dd>
<t>The stream ID or push ID that is the target of the priority updat e.</t> <t>The stream ID or push ID that is the target of the priority updat e.</t>
</dd> </dd>
<dt> <dt>
Priority Field Value: </dt> Priority Field Value: </dt>
<dd> <dd>
<t>The priority update value in ASCII text, encoded using Structured Fields. This <t>The priority update value in ASCII text, encoded using Structured Fields. This
is the same representation as the Priority header field value.</t> is the same representation as the Priority header field value.</t>
</dd> </dd>
</dl> </dl>
<t>The request-stream variant of PRIORITY_UPDATE (type=0xF0700) <bcp14>M UST</bcp14> reference a <t>The request-stream variant of PRIORITY_UPDATE (type=0xF0700) <bcp14>M UST</bcp14> reference a
request stream. If a server receives a PRIORITY_UPDATE (type=0xF0700) for a request stream. If a server receives a PRIORITY_UPDATE (type=0xF0700) for a
Stream ID that is not a request stream, this <bcp14>MUST</bcp14> be treated as a stream ID that is not a request stream, this <bcp14>MUST</bcp14> be treated as a
connection connection
error of type H3_ID_ERROR. The Stream ID <bcp14>MUST</bcp14> be within the clien error of type H3_ID_ERROR. The stream ID <bcp14>MUST</bcp14> be within the clien
t-initiated t-initiated
bidirectional stream limit. If a server receives a PRIORITY_UPDATE bidirectional stream limit. If a server receives a PRIORITY_UPDATE
(type=0xF0700) with a Stream ID that is beyond the stream limits, this <bcp14>SH OULD</bcp14> be (type=0xF0700) with a stream ID that is beyond the stream limits, this <bcp14>SH OULD</bcp14> be
treated as a connection error of type H3_ID_ERROR. Generating an error is not treated as a connection error of type H3_ID_ERROR. Generating an error is not
mandatory because HTTP/3 implementations might have practical barriers to mandatory because HTTP/3 implementations might have practical barriers to
determining the active stream concurrency limit that is applied by the QUIC determining the active stream concurrency limit that is applied by the QUIC
layer.</t> layer.</t>
<t>The push-stream variant PRIORITY_UPDATE (type=0xF0701) <bcp14>MUST</b <t>The push-stream variant of PRIORITY_UPDATE (type=0xF0701) <bcp14>MUST
cp14> reference a promised </bcp14> reference a promised
push stream. If a server receives a PRIORITY_UPDATE (type=0xF0701) with a Push I push stream. If a server receives a PRIORITY_UPDATE (type=0xF0701) with a push I
D D
that is greater than the maximum Push ID or which has not yet been promised, thi that is greater than the maximum push ID or that has not yet been promised, this
s
<bcp14>MUST</bcp14> be treated as a connection error of type H3_ID_ERROR.</t> <bcp14>MUST</bcp14> be treated as a connection error of type H3_ID_ERROR.</t>
<t>Servers <bcp14>MUST NOT</bcp14> send PRIORITY_UPDATE frames of either type. If a client <t>Servers <bcp14>MUST NOT</bcp14> send PRIORITY_UPDATE frames of either type. If a client
receives a PRIORITY_UPDATE frame, this <bcp14>MUST</bcp14> be treated as a conne ction error of receives a PRIORITY_UPDATE frame, this <bcp14>MUST</bcp14> be treated as a conne ction error of
type H3_FRAME_UNEXPECTED.</t> type H3_FRAME_UNEXPECTED.</t>
</section> </section>
</section> </section>
<section anchor="merging" numbered="true" toc="default"> <section anchor="merging" numbered="true" toc="default">
<name>Merging Client- and Server-Driven Priority Parameters</name> <name>Merging Client- and Server-Driven Priority Parameters</name>
<t>It is not always the case that the client has the best understanding of how the <t>It is not always the case that the client has the best understanding of how the
HTTP responses deserve to be prioritized. The server might have additional HTTP responses deserve to be prioritized. The server might have additional
information that can be combined with the client's indicated priority in order information that can be combined with the client's indicated priority in order
to improve the prioritization of the response. For example, use of an HTML to improve the prioritization of the response. For example, use of an HTML
document might depend heavily on one of the inline images; existence of such document might depend heavily on one of the inline images; the existence of such
dependencies is typically best known to the server. Or, a server that receives dependencies is typically best known to the server. Or, a server that receives
requests for a font <xref target="RFC8081" format="default"/> and images with th e same urgency might give requests for a font <xref target="RFC8081" format="default"/> and images with th e same urgency might give
higher precedence to the font, so that a visual client can render textual higher precedence to the font, so that a visual client can render textual
information at an early moment.</t> information at an early moment.</t>
<t>An origin can use the Priority response header field to indicate its vi ew on how <t>An origin can use the Priority response header field to indicate its vi ew on how
an HTTP response should be prioritized. An intermediary that forwards an HTTP an HTTP response should be prioritized. An intermediary that forwards an HTTP
response can use the priority parameters found in the Priority response header response can use the priority parameters found in the Priority response header
field, in combination with the client Priority request header field, as input to field, in combination with the client Priority request header field, as input to
its prioritization process. No guidance is provided for merging priorities; this its prioritization process. No guidance is provided for merging priorities; this
is left as an implementation decision.</t> is left as an implementation decision.</t>
<t>Absence of a priority parameter in an HTTP response indicates the serve r's <t>The absence of a priority parameter in an HTTP response indicates the s erver's
disinterest in changing the client-provided value. This is different from the disinterest in changing the client-provided value. This is different from the
request header field, in which omission of a priority parameter implies the use request header field, in which omission of a priority parameter implies the use
of their default values (see <xref target="parameters" format="default"/>).</t> of its default value (see <xref target="parameters" format="default"/>).</t>
<t>As a non-normative example, when the client sends an HTTP request with the <t>As a non-normative example, when the client sends an HTTP request with the
urgency parameter set to <tt>5</tt> and the incremental parameter set to <tt>tru e</tt></t> urgency parameter set to <tt>5</tt> and the incremental parameter set to <tt>tru e</tt></t>
<sourcecode type="example"><![CDATA[ <artwork type=""><![CDATA[
:method = GET :method = GET
:scheme = https :scheme = https
:authority = example.net :authority = example.net
:path = /menu.png :path = /menu.png
priority = u=5, i priority = u=5, i
]]></sourcecode> ]]></artwork>
<t>and the origin responds with</t> <t>and the origin responds with</t>
<sourcecode type="example"><![CDATA[ <artwork type=""><![CDATA[
:status = 200 :status = 200
content-type = image/png content-type = image/png
priority = u=1 priority = u=1
]]></sourcecode> ]]></artwork>
<t>the intermediary might alter its understanding of the urgency from <tt> 5</tt> to <tt>1</tt>, <t>the intermediary might alter its understanding of the urgency from <tt> 5</tt> to <tt>1</tt>,
because it prefers the server-provided value over the client's. The incremental because it prefers the server-provided value over the client's. The incremental
value continues to be <tt>true</tt>, the value specified by the client, as the s value continues to be <tt>true</tt>, i.e., the value specified by the client, as
erver did the server did
not specify the incremental(<tt>i</tt>) parameter.</t> not specify the incremental (<tt>i</tt>) parameter.</t>
</section> </section>
<section anchor="client-scheduling" numbered="true" toc="default"> <section anchor="client-scheduling" numbered="true" toc="default">
<name>Client Scheduling</name> <name>Client Scheduling</name>
<t>A client <bcp14>MAY</bcp14> use priority values to make local processin g or scheduling choices <t>A client <bcp14>MAY</bcp14> use priority values to make local processin g or scheduling choices
about the requests it initiates.</t> about the requests it initiates.</t>
</section> </section>
<section anchor="server-scheduling" numbered="true" toc="default"> <section anchor="server-scheduling" numbered="true" toc="default">
<name>Server Scheduling</name> <name>Server Scheduling</name>
<t>It is generally beneficial for an HTTP server to send all responses as early as <t>It is generally beneficial for an HTTP server to send all responses as early as
possible. However, when serving multiple requests on a single connection, there possible. However, when serving multiple requests on a single connection, there
skipping to change at line 629 skipping to change at line 604
<t>Server scheduling is a prioritization process based on many inputs, wit h <t>Server scheduling is a prioritization process based on many inputs, wit h
priority signals being only one form of input. Factors such as implementation priority signals being only one form of input. Factors such as implementation
choices or deployment environment also play a role. Any given connection is choices or deployment environment also play a role. Any given connection is
likely to have many dynamic permutations. For these reasons, it is not possible likely to have many dynamic permutations. For these reasons, it is not possible
to describe a universal scheduling algorithm. This document provides some basic, to describe a universal scheduling algorithm. This document provides some basic,
non-exhaustive recommendations for how servers might act on priority non-exhaustive recommendations for how servers might act on priority
parameters. It does not describe in detail how servers might combine priority parameters. It does not describe in detail how servers might combine priority
signals with other factors. Endpoints cannot depend on particular treatment signals with other factors. Endpoints cannot depend on particular treatment
based on priority signals. Expressing priority is only a suggestion.</t> based on priority signals. Expressing priority is only a suggestion.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that, when possible, servers respect t he urgency parameter <t>It is <bcp14>RECOMMENDED</bcp14> that, when possible, servers respect t he urgency parameter
(<xref target="urgency" format="default"/>), sending higher urgency responses be fore lower urgency responses.</t> (<xref target="urgency" format="default"/>), sending higher-urgency responses be fore lower-urgency responses.</t>
<t>The incremental parameter indicates how a client processes response byt es as <t>The incremental parameter indicates how a client processes response byt es as
they arrive. It is <bcp14>RECOMMENDED</bcp14> that, when possible, servers respe ct the they arrive. It is <bcp14>RECOMMENDED</bcp14> that, when possible, servers respe ct the
incremental parameter (<xref target="incremental" format="default"/>).</t> incremental parameter (<xref target="incremental" format="default"/>).</t>
<t>Non-incremental responses of the same urgency <bcp14>SHOULD</bcp14> be served by prioritizing <t>Non-incremental responses of the same urgency <bcp14>SHOULD</bcp14> be served by prioritizing
bandwidth allocation in ascending order of the stream ID, which corresponds to bandwidth allocation in ascending order of the stream ID, which corresponds to
the order in which clients make requests. Doing so ensures that clients can use the order in which clients make requests. Doing so ensures that clients can use
request ordering to influence response order.</t> request ordering to influence response order.</t>
<t>Incremental responses of the same urgency <bcp14>SHOULD</bcp14> be serv ed by sharing bandwidth <t>Incremental responses of the same urgency <bcp14>SHOULD</bcp14> be serv ed by sharing bandwidth
among them. Payload of incremental responses are used in parts, or chunks, as among them. The message content of incremental responses is used as parts, or ch
they are received. A client might benefit more from receiving a portion of all unks,
are received. A client might benefit more from receiving a portion of all
these resources rather than the entirety of a single resource. How large a these resources rather than the entirety of a single resource. How large a
portion of the resource is needed to be useful in improving performance varies. portion of the resource is needed to be useful in improving performance varies.
Some resource types place critical elements early; others can use information Some resource types place critical elements early; others can use information
progressively. This scheme provides no explicit mandate about how a server progressively. This scheme provides no explicit mandate about how a server
should use size, type or any other input to decide how to prioritize.</t> should use size, type, or any other input to decide how to prioritize.</t>
<t>There can be scenarios where a server will need to schedule multiple in cremental <t>There can be scenarios where a server will need to schedule multiple in cremental
and non-incremental responses at the same urgency level. Strictly abiding the and non-incremental responses at the same urgency level. Strictly abiding by the
scheduling guidance based on urgency and request generation order might lead scheduling guidance based on urgency and request generation order might lead
to suboptimal results at the client, as early non-incremental responses might to suboptimal results at the client, as early non-incremental responses might
prevent serving of incremental responses issued later. The following are prevent the serving of incremental responses issued later. The following are
examples of such challenges.</t> examples of such challenges:</t>
<ol spacing="normal" type="1"><li>At the same urgency level, a non-increme ntal request for a large resource <ol spacing="normal" type="1"><li>At the same urgency level, a non-increme ntal request for a large resource
followed by an incremental request for a small resource.</li> followed by an incremental request for a small resource.</li>
<li>At the same urgency level, an incremental request of indeterminate l ength <li>At the same urgency level, an incremental request of indeterminate l ength
followed by a non-incremental large resource.</li> followed by a non-incremental large resource.</li>
</ol> </ol>
<t>It is <bcp14>RECOMMENDED</bcp14> that servers avoid such starvation whe re possible. The method <t>It is <bcp14>RECOMMENDED</bcp14> that servers avoid such starvation whe re possible. The method
to do so is an implementation decision. For example, a server might for doing so is an implementation decision. For example, a server might
pre-emptively send responses of a particular incremental type based on other preemptively send responses of a particular incremental type based on other
information such as content size.</t> information such as content size.</t>
<t>Optimal scheduling of server push is difficult, especially when pushed resources <t>Optimal scheduling of server push is difficult, especially when pushed resources
contend with active concurrent requests. Servers can consider many factors when contend with active concurrent requests. Servers can consider many factors when
scheduling, such as the type or size of resource being pushed, the priority of scheduling, such as the type or size of resource being pushed, the priority of
the request that triggered the push, the count of active concurrent responses, the request that triggered the push, the count of active concurrent responses,
the priority of other active concurrent responses, etc. There is no general the priority of other active concurrent responses, etc. There is no general
guidance on the best way to apply these. A server that is too simple could guidance on the best way to apply these. A server that is too simple could
easily push at too high a priority and block client requests, or push at too low easily push at too high a priority and block client requests, or push at too low
a priority and delay the response, negating intended goals of server push.</t> a priority and delay the response, negating intended goals of server push.</t>
<t>Priority signals are a factor for server push scheduling. The concept o f <t>Priority signals are a factor for server push scheduling. The concept o f
parameter value defaults applies slightly differently because there is no parameter value defaults applies slightly differently because there is no
explicit client-signalled initial priority. A server can apply priority signals explicit client-signaled initial priority. A server can apply priority signals
provided in an origin response; see the merging guidance given in <xref target=" merging" format="default"/>. provided in an origin response; see the merging guidance given in <xref target=" merging" format="default"/>.
In the absence of origin signals, applying default parameter values could be In the absence of origin signals, applying default parameter values could be
suboptimal. By whatever means a server decides to schedule a pushed response, it suboptimal. By whatever means a server decides to schedule a pushed response, it
can signal the intended priority to the client by including the Priority field can signal the intended priority to the client by including the Priority field
in a PUSH_PROMISE or HEADERS frame.</t> in a PUSH_PROMISE or HEADERS frame.</t>
<section anchor="intermediaries-with-multiple-backend-connections" numbere d="true" toc="default"> <section anchor="intermediaries-with-multiple-backend-connections" numbere d="true" toc="default">
<name>Intermediaries with Multiple Backend Connections</name> <name>Intermediaries with Multiple Backend Connections</name>
<t>An intermediary serving an HTTP connection might split requests over multiple <t>An intermediary serving an HTTP connection might split requests over multiple
backend connections. When it applies prioritization rules strictly, low priority backend connections. When it applies prioritization rules strictly, low-priority
requests cannot make progress while requests with higher priorities are in requests cannot make progress while requests with higher priorities are in
flight. This blocking can propagate to backend connections, which the peer might flight. This blocking can propagate to backend connections, which the peer might
interpret as a connection stall. Endpoints often implement protections against interpret as a connection stall. Endpoints often implement protections against
stalls, such as abruptly closing connections after a certain time period. To stalls, such as abruptly closing connections after a certain time period. To
reduce the possibility of this occurring, intermediaries can avoid strictly reduce the possibility of this occurring, intermediaries can avoid strictly
following prioritization and instead allocate small amounts of bandwidth for all following prioritization and instead allocate small amounts of bandwidth for all
the requests that they are forwarding, so that every request can make some the requests that they are forwarding, so that every request can make some
progress over time.</t> progress over time.</t>
<t>Similarly, servers <bcp14>SHOULD</bcp14> allocate some amount of band widths to streams acting <t>Similarly, servers <bcp14>SHOULD</bcp14> allocate some amount of band widths to streams acting
as tunnels.</t> as tunnels.</t>
</section> </section>
</section> </section>
<section anchor="connect-scheduling" numbered="true" toc="default"> <section anchor="connect-scheduling" numbered="true" toc="default">
<name>Scheduling and the CONNECT Method</name> <name>Scheduling and the CONNECT Method</name>
<t>When a request stream carries the CONNECT method, the scheduling guidan <t>When a stream carries a CONNECT request, the scheduling guidance in
ce in this document applies to the frames on the stream. A client that issues multipl
this document applies to the frames on the stream. A client that issues multiple e
CONNECT requests can set the incremental parameter to <tt>true</tt>. Servers tha t CONNECT requests can set the incremental parameter to <tt>true</tt>. Servers tha t
implement the recommendations for handling of the incremental parameter in implement the recommendations for handling of the incremental parameter (<xref t
<xref target="server-scheduling" format="default"/> are likely to schedule these arget="server-scheduling" format="default"/>) are likely to schedule these fairl
fairly, avoiding one y, preventing one
CONNECT stream from blocking others.</t> CONNECT stream from blocking others.</t>
</section> </section>
<section anchor="retransmission-scheduling" numbered="true" toc="default"> <section anchor="retransmission-scheduling" numbered="true" toc="default">
<name>Retransmission Scheduling</name> <name>Retransmission Scheduling</name>
<t>Transport protocols such as TCP and QUIC provide reliability by detecti ng packet <t>Transport protocols such as TCP and QUIC provide reliability by detecti ng packet
losses and retransmitting lost information. In addition to the considerations in losses and retransmitting lost information. In addition to the considerations in
<xref target="server-scheduling" format="default"/>, scheduling of retransmissio n data could compete with new <xref target="server-scheduling" format="default"/>, scheduling of retransmissio n data could compete with new
data. The remainder of this section discusses considerations when using QUIC.</t > data. The remainder of this section discusses considerations when using QUIC.</t >
<t><xref section="13.3" sectionFormat="of" target="QUIC" format="default"/ > states "Endpoints <bcp14>SHOULD</bcp14> prioritize <t><xref section="13.3" sectionFormat="of" target="QUIC" format="default"/ > states the following: "Endpoints <bcp14>SHOULD</bcp14> prioritize
retransmission of data over sending new data, unless priorities specified by the retransmission of data over sending new data, unless priorities specified by the
application indicate otherwise". When an HTTP/3 application uses the priority application indicate otherwise". When an HTTP/3 application uses the priority
scheme defined in this document and the QUIC transport implementation supports scheme defined in this document and the QUIC transport implementation supports
application indicated stream priority, a transport that considers the relative application-indicated stream priority, a transport that considers the relative
priority of streams when scheduling both new data and retransmission data might priority of streams when scheduling both new data and retransmission data might
better match the expectations of the application. However, there are no better match the expectations of the application. However, there are no
requirements on how a transport chooses to schedule based on this information requirements on how a transport chooses to schedule based on this information
because the decision depends on several factors and trade-offs. It could because the decision depends on several factors and trade-offs. It could
prioritize new data for a higher urgency stream over retransmission data for a prioritize new data for a higher-urgency stream over retransmission data for a
lower priority stream, or it could prioritize retransmission data over new data lower-priority stream, or it could prioritize retransmission data over new data
irrespective of urgencies.</t> irrespective of urgencies.</t>
<t><xref section="6.2.4" sectionFormat="of" target="QUIC-RECOVERY" format= "default"/> also highlights consideration of <t><xref section="6.2.4" sectionFormat="of" target="QUIC-RECOVERY" format= "default"/> also highlights considerations regarding
application priorities when sending probe packets after Probe Timeout timer application priorities when sending probe packets after Probe Timeout timer
expiration. A QUIC implementation supporting application-indicated priorities expiration. A QUIC implementation supporting application-indicated priorities
might use the relative priority of streams when choosing probe data.</t> might use the relative priority of streams when choosing probe data.</t>
</section> </section>
<section anchor="fairness" numbered="true" toc="default"> <section anchor="fairness" numbered="true" toc="default">
<name>Fairness</name> <name>Fairness</name>
<t>Typically, HTTP implementations depend on the underlying transport to m aintain <t>Typically, HTTP implementations depend on the underlying transport to m aintain
fairness between connections competing for bandwidth. When HTTP requests are fairness between connections competing for bandwidth. When an intermediary recei
forwarded through intermediaries, progress made by each connection originating ves HTTP requests on client connections, it forwards them to backend connections
from end clients can become different over time, depending on how intermediaries . Depending on how the intermediary coalesces or splits requests across differen
coalesce or split requests into backend connections. This unfairness can expand t backend connections, different clients might experience dissimilar performance
if priority signals are used. <xref target="coalescing" format="default"/> and < . This dissimilarity might expand if the intermediary also uses priority signals
xref target="h1-backends" format="default"/> discuss when
mitigations against this expansion of unfairness.</t> forwarding requests. Sections&nbsp;<xref target="coalescing" format="counter"/>
and <xref target="h1-backends" format="counter"/> discuss
mitigations of this expansion of unfairness.</t>
<t>Conversely, <xref target="intentional-unfairness" format="default"/> di scusses how servers might intentionally <t>Conversely, <xref target="intentional-unfairness" format="default"/> di scusses how servers might intentionally
allocate unequal bandwidth to some connections depending on the priority allocate unequal bandwidth to some connections, depending on the priority
signals.</t> signals.</t>
<section anchor="coalescing" numbered="true" toc="default"> <section anchor="coalescing" numbered="true" toc="default">
<name>Coalescing Intermediaries</name> <name>Coalescing Intermediaries</name>
<t>When an intermediary coalesces HTTP requests coming from multiple cli ents into <t>When an intermediary coalesces HTTP requests coming from multiple cli ents into
one HTTP/2 or HTTP/3 connection going to the backend server, requests that one HTTP/2 or HTTP/3 connection going to the backend server, requests that
originate from one client might carry signals indicating higher priority than originate from one client might carry signals indicating higher priority than
those coming from others.</t> those coming from others.</t>
<t>It is sometimes beneficial for the server running behind an intermedi ary to obey <t>It is sometimes beneficial for the server running behind an intermedi ary to obey
Priority header field values. As an example, a resource-constrained Priority header field values. As an example, a resource-constrained
server might defer the transmission of software update files that have the server might defer the transmission of software update files that have the
background urgency. However, in the worst case, the asymmetry background urgency level (7). However, in the worst case, the asymmetry
between the priority declared by multiple clients might cause responses going to between the priority declared by multiple clients might cause all responses goin
one user agent to be delayed totally after those going to another.</t> g to
one user agent to be delayed until all responses going to another user agent hav
e
been sent.</t>
<t>In order to mitigate this fairness problem, a server could use knowle dge about <t>In order to mitigate this fairness problem, a server could use knowle dge about
the intermediary as another input in its prioritization decisions. For the intermediary as another input in its prioritization decisions. For
instance, if a server knows the intermediary is coalescing requests, then it instance, if a server knows the intermediary is coalescing requests, then it
could avoid serving the responses in their entirety and instead distribute could avoid serving the responses in their entirety and instead distribute
bandwidth (for example, in a round-robin manner). This can work if the bandwidth (for example, in a round-robin manner). This can work if the
constrained resource is network capacity between the intermediary and the user constrained resource is network capacity between the intermediary and the user
agent, as the intermediary buffers responses and forwards the chunks based on agent, as the intermediary buffers responses and forwards the chunks based on
the prioritization scheme it implements.</t> the prioritization scheme it implements.</t>
<t>A server can determine if a request came from an intermediary through <t>A server can determine if a request came from an intermediary through
configuration, or by consulting if that request contains one of the following configuration or can check to see if the request contains one of the following
header fields:</t> header fields:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Forwarded <xref target="FORWARDED" format="default"/>, X-Forwarded -For</li> <li>Forwarded <xref target="FORWARDED" format="default"/>, X-Forwarded -For</li>
<li>Via (see <xref section="7.6.3" sectionFormat="of" target="HTTP" fo rmat="default"/>)</li> <li>Via (see <xref section="7.6.3" sectionFormat="of" target="HTTP" fo rmat="default"/>)</li>
</ul> </ul>
</section> </section>
<section anchor="h1-backends" numbered="true" toc="default"> <section anchor="h1-backends" numbered="true" toc="default">
<name>HTTP/1.x Back Ends</name> <name>HTTP/1.x Back Ends</name>
<t>It is common for CDN infrastructure to support different HTTP version s on the <t>It is common for Content Delivery Network (CDN) infrastructure to sup port different HTTP versions on the
front end and back end. For instance, the client-facing edge might support front end and back end. For instance, the client-facing edge might support
HTTP/2 and HTTP/3 while communication to back end servers is done using HTTP/2 and HTTP/3 while communication to backend servers is done using
HTTP/1.1. Unlike with connection coalescing, the CDN will "de-mux" requests into HTTP/1.1. Unlike connection coalescing, the CDN will "demux" requests into
discrete connections to the back end. HTTP/1.1 and older do not support response discrete connections to the back end. Response multiplexing in a single connecti
multiplexing in a single connection, so there is not a fairness problem. on is not supported by HTTP/1.1 (or older), so there is not a fairness problem.
However, back end servers <bcp14>MAY</bcp14> still use client headers for reques However, backend servers <bcp14>MAY</bcp14> still use client headers for request
t scheduling. scheduling.
Back end servers <bcp14>SHOULD</bcp14> only schedule based on client priority in Backend servers <bcp14>SHOULD</bcp14> only schedule based on client priority inf
formation where ormation where
that information can be scoped to individual end clients. Authentication and that information can be scoped to individual end clients. Authentication and
other session information might provide this linkability.</t> other session information might provide this linkability.</t>
</section> </section>
<section anchor="intentional-unfairness" numbered="true" toc="default"> <section anchor="intentional-unfairness" numbered="true" toc="default">
<name>Intentional Introduction of Unfairness</name> <name>Intentional Introduction of Unfairness</name>
<t>It is sometimes beneficial to deprioritize the transmission of one co nnection <t>It is sometimes beneficial to deprioritize the transmission of one co nnection
over others, knowing that doing so introduces a certain amount of unfairness over others, knowing that doing so introduces a certain amount of unfairness
between the connections and therefore between the requests served on those between the connections and therefore between the requests served on those
connections.</t> connections.</t>
<t>For example, a server might use a scavenging congestion controller on <t>For example, a server might use a scavenging congestion controller on
connections that only convey background priority responses such as software connections that only convey background priority responses such as software
update images. Doing so improves responsiveness of other connections at the cost update images. Doing so improves responsiveness of other connections at the cost
of delaying the delivery of updates.</t> of delaying the delivery of updates.</t>
</section> </section>
</section> </section>
<section anchor="header-field-rationale" numbered="true" toc="default"> <section anchor="header-field-rationale" numbered="true" toc="default">
<name>Why use an End-to-End Header Field?</name> <name>Why Use an End-to-End Header Field?</name>
<t>In contrast to the prioritization scheme of HTTP/2 that uses a hop-by-h <t>In contrast to the prioritization scheme of HTTP/2, which uses a hop-by
op frame, -hop frame,
the Priority header field is defined as end-to-end.</t> the Priority header field is defined as "end-to-end".</t>
<t>The way that a client processes a response is a property associated wit h the <t>The way that a client processes a response is a property associated wit h the
client generating that request, not that of an intermediary. Therefore, it is client generating that request, not that of an intermediary. Therefore, it is
an end-to-end property. How these end-to-end properties carried by the Priority an end-to-end property. How these end-to-end properties carried by the Priority
header field affect the prioritization between the responses that share a header field affect the prioritization between the responses that share a
connection is a hop-by-hop issue.</t> connection is a hop-by-hop issue.</t>
<t>Having the Priority header field defined as end-to-end is important for caching <t>Having the Priority header field defined as end-to-end is important for caching
intermediaries. Such intermediaries can cache the value of the Priority header intermediaries. Such intermediaries can cache the value of the Priority header
field along with the response and utilize the value of the cached header field field along with the response and utilize the value of the cached header field
when serving the cached response, only because the header field is defined as when serving the cached response, only because the header field is defined as
end-to-end rather than hop-by-hop.</t> end-to-end rather than hop-by-hop.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t><xref target="frame" format="default"/> describes considerations for se rver buffering of PRIORITY_UPDATE <t><xref target="frame" format="default"/> describes considerations for se rver buffering of PRIORITY_UPDATE
frames.</t> frames.</t>
<t><xref target="server-scheduling" format="default"/> presents examples w here servers that prioritize responses <t><xref target="server-scheduling" format="default"/> presents examples w here servers that prioritize responses
in a certain way might be starved of the ability to transmit payload.</t> in a certain way might be starved of the ability to transmit responses.</t>
<t>The security considerations from <xref target="STRUCTURED-FIELDS" forma <t>The security considerations from <xref target="STRUCTURED-FIELDS" forma
t="default"/> apply to processing of t="default"/> apply to the processing of
priority parameters defined in <xref target="parameters" format="default"/>.</t> priority parameters defined in <xref target="parameters" format="default"/>.</t>
</section> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This specification registers the following entry in the Hypertext Trans <t>This specification registers the following entry in the "Hypertext Tran
fer sfer
Protocol (HTTP) Field Name Registry established by <xref target="HTTP" format="d Protocol (HTTP) Field Name Registry" defined in <xref target="HTTP2" format="def
efault"/>:</t> ault"/>:</t>
<dl> <dl spacing="compact">
<dt> <dt>
Field name: </dt> Field Name: </dt>
<dd> <dd>
<t>Priority</t> <t>Priority</t>
</dd> </dd>
<dt> <dt>
Status: </dt> Status: </dt>
<dd> <dd>
<t>permanent</t> <t>permanent</t>
</dd> </dd>
<dt> <dt>
Specification document(s): </dt> Reference: </dt>
<dd> <dd>
<t>This document</t> <t>This document</t>
</dd> </dd>
</dl> </dl>
<t>This specification registers the following entry in the HTTP/2 Settings <t>This specification registers the following entry in the "HTTP/2 Setting
registry s" registry
established by <xref target="RFC7540" format="default"/>:</t> defined in <xref target="HTTP2" format="default"/>:</t>
<dl> <dl spacing="compact">
<dt> <dt>
Name: </dt> Code: </dt>
<dd> <dd>
<t>SETTINGS_NO_RFC7540_PRIORITIES</t> <t>0x9</t>
</dd> </dd>
<dt> <dt>
Code: </dt> Name: </dt>
<dd> <dd>
<t>0x9</t> <t>SETTINGS_NO_RFC7540_PRIORITIES</t>
</dd> </dd>
<dt> <dt>
Initial value: </dt> Initial Value: </dt>
<dd> <dd>
<t>0</t> <t>0</t>
</dd> </dd>
<dt> <dt>
Specification: </dt> Reference: </dt>
<dd> <dd>
<t>This document</t> <t>This document</t>
</dd> </dd>
</dl> </dl>
<t>This specification registers the following entry in the HTTP/2 Frame Ty <t>This specification registers the following entry in the "HTTP/2 Frame T
pe ype"
registry established by <xref target="RFC7540" format="default"/>:</t> registry defined in <xref target="HTTP2" format="default"/>:</t>
<dl> <dl spacing="compact">
<dt> <dt>
Frame Type: </dt> Code: </dt>
<dd> <dd>
<t>PRIORITY_UPDATE</t> <t>0x10</t>
</dd> </dd>
<dt> <dt>
Code: </dt> Frame Type: </dt>
<dd> <dd>
<t>0x10</t> <t>PRIORITY_UPDATE</t>
</dd> </dd>
<dt> <dt>
Specification: </dt> Reference: </dt>
<dd> <dd>
<t>This document</t> <t>This document</t>
</dd> </dd>
</dl> </dl>
<t>This specification registers the following entries in the HTTP/3 Frame Type <t>This specification registers the following entry in the "HTTP/3 Frame T ypes"
registry established by <xref target="HTTP3" format="default"/>:</t> registry established by <xref target="HTTP3" format="default"/>:</t>
<dl> <dl spacing="compact">
<dt>
Value: </dt>
<dd>
<t>0xF0700-0xF0701</t>
</dd>
<dt> <dt>
Frame Type: </dt> Frame Type: </dt>
<dd> <dd>
<t>PRIORITY_UPDATE</t> <t>PRIORITY_UPDATE</t>
</dd> </dd>
<dt> <dt>
Code: </dt> Status: </dt>
<dd> <dd>
<t>0xF0700 and 0xF0701</t> <t>permanent</t>
</dd> </dd>
<dt> <dt>
Specification: </dt> Reference: </dt>
<dd> <dd>
<t>This document</t> <t>This document</t>
</dd> </dd>
<dt>
Change Controller: </dt>
<dd>
<t>IETF</t>
</dd>
<dt>
Contact: </dt>
<dd>
<t>ietf-http-wg@w3.org</t>
</dd>
</dl> </dl>
<t>Upon publication, please create the HTTP Priority Parameters registry a <t>IANA has created the "Hypertext Transfer Protocol (HTTP) Priority" regi
t stry at
<eref target="https://iana.org/assignments/http-priority">https://iana.org/assig <eref target="https://www.iana.org/assignments/http-priority" brackets="angle"/>
nments/http-priority</eref> and populate it with the entries in and has populated it with the entries in
<xref target="iana-parameter-table" format="default"/>; see <xref target="regist er" format="default"/> for its associated procedures.</t> <xref target="iana-parameter-table" format="default"/>; see <xref target="regist er" format="default"/> for its associated procedures.</t>
<table anchor="iana-parameter-table" align="center"> <table anchor="iana-parameter-table" align="center">
<name>Initial Priority Parameters</name> <name>Initial Priority Parameters</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="center">Description</th> <th align="center">Description</th>
<th align="left">Specification</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">u</td> <td align="left">u</td>
<td align="center">The urgency of an HTTP response.</td> <td align="center">The urgency of an HTTP response.</td>
<td align="left"> <td align="left">
<xref target="urgency" format="default"/></td> <xref target="urgency" format="default"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">i</td> <td align="left">i</td>
<td align="center">Whether an HTTP response can be processed increme ntally.</td> <td align="center">Whether an HTTP response can be processed increme ntally.</td>
<td align="left"> <td align="left">
<xref target="incremental" format="default"/></td> <xref target="incremental" format="default"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="HTTP2" to="HTTP/2"/>
<displayreference target="HTTP3" to="HTTP/3"/>
<displayreference target="I-D.lassey-priority-setting" to="PRIORITY-SETTING"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="HTTP"> <!-- [HTTP] draft-ietf-httpbis-semantics (RFC 9110) AUTH48 -->
<reference anchor='HTTP' target="https://www.rfc-editor.org/info/rfc9110
">
<front> <front>
<title>HTTP Semantics</title> <title>HTTP Semantics</title>
<author fullname="Roy T. Fielding"> <author initials='R' surname='Fielding' fullname='Roy Fielding' role
<organization>Adobe</organization> ="editor">
</author> <organization />
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke">
<organization>greenbytes GmbH</organization>
</author> </author>
<date day="12" month="September" year="2021"/> <author initials='M' surname='Nottingham' fullname='Mark Nottingham'
<abstract> role="editor">
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applic <organization />
ation-
level protocol for distributed, collaborative, hypertext information
systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
of RFC 7230.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics-
19"/>
</reference>
<reference anchor="HTTP2">
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author fullname="Martin Thomson">
<organization>Mozilla</organization>
</author> </author>
<author fullname="Cory Benfield"> <author initials='J' surname='Reschke' fullname='Julian Reschke' rol
<organization>Apple Inc.</organization> e="editor">
<organization />
</author> </author>
<date day="18" month="November" year="2021"/> <date year='2022' month='June'/>
<abstract>
<t> This specification describes an optimized expression of the
semantics
of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
resources and a reduced latency by introducing field compression and
allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFC 7540 and RFC 8740.
</t>
</abstract>
</front> </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-0 <seriesInfo name="STD" value="97"/>
6"/> <seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference> </reference>
<reference anchor="HTTP3"> <!-- [HTTP/2] draft-ietf-httpbis-http2bis (RFC 9113) AUTH48 -->
<reference anchor='HTTP2' target="https://www.rfc-editor.org/info/rfc911
3">
<front> <front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title> <title>HTTP/2</title>
<author fullname="Mike Bishop"> <author initials='M' surname='Thomson' fullname='Martin Thomson' rol
<organization>Akamai</organization> e="editor">
<organization />
</author> </author>
<date day="2" month="February" year="2021"/> <author initials='C' surname='Benfield' fullname='Cory Benfield' rol
<abstract> e="editor">
<t> The QUIC transport protocol has several features that are de <organization />
sirable
in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC. This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to HTTP/3.
DO NOT DEPLOY THIS VERSION OF HTTP
DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This
version is still a work in progress. For trial deployments, please
use earlier versions.
Note to Readers
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic.
Working Group information can be found at https://github.com/quicwg;
source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/-http.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
</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">
<organization/>
</author> </author>
<date month="March" year="1997"/> <date year='2022' month='June'/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF document
s. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="9113"/>
<seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC9113"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC8174"> <!-- [HTTP/3] draft-ietf-quic-http (RFC 9114) AUTH48 -->
<reference anchor='HTTP3' target="https://www.rfc-editor.org/info/rfc911
4">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti <title>HTTP/3</title>
tle> <author initials='M' surname='Bishop' fullname='Mike Bishop' role="e
<author fullname="B. Leiba" initials="B." surname="Leiba"> ditor">
<organization/> <organization />
</author> </author>
<date month="May" year="2017"/> <date year='2022' month='June'/>
<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 tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="9114"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC9114"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<reference anchor="STRUCTURED-FIELDS"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<reference anchor="STRUCTURED-FIELDS" target="https://www.rfc-editor.org
/info/rfc8941">
<front> <front>
<title>Structured Field Values for HTTP</title> <title>Structured Field Values for HTTP</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"> <author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/> <organization/>
</author> </author>
<author fullname="P-H. Kamp" initials="P-H." surname="Kamp"> <author fullname="P-H. Kamp" initials="P-H." surname="Kamp">
<organization/> <organization/>
</author> </author>
<date month="February" year="2021"/> <date month="February" year="2021"/>
<abstract>
<t>This document describes a set of data types and associated algo
rithms that are intended to make it easier and safer to define and handle HTTP h
eader and trailer fields, known as "Structured Fields", "Structured Headers", or
"Structured Trailers". It is intended for use by specifications of new HTTP fie
lds that wish to use a common syntax that is more restrictive than traditional H
TTP field values.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8941"/> <seriesInfo name="RFC" value="8941"/>
<seriesInfo name="DOI" value="10.17487/RFC8941"/> <seriesInfo name="DOI" value="10.17487/RFC8941"/>
</reference> </reference>
<reference anchor="QUIC"> <reference anchor="QUIC" target="https://www.rfc-editor.org/info/rfc9000 ">
<front> <front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I yengar"> <author fullname="J. Iyengar" initials="J." role="editor" surname="I yengar">
<organization/> <organization/>
</author> </author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T homson"> <author fullname="M. Thomson" initials="M." role="editor" surname="T homson">
<organization/> <organization/>
</author> </author>
<date month="May" year="2021"/> <date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol.
QUIC provides applications with flow-controlled streams for structured communic
ation, low-latency connection establishment, and network path migration. QUIC in
cludes security measures that ensure confidentiality, integrity, and availabilit
y in a range of deployment circumstances. Accompanying documents describe the i
ntegration of TLS for key negotiation, loss detection, and an exemplary congesti
on control algorithm.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9000"/> <seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference> </reference>
<reference anchor="RFC8126"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.8126.xml"/>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton">
<organization/>
</author>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization/>
</author>
<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 th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations 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 documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="MARX" target="https://www.doi.org/10.5220/00081917013 00143"> <reference anchor="MARX" target="https://www.doi.org/10.5220/00081917013 00143">
<front> <front>
<title>Of the Utmost Importance: Resource Prioritization in HTTP/3 o ver QUIC</title> <title>Of the Utmost Importance: Resource Prioritization in HTTP/3 o ver QUIC</title>
<author initials="R." surname="Marx" fullname="Robin Marx"> <author initials="R." surname="Marx" fullname="Robin Marx">
<organization/> <organization/>
</author> </author>
<author initials="T.D." surname="Decker" fullname="Tom De Decker"> <author initials="T." surname="De Decker" fullname="Tom De Decker">
<organization/> <organization/>
</author> </author>
<author initials="P." surname="Quax" fullname="Peter Quax"> <author initials="P." surname="Quax" fullname="Peter Quax">
<organization/> <organization/>
</author> </author>
<author initials="W." surname="Lamotte" fullname="Wim Lamotte"> <author initials="W." surname="Lamotte" fullname="Wim Lamotte">
<organization/> <organization/>
</author> </author>
<date year="2019" month="September"/> <date year="2019" month="September"/>
</front> </front>
<seriesInfo name="DOI" value="10.5220/0008191701300143"/> <seriesInfo name="DOI" value="10.5220/0008191701300143"/>
<seriesInfo name="SCITEPRESS" value="Proceedings of the 15th Internati <refcontent>SCITEPRESS Proceedings of the 15th International Conferenc
onal Conference on Web Information Systems and Technologies (pages 130-143)"/> e on Web Information Systems and Technologies (pages 130-143)</refcontent>
</reference>
<reference anchor="RFC7540">
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author fullname="M. Belshe" initials="M." surname="Belshe">
<organization/>
</author>
<author fullname="R. Peon" initials="R." surname="Peon">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson">
<organization/>
</author>
<date month="May" year="2015"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduce
d perception of latency by introducing header field compression and allowing mul
tiple concurrent exchanges on the same connection. It also introduces unsolicit
ed push of representations from servers to clients.</t>
<t>This specification is an alternative to, but does not obsolete,
the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7540"/>
<seriesInfo name="DOI" value="10.17487/RFC7540"/>
</reference> </reference>
<reference anchor="CACHING"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7540.xml"/>
<!-- [CACHING] draft-ietf-httpbis-cache (RFC 9111) AUTH48 -->
<reference anchor='CACHING' target="https://www.rfc-editor.org/info/rfc9
111">
<front> <front>
<title>HTTP Caching</title> <title>HTTP Caching</title>
<author fullname="Roy T. Fielding"> <author initials='R' surname='Fielding' fullname='Roy Fielding' role
<organization>Adobe</organization> ="editor">
</author> <organization />
<author fullname="Mark Nottingham">
<organization>Fastly</organization>
</author> </author>
<author fullname="Julian Reschke"> <author initials='M' surname='Nottingham' fullname='Mark Nottingham'
<organization>greenbytes GmbH</organization> role="editor">
<organization />
</author> </author>
<date day="12" month="September" year="2021"/> <author initials='J' surname='Reschke' fullname='Julian Reschke' rol
<abstract> e="editor">
<t> The Hypertext Transfer Protocol (HTTP) is a stateless applic <organization />
ation-
level protocol for distributed, collaborative, hypertext information
systems. This document defines HTTP caches and the associated header
fields that control cache behavior or indicate cacheable response
messages.
This document obsoletes RFC 7234.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-19"/
>
</reference>
<reference anchor="RFC8081">
<front>
<title>The "font" Top-Level Media Type</title>
<author fullname="C. Lilley" initials="C." surname="Lilley">
<organization/>
</author> </author>
<date month="February" year="2017"/> <date year='2022' month='June'/>
<abstract>
<t>This memo serves to register and document the "font" top-level
media type, under which subtypes for representation formats for fonts may be reg
istered. This document also serves as a registration application for a set of i
ntended subtypes, which are representative of some existing subtypes already in
use, and currently registered under the "application" tree by their separate reg
istrations.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8081"/> <seriesInfo name="STD" value="98"/>
<seriesInfo name="DOI" value="10.17487/RFC8081"/> <seriesInfo name="RFC" value="9111"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC9111"/>
<reference anchor="QUIC-RECOVERY"> </reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8081.xml"/>
<reference anchor="QUIC-RECOVERY" target="https://www.rfc-editor.org/inf
o/rfc9002">
<front> <front>
<title>QUIC Loss Detection and Congestion Control</title> <title>QUIC Loss Detection and Congestion Control</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="I yengar"> <author fullname="J. Iyengar" initials="J." role="editor" surname="I yengar">
<organization/> <organization/>
</author> </author>
<author fullname="I. Swett" initials="I." role="editor" surname="Swe tt"> <author fullname="I. Swett" initials="I." role="editor" surname="Swe tt">
<organization/> <organization/>
</author> </author>
<date month="May" year="2021"/> <date month="May" year="2021"/>
<abstract>
<t>This document describes loss detection and congestion control m
echanisms for QUIC.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9002"/> <seriesInfo name="RFC" value="9002"/>
<seriesInfo name="DOI" value="10.17487/RFC9002"/> <seriesInfo name="DOI" value="10.17487/RFC9002"/>
</reference> </reference>
<reference anchor="FORWARDED"> <reference anchor="FORWARDED" target="https://www.rfc-editor.org/info/rf c7239">
<front> <front>
<title>Forwarded HTTP Extension</title> <title>Forwarded HTTP Extension</title>
<author fullname="A. Petersson" initials="A." surname="Petersson"> <author fullname="A. Petersson" initials="A." surname="Petersson">
<organization/> <organization/>
</author> </author>
<author fullname="M. Nilsson" initials="M." surname="Nilsson"> <author fullname="M. Nilsson" initials="M." surname="Nilsson">
<organization/> <organization/>
</author> </author>
<date month="June" year="2014"/> <date month="June" year="2014"/>
<abstract>
<t>This document defines an HTTP extension header field that allow
s proxy components to disclose information lost in the proxying process, for exa
mple, the originating IP address of a request or IP address of the proxy on the
user-agent-facing interface. In a path of proxying components, this makes it po
ssible to arrange it so that each subsequent component will have access to, for
example, all IP addresses used in the chain of proxied HTTP requests.</t>
<t>This document also specifies guidelines for a proxy administrat
or to anonymize the origin of a request.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="7239"/> <seriesInfo name="RFC" value="7239"/>
<seriesInfo name="DOI" value="10.17487/RFC7239"/> <seriesInfo name="DOI" value="10.17487/RFC7239"/>
</reference> </reference>
<reference anchor="I-D.lassey-priority-setting"> <!-- draft-lassey-priority-setting (Expired) -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<title>Declaring Support for HTTP/2 Priorities</title> .lassey-priority-setting.xml"/>
<author fullname="Brad Lassey">
<organization>Google</organization>
</author>
<author fullname="Lucas Pardue">
<organization>Cloudflare</organization>
</author>
<date day="25" month="July" year="2019"/>
<abstract>
<t> HTTP/2 provides a prioritization scheme but experience has s
hown that
implementation support varies. This document defines an HTTP/2
setting that endpoints can use as an affirmative signal to indicate
their support for HTTP/2 Priorities.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-lassey-priority-setting
-00"/>
</reference>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="true" toc="default"> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t>Roy Fielding presented the idea of using a header field for representin <t><contact fullname="Roy Fielding"/>
g presented the idea of using a header field for representing
priorities in <eref target="https://www.ietf.org/proceedings/83/slides/slides-83 priorities in <eref target="https://www.ietf.org/proceedings/83/slides/slides-83
-httpbis-5.pdf">https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.p -httpbis-5.pdf" brackets="angle"/>.
df</eref>. In <eref target="https://github.com/pmeenan/http3-prioritization-proposal" brack
In <eref target="https://github.com/pmeenan/http3-prioritization-proposal">https ets="angle"/>, <contact fullname="Patrick Meenan"/>
://github.com/pmeenan/http3-prioritization-proposal</eref>, Patrick Meenan
advocated for representing the priorities using a tuple of urgency and advocated for representing the priorities using a tuple of urgency and
concurrency. The ability to disable HTTP/2 prioritization is inspired by concurrency. The ability to disable HTTP/2 prioritization is inspired by
<xref target="I-D.lassey-priority-setting" format="default"/>, authored by Brad Lassey and Lucas Pardue, with <xref target="I-D.lassey-priority-setting" format="default"/>, authored by <cont act fullname="Brad Lassey"/> and <contact fullname="Lucas Pardue"/>, with
modifications based on feedback that was not incorporated into an update to that modifications based on feedback that was not incorporated into an update to that
document.</t> document.</t>
<t>The motivation for defining an alternative to HTTP/2 priorities is draw n from <t>The motivation for defining an alternative to HTTP/2 priorities is draw n from
discussion within the broad HTTP community. Special thanks to Roberto Peon, discussion within the broad HTTP community. Special thanks to <contact fullname=
Martin Thomson and Netflix for text that was incorporated explicitly in this "Roberto Peon"/>,
<contact fullname="Martin Thomson"/>, and Netflix for text that was incorporated
explicitly in this
document.</t> document.</t>
<t>In addition to the people above, this document owes a lot to the extens ive <t>In addition to the people above, this document owes a lot to the extens ive
discussion in the HTTP priority design team, consisting of Alan Frindell, discussion in the HTTP priority design team, consisting of <contact fullname="Al
Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, Lucas Pardue, Matthew Cox, an Frindell"/>,
Mike Bishop, Roberto Peon, Robin Marx, Roy Fielding.</t> <contact fullname="Andrew Galloni"/>, <contact fullname="Craig Taylor"/>, <conta
<t>Yang Chi contributed the section on retransmission scheduling.</t> ct fullname="Ian Swett"/>, <contact fullname="Matthew Cox"/>,
</section> <contact fullname="Mike Bishop"/>, <contact fullname="Roberto Peon"/>, <contact
<section anchor="change-log" numbered="true" toc="default"> fullname="Robin Marx"/>, <contact fullname="Roy Fielding"/>, and the authors
<name>Change Log</name> of this document.</t>
<t><em>RFC EDITOR: please remove this section before publication</em></t> <t><contact fullname="Yang Chi"/> contributed the section on retransmissio
<section anchor="since-draft-ietf-httpbis-priority-11" numbered="true" toc n scheduling.</t>
="default">
<name>Since draft-ietf-httpbis-priority-11</name>
<ul spacing="normal">
<li>Changes to address Last Call/IESG feedback</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-10" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-10</name>
<ul spacing="normal">
<li>Editorial changes</li>
<li>Add clearer IANA instructions for Priority Parameter initial popul
ation</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-09" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-09</name>
<ul spacing="normal">
<li>Editorial changes</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-08" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-08</name>
<ul spacing="normal">
<li>Changelog fixups</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-07" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-07</name>
<ul spacing="normal">
<li>Relax requirements of receiving SETTINGS_NO_RFC7540_PRIORITIES tha
t changes
value (#1714, #1725)</li>
<li>Clarify how intermediaries might use frames vs. headers (#1715, #1
735)</li>
<li>Relax requirement when receiving a PRIORITY_UPDATE with an invalid
structured
field value (#1741, #1756)</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-06" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-06</name>
<ul spacing="normal">
<li>Focus on editorial changes</li>
<li>Clarify rules about Sf-Dictionary handling in headers</li>
<li>Split policy for parameter IANA registry into two sections based o
n key length</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-05" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-05</name>
<ul spacing="normal">
<li>Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to
SETTINGS_NO_RFC7540_PRIORITIES</li>
<li>Clarify that senders of the HTTP/2 setting can use any alternative
(#1679,
#1705)</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-04" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-04</name>
<ul spacing="normal">
<li>Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to
SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601)</li>
<li>Reoriented text towards RFC7540bis (#1561, #1601)</li>
<li>Clarify intermediary behavior (#1562)</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-03" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-03</name>
<ul spacing="normal">
<li>Add statement about what this scheme applies to. Clarify extension
s can
use it but must define how themselves (#1550, #1559)</li>
<li>Describe scheduling considerations for the CONNECT method (#1495,
#1544)</li>
<li>Describe scheduling considerations for retransmitted data (#1429,
#1504)</li>
<li>Suggest intermediaries might avoid strict prioritization (#1562)</
li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-02" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-02</name>
<ul spacing="normal">
<li>Describe considerations for server push prioritization (#1056, #13
45)</li>
<li>Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261, #1
344)</li>
<li>Add a Priority Parameters registry (#1371)</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-01" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-01</name>
<ul spacing="normal">
<li>PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,
#1271)</li>
<li>Add section to describe server scheduling considerations (#1215, #
1232, #1266)</li>
<li>Remove specific instructions related to intermediary fairness (#10
22, #1264)</li>
</ul>
</section>
<section anchor="since-draft-ietf-httpbis-priority-00" numbered="true" toc
="default">
<name>Since draft-ietf-httpbis-priority-00</name>
<ul spacing="normal">
<li>Move text around (#1217, #1218)</li>
<li>Editorial change to the default urgency. The value is 3, which was
always the
intent of previous changes.</li>
</ul>
</section>
<section anchor="since-draft-kazuho-httpbis-priority-04" numbered="true" t
oc="default">
<name>Since draft-kazuho-httpbis-priority-04</name>
<ul spacing="normal">
<li>Minimize semantics of Urgency levels (#1023, #1026)</li>
<li>Reduce guidance about how intermediary implements merging priority
signals
(#1026)</li>
<li>Remove mention of CDN-Loop (#1062)</li>
<li>Editorial changes</li>
<li>Make changes due to WG adoption</li>
<li>Removed outdated Consideration (#118)</li>
</ul>
</section>
<section anchor="since-draft-kazuho-httpbis-priority-03" numbered="true" t
oc="default">
<name>Since draft-kazuho-httpbis-priority-03</name>
<ul spacing="normal">
<li>Changed numbering from <tt>[-1,6]</tt> to <tt>[0,7]</tt> (#78)</li
>
<li>Replaced priority scheme negotiation with HTTP/2 priority deprecat
ion (#100)</li>
<li>Shorten parameter names (#108)</li>
<li>Expand on considerations (#105, #107, #109, #110, #111, #113)</li>
</ul>
</section>
<section anchor="since-draft-kazuho-httpbis-priority-02" numbered="true" t
oc="default">
<name>Since draft-kazuho-httpbis-priority-02</name>
<ul spacing="normal">
<li>Consolidation of the problem statement (#61, #73)</li>
<li>Define SETTINGS_PRIORITIES for negotiation (#58, #69)</li>
<li>Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)</li>
<li>Explain fairness issue and mitigations (#56)</li>
</ul>
</section>
<section anchor="since-draft-kazuho-httpbis-priority-01" numbered="true" t
oc="default">
<name>Since draft-kazuho-httpbis-priority-01</name>
<ul spacing="normal">
<li>Explain how reprioritization might be supported.</li>
</ul>
</section>
<section anchor="since-draft-kazuho-httpbis-priority-00" numbered="true" t
oc="default">
<name>Since draft-kazuho-httpbis-priority-00</name>
<ul spacing="normal">
<li>Expand urgency levels from 3 to 8.</li>
</ul>
</section>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAPgq5mEAA9V92XYbyZHoe35FjfRg0geAuEitFj1tD5ukujmjbUjKbR+P
j1QACmSNClVwLaRgjeZb7rfcL7uxZkYWCpTU9svVaZskUJVLZGTsy3g8dm3e
FtlRcvaxzcomnxZZ8qbOqzpv87+nbV6VyeXsJltmyaKqk5+vrt64dDqts9sj
+sM/mzVuXs3KdAlDzet00Y7zrF2Mb9p2Nc2b8YofW4/3D9wsbbPrql4fJU07
dy5f1UdJW3dNe7C392zvwKV1lh4lx6tVkc9oBU2SlvPkIkuL8VW+zNxdVX+4
rqtuxWtwH7I1fDQ/Ss7LNqvLrB2f4gqca1p48V1aVCWsag1LbJZp3b77W1e1
WXOUlJVb5UfJX9pqNkpg9Xk5z8p2lDRV3dbZooHf1kv5pa3zGXw1q5arVH5Z
wsPwVV4WeZn91bnbrOyyI5ckdm1J0q5XMPsvsOa8vE5+wu/g05sKIYXgaY4e
PcKfd9eTqr5+BN8t07w4Sjz8xnfX/3Z3iF/Cd2k9uwnvFXnTNhP+8tExfJXf
Zs2jN90UQPfIDoDD1tmqCq9e5+1NN53APmR2+jHOGA0A6I+KdJoVzaNVOGF+
Z5w3TZeN6eujxHzt0q69qWoEwRj+lwBoAMr/MUlef+job0aP/0j/3t1U/kNY
+lHyPG3aYk1/Z7z9D/RU9aH7t2v8ABcaj/tikrxJ63mXmaFfdLO0sR/T4CdF
1c0XBeCVnaDAZ1f06OTg8eSpmcflJWD7EpDvlg705fHFn47o3Tatr7M2QPHu
7m4yr3KC//7e5MnBwd6jvb297/ef7T/d2z/c29t/fMgv8i178HqRtDdZ8rZd
Vk2bnC9XgGtpOYOvLrKm6urZxvXLS8KkR4dJdZvVyX++PT95QEPO4R4dJQd7
+8/Ge8/okwB/hZQC5qKawjgv0/rjwJdX1TI5zeC/2YesHvj+TdbixF069PIv
+TJ5kS6rtmXoNlkNuIAAPJLnTl+fHyX3AidJLk/Or87eXJxdXgKM3tTVLMvm
cF2apGJ47T9pb+R6E1TSIjmpykVWZwC7BKD0SzaF7+XUkGitmzZbMuW4ymY3
ZVVU17CwZGeVXsMPmH4M0+8+cM6Nx+MkncIVh5vt3NVN3iA16PB+J/OsmdX5
FN5Ik4YJYXuTtklaFNUdDs9kcFbk+HRbEWHoSqRcWZK3jVsBAeFlNkRCb6o7
2lG3ggmzdIkAw3PVe/R3eK7OmhXcQPgNBoRB4IO/dRlc9ZHD/aRFU/kF6Pvw
5E3OS0hh+XelDJ8j0JYAzbRe0+Q8nkzgmpuqK+bJNDMLmCd3N1mJq1wDvSHK
fwf3JJtPkqQPnQXQvgYfdYK2MEmWzmFBizyDgXHLASRIAXHzeQkTwRkqW0Ak
F1ACGa2R/oyRGq8yIslAEcsyq0cJXO67rCjwJ92JAzpfuR6LGhCSgOyA1Olu
cEq/3QmsP2uypLnBfaW0MkAWRhsk8t2s7Wo5YtwoYPJ1mc0dQHVVV7f5HKDR
0SNCKKd5AeufMBIt8/m8yJx7iKhaV3MYDXbi3DkNFiZDUgxrgp0JfwMsV0z6
9Olf8OcP5+PTScRCG6BbZZvPms+fYX9CK/DU09sMBix4qJt8RVgDLA+IX7Ks
YKkVgBzn5HcACCeErQDLvChctYCNJPO8mRF9aQlA8Xh3N3mBCALXsmkQoCk8
ABwxuwVcifcycvDw7AZObJ0UgAi4lkVXywroHTh3xWdAqJdZWtL4I8IMuN4I
Xb72zi4DDgMxmfAN8JNGxDfk6gGAp0UFFAxwrgaCNqsAWGVHGFfp2h08ARcH
0PoWaH2Kwo4BS3JcwrGmy1UhC4Ax4b/bvOlozYCLNY6np/XyhdObMEp42zO9
TbqW6ZoWGbaOLycnl5dwPwpBNNypv1JELvAIJ4BEtIsaeKOKGUm+JPI1r0B6
aXkWszK8DcCfUAK7K4GLzeoMB+UtNwyum6784OmqDJfWNbA6wGK5VYKEB5tY
iD8P4JfPn83Vc/L8YXj+b10+o4fhwaZbIZtLll3R5gDcjwJExQIaKdC8vHRA
1eAZgA/sv8zoFk3wdHLhl22yyDyipOUavyh4q0T9Cchw5iDZVYUjIMv1beJV
5AyUlK8xY4qSQfoGEHvOyw1CAS7mOVwuwZVRYqjDEtAZnl90SNzCtTA446mn
46NPsrQGFAZpYFkxKuWEzWavMJeSh0Dt44XSyQUgjvDy94+7govdf4wpXUv7
JMKROr5QARkMieXZgZTBcpAbzjvE4TotmyUIhbJPOLNZV9eMzDwRyiqpg7uA
Z4Ugapi7zEDCa7JJcmnGBYKLREuutecQSIiB8dFqmhYJV9PN8E4DqAG7aWW9
3U2Sn6s7oFHAOHThtN1qldXEnmUylL+ADBJ3nAlpJBk3xlDYVwMHZzAVlztL
O2Qo3bRatXCbChnBpUF/SWA+Qh2YZ5K82dgRcnI/cU+EADDltbvNsztzYzxU
AuSIC9DDCfD+pAT5SXaLnM7yUsBkgS09hOoOHwYzAph8ioRmA/B3IPwLK/HU
094JBCdoYYyc/LniiL/vBhsAvy6enyRPnzzeA3LzB/gdf0VqwXKLn5/AA5Q0
NUIWYiuLPijSwY42VktbjwBZyX2m+5MmD/wrMF/24Hf8rUoATuk/fhlYXGM4
zm+ahGW7mphgQdoCQ0BJ8V2WX9+0ID4AdwX6P+2UFOAoU3jiLp8DUEF6hhf6
uOvvBLEURDJizZtbTZFkrroWRT1DFvhQ5tksJ3FqmaL+OUH5NhO5hta4STn9
sfRP4g5mqqYEwblKHihA1i0AGqX1EZDEVZEC+swRGz59ArUgv6WBP3+eiMjm
voq53KQNXThE+BJUQ1gyQBtPcs7ic4O037G00l+oQIakvT5ARIjHrfefdyzO
zkGCrbO8pOsNKgECOMUbDmSn7Vq2hGwD0uQeBaL0QiNQzSZYVSJZNUYD5l0d
EhvQUKoCpwcpokME+fQJtFcQeUEqQoipLO53Fb5V6QQ1YNgJWkVAnidJH+Fg
ViWSMGCBEc0N2/v0iaX7MUn3IIkaDSBQNtqDVQNGhh2PhwR8WIaDX8dtNc42
TyZIrMR48Am6nJGmgWSBnu7RTKTqgWQP6jtw2fIlULS6WAdWMc1An0IAuUiF
whUg8uWtmTHQkkr0m/AGCC4L1J9VkkidUPFRIGnESG7S8lppeCD4QjL9DDtN
lsEVMhqO3K9dlDV1EjwBD+hmBURgkc9UQ1I0B0ELzvNg3K3QlDCmb0Wug88P
e5+jQGDhjY/RVwM8mlgOkiTSRhmivwlqp+vdSZHO6b6yylmVKLHCpbsG8ZSe
welE6r3uALMBwniL1w7QHLSiDk7Paigo/kRyCXEmvG2oGXmwerqNC4XBvKpE
XyO+8+LHgZN5CKFMH2aInxBx0CEJg5916vdw3eVzFATgPlcAIMROxbglcgui
ON0KKZVQMQcK5cPkVdUay8ctYA3qRUzOPwDU0ALaJA9evr28ejDin8mr1/T7
xdl/vj2/ODvF3y9/Pn7xwv/i5InLn1+/fXEafgtvnrx++fLs1Sm/DJ8m0Ufu
wcvjP8M3uLEHr99cnb9+dfziAdL+NiKCeKQA4ancDKDkSMdTpLhMHYlf/Hjy
5v/+n/3HqH0AeT3Y338GkOQ/vt9/+hj+QLsEz0YIwn+i8ILiFsjRZEcoQAZL
VzloPQ1ZDODKg0SENB1A+du/IGT+epT863S22n/8e/kANxx9qDCLPiSYbX6y
8TIDceCjgWk8NKPPe5CO13v85+hvhbv5kNECaVCTnOakPwElAtq2GE+rCvTy
kn6fm69Irl6M8XyuUUDCK0waiCjUyLYvry7enly9BbCMn5+fvTi9/AGP5tnj
faIOZ6I6Cwcb1O1EjBFRYNy0a890yDgkM5F8QIPGzJQYIb5/m9Y5CqDjIiuv
QYTSZWflrJqbgf4FzaW4ymd7e3syIAOGVeuqUAae0+KIjShSJlMgB2a5+ihK
wi5HvgVUFSbd+7hH2/RPHvYG/x1c8Qww+ZJV2eS7ycFkH8WXe7Rmu1SZvkdn
B5fc3mSDrNuh+CqWkaBpKOVRG/OBsIj+gp9MDicHyI/CwbiHyUsv3bFIlIHs
N0Pge+EoeIeSTw+NMGhk/77strMxM84b9INd3DZZ7lCHTxqy87o7vN5+ZwIf
GVqljFmeNUYsbyK4IVcvp2mBpHnuUOqfJOegFncLtN6KTakAKQHvA4xYVOul
CC5M00ipFDMCTZI2RmZ1SJjgHtzmqiV7S4uCVD8B2ggSdCOGOJWakoyldDKP
eDVrCU/i04CSuH10TrVikhwAZHSEuyIUOlXH2RqxFi5EKjYSbMIwUKJLpuqZ
mDVmbHopxCIPHJSBDsc/Qs38Ru1N3mg+KBQDIr1Em0BAB9bPYq3E27uQN1Zl
/z64wCl7vhMvrBk1lXbaWLWZObE3BIKsgHqFiAwIXBKeA0UDUF9nJdkQ5j1L
kAo7I1aXP5TVXZHNr0mf7Nt/grY5EqDfpaze9mxQ86wAANeooYvBznnNfobP
zVDorXCnuJQVasUiYdyq9ZffmyTJL7guD24yNYF6uligCMWmJm8rqQK39qJd
REEi5UVEnIZg16BcCERwnvP5sRILIMZJAKS0HZw2IzuRxx0e338hlgqSDIeV
qvCm2uwbwp2aLiGZv1EGA0kNRd4Ryd45KegFSIphg0FAI3uDf4AYDek+hmbN
K5gZ8ZElaTh10LNuqrlYHeCg9eJM15GHRq2EaV+LJ1AarSGnq+EnDBS9wQMG
ODbW6ID2fhFcBUfRwaHOFjwLFwypiZgd6YjafMmEDqHrsYBOflbVwP7RdELX
WUwGaGOwti2hHHofwgoQ//Fa+Suguli8UifkxjtkdJlkwRSLBpNAmUpIAd1c
ONeKhH02ujivGcAtndUVnB/zABAEi/yD585MdA9FasH7wqSVkM+qpUjq0OOe
7Hz6hE5gZD88McqUfAsV35jQsYoKcyIFbNEF0rQJ4hxo7WTPDKZA1PjQ5QjT
N+jXcUS/a2boeEKCvczoDIVsu1WDDJpI8gqHyGdIe3S6Bdt+3V02Jeo3SxsU
fUGJOM0bkJq2s+i5fv+ZpQ8APQhZ4kYFpsR8E1aQ4NEyfRGcnsuSI5EAlGfL
ImBf38j3lVmJNHR5dnV1/uqny3evXr8TieDdm4vz1xfnV+dnl15My1iYzIOq
S24YS0EsF2UDLBz5qspFMKqA0RMCsjF6WABrVBm/h8eSFKA6zjSDidgqRUYc
FAG/sCVSToCa7OFq9tEJstZ3xQMG6MZf0rMOZUCALOtX0Y1KsrqG5zYA/Zhk
Ub9msk+uV5l7c/H66vXJ6xfvzi4uXl/wstVxy0sAgO7ByZwvDPAQ4b6wJxIz
aGNkyslbFS0Wed20HiIsi6IhFN1bTaJ6mrGUfGkmWqZLyf7iJ0j6E1xksywP
7gH0M6LVT+cBfYtBiitFmLoNmArIkh7InNuwW31hwSQ1pB474FCJFs/Jhu2C
kIbUEqlg16i1ZwA9+cji3aL4BhIuScJrt0Wx2NAVyElgnT/eF2tdsWuHHgW9
UWR1R9kuCFbBYAaQnRMdmmYLvGDBckSOyOTYKdPELdd8QM23Q4+uxP2XGE7J
up/+maeE/vUvkRCCNZAnlXSAIwVCxKLqlxeE6ICqb1eDlDcXWTAivZuka2Hl
1r5dF2XgAdvgbjLtaG81Xf6ySlieIlFdpkWBRw2OapCFu0EM6GFyPL8FZsUB
Jm8JeQcCD7NGtYfjsAXnfmRcYWzgMIQechPOBhnc21e9wIbSSJIvjCvIoasV
j+hLF6mm2UegJoJqZCMPPHYizx1aUJhsZN8TkxCdb8/SMODkEfuC/q3+qWHv
hvCl3pmKYXfjUOFoXqM8smVPg1RTHWylV1a/xMm8O4KvT7g85PBWYLTVSo3Y
zlhehk4E7QC3VT5vvNUbZKeunKdlG7sB0e2BB1+qDZJu5BwvfjD7C1L09/81
lMBvZc+hyKDYRUJIY/edkhdHffwDW05k6D+/e/vm9PjqzInFfmfo2EYYJEHH
ho59eRIpAYq6xbq/We8LN9tE1iaBMiHUIXLlWBeL2+mjFAs4HK+A7q3gwfGu
GIA/i/isEmFgRIsSPLAgJy4W45dV2mmieuZAXmboARSuS/SNDVASIywGD/Gr
btKTtYQwq0yrqMR3ZbuISLdrCYoUTL6AT1HnIgPChgNDxKfgV4CjaCiypidt
HU4e68N48UDz8h60Mrsb8t3h2Vs/3y4rqRJFweEWt9maD65C30r06iAJCBjE
po2cFeFyzrzDuM1dZE80DqnGuna87i3fqisx8mziUMttHhUfnRM5TJrIHsFm
GtR2UOVD7QvxXm96rqELfCImWoE8UUxBF/B2VTeiTZy8fvXq7ORKlffeUT0D
Yf47c1iRXg+bB+0VdaXmxrUdICbSpEtvjCANmcwTQmBIp+Pnfpekc7aLYLTI
xn5V8ukbVtDqlIsd7tMnuQwRFGFb8AVdnBi6wVxiQ1xwPxi0gutAbxsseR3M
jORcR3MK3xINnBPVVANRPJ4HoUdNAUheK/ZwLxt/Q0J8uZAFEbKFzkuOAYYa
sX4IJCK9zVHEruWm0EXBCBLYAEiLMDusAkfJmyWeARorzCwsrdKLiIBNVtwy
HJzln54a5I3QTT7BORMaT0jehMv16aG5lj3SEoXFcJAuxjGw0fRDth4zy1il
OTrnGfmJgVUgLiAOxEGmsI9JcoYmhfhdG5iSDhAPwfPtfvlNCrG7ScrvUjx2
J87Olqkk2QAWgwSLZLvUowiaAQJhzCW0CgDbc4sn/4hbHFnTr3KJ9xiusFEX
XORDEtNWF3nynLmwh5Vfn4EPXmaNb7wB3o+uTNSiI+sf710izjhYBeOJBwR5
8iwMyg0I+kFGzjo1Q30QAGzkr1WoVRulCrP+eOD+hRjXwalGpDF48p46Kxhg
wHFNn9OfYreCC/4RHeMr9UJZDB3X4gWniITgckIsm+uWBiPRw2SolNotpT5m
D6P8MOhnsUALQI8Ck0ELFDqMBOKwJBQT85XqbegI8HL88BpUih8E+kjlxiig
zSAOGn/Rv6mmnUv1H8yT5zi89fX2TVNimNrw4KptbUtUf9LVQM9n65333ftd
sQL6oOKd9zl8OLDSifsFaYBR1MrIK6yGXFHKEI/W3t81EL2UKk8UkVmCsljS
BrIAC07Rbs2RUckdqqdyw4mCH5fJRgyPxjlGjo0tXmsNkpVECNjfq6oVFagy
ka+Dh1ba0OaGLR/oQ1QfBwqX6Kz2A9EbvA69AcusvlYWH6xVMIu40825pza+
x4gzjwkB3AACTJJfSKHvDYRE3kbY0mzzUSwkO7x/gipGqomsAhTBVrICNni8
Q0SS5beuHVcLuPLIAfhwyS0g5wwQ70r0d7FSsF5ljdpLXdDxHj5M3jISMzcU
jDZ6GSN3m37gID2NJZhm7R0a2dm5/xRD8EmSEu2Uzcfm1IXbetOovaulia1g
s1yEs/j4YWT64UCJ3KqPQ5HBniOKZxZNeyxm9ALCedIZisxlUFgVFiLaTtOg
4iQM2OAzdXGYkl9g5FutAuuL51cTr0LN8fJlAby6ZgnkVSy1tESmiDcwn3wa
dijAXlTqrdPEDfTMNEb8IKodEi4IrwxhI3oL0s37vfdHzv3v//6vDuSORC34
Ifnp7ModiXz4A6f+uSPOtUNU/kFfmZRZ645WKczwQ/KIYlsms6YJtPyHpPth
DycBkuSjmYnzZS0M31DmlhBh+lw0eVISGhLKffqChy/bVt1ONrmejMjDvOvp
ZEM+u9agm267yG6zwjuaUqZSNJQkebmZjzLTXDPjGK69RO1HJFO0C+4+L2LJ
JHfZdNzkbaZ6lqdp6tzBMO+mv8Kdp7uiWHLYMR7nNJ1R/i8y07T50CQab6CO
cvS2N9WivUOliUU0tRjFo4eoLK/Z4QR0HLibHgsg119OGcB4S8jfTowlnYmL
+CGmfnkGyfsyHDMiOrklOiEyS02ffEmZ9YhpuXH5wvBSkYHl8krwYxaxaLJs
TbKJKhlwLKCTOZOlAjQWAzUx3DrKDPLD+9ygTaqlSUSDGwRgL4CxwnnD3dpl
N5GX7Je07yhTxPiN7xlVriuNPIos0VPQOxc5h3ZESX9hSHJ5e5rnJy/Wbppx
HkdseqJg0ypOIRNzmyVsBtoT8iXgGyVFOIctfGk5GJY6pR+jmFb6ABQ27wRA
ZTYOhRMM2ZbA9gkJBpvincL4B+A963/yKYD8mY0MwPsvb4V3MAnyqc3ytJi4
UwY1yReaMCGyhfG4+byJkSZbqZPI31XYliuq8tozTaCXLcY5mM34oBqYjXKx
xTjJkWRKZTm6ODo+Xrq9TnpVK29aSVHqpwApp7OHCzXNSCTWHJpv5GT//ubs
py2szJ+P4/NJ3j9571WO+w4yeY8n+X7yz2WAFHI0+e/VdcwAnwB+Mw/EgATk
I7jpVyDGDFtZyuxuHFlaSLdI2zZbrlq5m8YyNChhzlI604ZQDtGj5KwnkGrI
ZqXhZXPkb8hxiaqjfM5Q7sercxAHq77ZRwzfAGYRfOAbsTxR5EpH7uxWDwYW
TektLLNvysJoVkSR7h4RmqN1WeIdRVCwIrWkPpDGFTzovQioajHivGHQT9aj
CL1Eo5Q/KVKgjtBKGLv5CB/aohSlaFdyajimZFZg66Re+UDGgkwYQOsL/A7I
ySITPds7LlkHZCaQJup/9tmY6C+8BokU0wMoPwPDJTIWYEUpIEmgIY/Mnc8N
qRo2YqPHupvOcxqN2CIBjt3uyKuDzjN0cue9MEaLBiDKVtelxviFK0lOaNgp
cCXvmhHPKj5IUWm6JdkKbwEV3eAuLXqnJ1JC2l3jegYCF2HM1Q2FEpJcA3cX
4+8IIpJu9x6jVwEq7wfO1HrA1QXms9SZ4gkdI17l8FoJm0MVBgPNYf0/ITsD
kXEbjoeEO8pVB/l0XtXemDeygWnBxFfVJmA3fKxpVMQQr2VipuQAK0LIzKXX
NaIU5WPIckUHawW+foW/aagihskwmlU1E33UF+E4/dQiq0sYAW4q/yiSnkaV
iwxIGxwlNpmUDOG6nV1xq19k1zkxeXzi08Oa/sxqoJavtriVBB+M90tfEh/g
Ujds6/ysnaHNMqlob7X8BRITnA37hNFejT4wzBFM2uxj23FYNjpGd0nedjLJ
F21ZyVfasphYUvxdZHLC/XK0b9NUIG+02WYCoBEoOXIop3cQILwFTLThjAPM
daTzJK8IW3PHPqBP90g5/Bpn5nyERrDrS2kF8mPjNIBY6oiDy7+AQ28lPRQY
HqkZtwRUp9aQjQNKBg5IM57hTO4qPShhZRXMQdWbKOiRXWtmn5gyE2OXF/OM
gy+2/zNahzHwsFC8FRLmLuUe8HgXbCua81LW5FGG5UamK/LDcR7QwXdkBfvH
F3VNUXIcQefM8hKKCG1hfLKt3LOqJ71VYdRStDXrSoYrjNZixDu2iTMP4L1P
nFpMcU4mlgO7G4kqT+iKCEzB3u1Os+vdBfmcTSXOcCafcuZDNcky2BOsPtOq
hPRJhiOZmadpAwSby5b8d6aa7jD4hfgpKINQi9JagQWLgCJh3SB3lPzXX1Km
mGr330RhiR9I2ToCh/dff3XulLyZ5LjUYebho2AM22BRvoIKCcV0g3C8Cy3Q
w6OxXzs+R5VSY5ehHxlHucxEQNA7Bwv/Vy0TladlSjWi2CJDHlaut6WD/Z6g
MMfcD4zuKSWjRXPdB9EBaX+y6eCTLE0io8ALIv/eFx2C7NMZzCJWMhxFI0yw
uA35THwC3rARXaPMt4aJOG/lYPOjSNO/aRKbyduzKg6n8zpjXeo5v/MhLxt7
AiKsuT91ipLl2BoW5Sbj1Qk5E2QUJ7DQ7QPGbZ0Fxk/lVcPYWYRB7N6eFoyC
lPQaKySYLV/NSL0Gwe4nve9abypoJprSDu94ji6TilEdjsiGGQxEE7DzcyCK
I+TfrFkctyz8q9i3mGDTabkIQyWgNkbJimJB7fmUhMIPO968vWGW4oIFNcdq
8XORTy/2vfzh5Pjk5/NXP22WK6CxxH9C9atgYkA6dVapbaaXHD982N70vqJM
spbrWmAAfbTJPISmqbuQ86WaJDhCKp9+SPIqrtLHSHFqUzoUOCWg0fWNUCZk
Rceu1JfWoBmcvsixvBKrIfLtCQ44PuEnR8kf4eh2OZ7ioueqdxIM4C1TXI7G
xATkLZWUiixGtNOgyZowJWctmMCXpfiC13UwM2JaV3eo6DBqcL0XFsbR+htb
Xdy/p7fpJbGYL9leFJrmvHmgKJJO7S7dD0/fJzvBoL1LsnQ58hXYWBkrAa7X
jErInbCEnWTvmepyYkxIemsdiYwp/hPeHfltENeuMZeIUMkpQO6sztcPqlCK
7QHgoc54zAoUbM/x9vbes3YwHGawE2LRovAqCvvqaHvx9Iw+QwNS5AWwOx6v
79JWbzAbCe62LEdLnNq8TGfKH4W8oeS8vZdVYj2L3tFw6cieeKJQ9dc/Tfoh
KibTmNQJXqD4YU0WspSyuuS4qfPT34XKkXy+8bNZ3qpXzb9CASNdcwO/TpK3
JaVMbY/scFsjGZj631Sr8XQ9xhAXKeMB/GEw3IZ0+14gvLoh40zqUUjPQxXV
sZ274YweW+OIiSNvTLLy6lrV6kAZCEsolJINgb0YP4N+mY1iIkvsCiGlCd6I
sL76iNuob0j8PgRBlaBns4F4K3jRmrMFusYLHFKhWw0doRiVAZxUTdvPxgLi
H+nCSljQ62XOqVND0WQSySa7rBzrCE3sE5okz0GC7Vh0DQEKg5Ni9HFIV3KD
6UoG5VkspHybvNmScmOQ3g0+/vPhu5/OXp1dHL94t5Gsc2zDooX+DZ+AZK30
cSyX8n106TGxAFh5Cdzw4yxbtZa6GNTxcsZAXH7ynCsnohlz5LQK7IIKBJZV
qIMyN2WnemmPtixhcHHRDHJ5RJ6YSx06SSlTM8QkOWNCgUmEVNFReFCdzkyG
r6grPiDYx89vg6C4bDyFDG4OXrq3DK+ZU8JCEZi4oCvQiariVsIP/BJGXo9c
dfWqargwWJBPWV4iVw+ujtxQfu9bLhpTg+BXc+KbZYfRCrWYOVeS6+WXx8Fm
HIestYwk28iJ83lKJQa+fXEUBk4xu5iqiCXsmLQJSOemsIVC7ueqGMoyMJVT
2XAmRyDWiSYcqgQbeLSSsBGUXNiGSGHC/ZpibEKZoHUa1LXrm8htSzUVNEag
7JZTFqG2LNEkWDtOpGhaTt2hgjD3AJGBRrM1wTKNpDRvl1zv8OFDvZ/bhIv+
HWV1estLIuIg2flh7+P+3q4v2GG4XFS16gt8g4s63suVDGGh5ALL9ZrA5vsu
fnFFGe03Ob48OT8nm+1ItABcIHl044qvGq8wrHgxU5DsXVlAkEMkCLmfkbrf
y0hlzjUsPOh0mij796yukp29j3u7mtg5GOcqEbKiNEqE6MLcVhZkddT7U2pR
4RhM/0RlFmuxonvwftRySfKC7ZI7B493R/DnFY648/0uaL+IPSMHn70tCX+e
F+l1g99N8MMLjY3Z2acXN8G8c4jfDDz6JhhNjBTIjyfDTHtnMoEvP5MO/uko
ebjIr8dwLfqC+ljIPJY9/+HBvXt/k66LKp0/kNvEYBjR/kd2xzvN7sjvgAsW
bcEoEijj2lLGbmvr2Nyjm6x4Wc7muBmDprGv8pxHaEnkxaEh8TjELO2Ppxg8
yiIWBbp5Q6Sm8eEDFKxUikOGNAzKXsXC/RSg1ZUo4BFqs3roQ+cBEoqo4gXm
B3wArq2MYo+aF3rIC1R+YYApDDWSce7RZrCAP9NHawoy2IPzXVlCw09rEGRM
dTR+kqnPhoOIhXeYUVb0q0nTL6pqb+GzksrDUk8kpIw8GWde7nx9jy03K0g9
mj+lRdppAQ+QUWNVtZu0WIxnRYWov0M8dfcBUf8H+bzIHmAJx7ZXNhcLeKf1
XBnlnYb0Dh/8fYsYmhwNRw/4Mz/7VcSwReIUyYA8bVOMnjV2WXIwCDLnJYkr
dj/JquianhggHi8dfIeDryJw4dJEmbVLl0E3K1ntxyUaQlkBFNOx9tNNFoe3
+RTQl8d/enfy+tXJ24uLs1dX7y6vLs6OX5rE1nAgNmtdqiFtYBfNK/5h5UPb
Cgv0azF8G9IaoaCPsb5Q4a/FWE/kduBgqzYTVBnEoW/AWrsa91VY20NONcr7
0w2ld75yowZqfpKh2+fsYQ/pO31jwdBoTOq/Ehs25QyKYdhqivEycGwi7wEA
85c/7rGpyOe1fBOWbq5Lj9qfAmnVw7K9RGL0E7DTYbGPLML/2BVScf9wu7h/
uFXc33wpFvef7z3do7Is/Ov+FuE/pEMNNMX4NcK/C8J/ZPIyXF3ImmR6eq7O
QTqWXKMRk0zQBIP5FvUgCSWK72XDVFbYfYkdb4BVJXQWJxHLCFEZvsD/vb04
Zs2Nmr2/Ybz9aDxro9FEysEjV9GLrJBqtZQMuch46XaGy0AmYlW+X2OR2RCc
csi2BNDWSb+kwrj4Cv98+O75xfHLs3dvX5396c3ZydXZ6ZAes/XOeMUlZ8WF
zmkyEQCPjJqTb2ggZ4KRqILk36iBHH6NBrJl1ap53KsHkI81VgG83D+8CRV2
jd4tWKXs5l5Z+v9DSZrDwOgajmXXVD+PLfJ98EakcleJufZ08mWygzlj8VX2
xd6w7L/r8XmJON2U50kZ++Ybc35qa2SFuXQgE+woDnWm9Wj1nuZc4IJVSYEa
mam+dseut2OhcJtbnmbrSsttmHka2bbaIzP3JWvHwMZ/Yme3hMV6sztA2S2x
3Hxb1ei9ZRO0XMZ+kU/2xJLqIFXtACJTYmIklDmtOqVVSiLtICQYYHoPWxVl
45LLr4nKWBPYFenaJ8jjpewj7H1otb+JrShfLnMMaIxNcN+Os/v+BMUV503h
NmKNTZ3px3zZLfVBpC+qfjGCo/FctDBeHR+1+1qz1uZBf5tMh0OooxFrQFkR
z33JR/B1t7FnghvmX1ismAOCRDEYs/mIY1hOawp4GU4/0EAi7eJFdKO4S9eS
mJI2oYuTcmBlFZR7E8L9pQ2KdIDrJWhinBL1sGFnhw1nEpsRIZG5I8EC5Tb8
D95zQaFN8+Cu971LNNoqFuvIj4SOIbibdXUbBVaYYjexEzUKJOfGHBsNsmTh
7KJF7nGLVXVwtNLkkZkWV7/jxAotmkHRAFElZ2RW61XOZUkI0r7GUwiMmSSv
61CVN9LLGxcFjYJICHKTtKL5fu/7fYl0kg5ZwzlNvCmMl3KSpWpycGUhOOxI
003Qv8/txEyJC+7fpfHR0WFSuBd55tbSHorT2TnSyNc3/ooAoyg+v9WgupIq
oWykFG7pktHPo9eqDZy1oQ38osREXd1QkMSCUjj7bune8p2UkRiq72Ou3L3h
NqPQIwe4CO6+n9CjDSheVSFalkI9JWAWMUQogX8XcZSoKTxYZItWEr17zi9t
wIPnNg2Fswf96+VmcmccFKmdNLChEJ0ExYRJkRTliiJi+LWLYnUl7exC1WWt
5+GGYeYTD+OoxaGFL8XaxPFK3DxpoDDDcACpO6aoHJDYS226GsiJj4OKA8OG
Yv9wJ5vhWL8uFe6fmwkHc3WTVbk1EU4XJrdaLBpMdHorQWtR18D7B3t75JrA
oybO9wOTqkcb8+zzJLxzc3ul3UhBJ4glB/qMqjXxbYQrCEQE0f77kc+YpSI3
YjbzGNpDvkQ7S3r2o9VkQ6q0ZN5IxpNWYeLTYNe9hJZpXQ+V5njIka83z5R+
ns8dsmp+fN0/dyldYgolgYhwInUZfchALySks/VJBKWpCP8HqY/Va0Bjup/N
bqocY0K4hll7YwplU/lb1ga414uIJdE6WPbgiFLmdz4Icrg7IIevFDZxFQDE
jCRtnCa4mRZ54lLiXF5fZcAv01YtslW6yZfvZiHnabnK2pyD2qSARrRdNtVo
RVjN3Dfalc/vFZLViJwX4rh7NdPq7Bq7WWGcqmmmA8zHhRaFNwPZ1H6xvWRx
7ntA1hyGCYoedl8kmIS6sfacc1OIq8dcQozfkjpWUlU6TgLbLPfJxjiKaUAB
iZrpYfV/fAlDrKiMnYdezHKcIFuc+JZk5W1eVyV3rcAOwitQgVAFrhANsK40
x30b0Rp4W6glSTInLX2+LtMlZukBLelEeWMpsJXmsWkDH2kjS7yGim8u6rmB
6U54WKj4BhimxTUC42bZr/rvq0hR0jWmpcxGDvlG9vEGaBExDsyqxM7sc1NA
cLjHUhVSaU2WLBlOTX1/WSqVfsHcjIHB+h0TtR2FrUGohQeTMxuKz1OQRIyr
CY2sSNeh+jomLjxGkQnmKdVCbIII32y2zpoo+TANhUh0kzuvZxNan9WU2tZG
DCAkl+/YHOCR90KLAKzPhxslwXJY3mPg68l9RTKC9INg984BLXUROooBM6Bg
SAnj1DLSv37fbkvVjn56Myz/1dZKDxqGalUGb2VJxHEGbCwqk2n6QnIVbakJ
lWrlIV9DJ47qCbF+tRcgsEbDJulT9wMxrtCKmcsvAGHIyqarfbCVqRbZhfoT
IeKQu30WXN7QuCPmxFbP/yHAaBsLDxPHyZAtlRKVwBEmjEPTUEQFV0Sh28XV
o7jOycggSwiCBELoi2NIyghXFaFMcqkRFkz0mLasgnFROCV/yt2AQ0UGenTB
1Jl6doSZhro7wIqTAm3B2B8kjCzKNgesIT3Nsrkv8SFVK/JSNHaiBqbHxK30
EqFSnKFtONXKotpdoYOML/1JUsLvmHL5g48yojRxgPLMlU+zVOyJdFlRN1AQ
Uqh/O1mnQ887Vcm1AT010QUtcyQ+mdqEYvlWgqhLzTM2oNguOUxDah+wiTcF
9l2pQ9nr/8TctUiAlw68sGPlUZTJt9dwsT1UopJCE7S75lSvOJ3mWk/ZhKEG
/dKTdh2Ak5L4eknyUO5bFy4l0z+lZvSm3zA31fFLMuIwS3vbN0FDwllid6dQ
N2frbeK6nQlmcUoNMxMNBTKg6CiNmmtQKy0w2ZaIPPau2Aa0keh/8by26glf
C8VflyQyt7TYKZPtr1JVsXDL3MH9CxkeioCi5mfEZE4i3ljIxjbihW9lxaHI
MWaCM/hAFaullwqjcRDaEfisk5JAhQHRklu5zfow3KYqoMCYqqngddaEU0Or
Uyub2N3RXfV4TLc1Ml8Z8b4lHOPL+lpQN24PrXWP0Zht2xFFmfbMueERzlST
4mc8vsYAsFdgoKxRHHvi06VJqBUJjSaIosZtMzOlTbgPqUNrK1zwukaxwctn
o5nSl0AiQDqrpWkOviZl2auOfWVDe9Ce7Rs1uaUp9z2vJFk7kyYGEnYtqqTz
1Egc12RI5Yq/El1OTA35Yq/Wd1tV0vuI0wscSP1o06Xzwz3C9ygTWpMRUrgp
CDUfQpiHZrarb1TeLNAsGb84z1BhsaZnrHVzzU4nXzbhupL2CAadrA/V9qhN
5dRNmXFx+/vzl7qJGF+/4sKsXhZke4SYuJpQ8rvAO1Wsowqfpr6YHoHz3FGT
bGllBYkrcSSIgb6kWhfrDYXA2ex+n4zqYcWBcOQ1EjumP3qT72sKjZ4zQqTB
aCkj+mIZtA4cSc18Pdho2zeM1ff8apL8iLcYaCjRH6pi78kRM/gm4s6pue5y
6jkGtpdJFDsjx++hItZ3wbMpKtyzottscMD5mFxE+e3lz5gV9PL88owqkZ8d
n55daJsgKe4XpY8TvXmp4sOP6ewDUqETr0E3m7Vnlc2qycao29IKDbDCVGIj
05kvRzaVKcJbjaQfYwCxYGDP/lB3yJQbEUtGeLWCrurnEXWUdAIV7ySEJi7s
5h0dagWXds9uQYgv0iDdcrJ8pZzTnF5T0dIqGdjCyNhkVplnSyGTvu/za7DY
nlWmq0WbGeaHM7YyeAIzY8Kdo5eaQNDTad2tqLFEUZEWbVaUpJqPnNXUYBMb
5aFgnVeUgeSw1Yi0TGG2bFKpc03GJ/4xUHFAmLyciAtiVO/kpOsa5Qr6lkos
z4Ae1PHGg3KkFaotv7GV+fGcxFvDnE18UhnVwbOFcggLqFKkRwU24eZ0EQa6
pWvFUb9K1Dd4kdEa+W5LOC/3cqCkKmmhwPZPYwsSy7i2anjJhvhPDwf6H2hl
uF5QRxQGF7d8kBT6AdmcwpOjDtYhoJaceuLeLo0ObnRH4ZEN0kB/d3Vue+XY
67DV/hFK80WhxS4gOh/1gM1LG2zdX6MTO8APdjiP2shYOyq2mklzOntftagq
w+4E6KQqeyLAqqTm/keN2a2V+wq/QM03CT0f9bZenbwhbMDgDR/MW2dFrlUM
pmvp3EYXCYlM6+Bik7ZGAq1WJqYHioo8Z15UpTxT9ah75hEbmrdBa9QTZOPG
8NKrgjMwyYosaUdldufwOy2fhXHx3rBjDd95M+toH731kCzMMV0IFWr/obGF
+4fcQBG/gPOkIOMmeRAopo//ViXa9ZYNL9PK6eKrkU97b2AbLKpEZ9hA3zNj
q7EF3zOhwl3eZA9C3QyJB7LP+3jSYFWN2/Vs9pgXUkEI0npM6ilETbfCj5vB
xfmcSZ0UNaUwlBa+oDPQTHJuweqsPB5SIbLSogY1B/DdSyKkNJjCvG+atS2p
Jq3wRVOO29vPzB6MI4dlTO4QqDmcS02pZ9tL2NPspqqansRlyoDH9b2jMrmq
WooFm0ZvcAXokxJlis6kTufZuFos2LbOuoKJYfYAYXW9Z0bWSFcOoNqEFof3
sW05SMQSzYcxaDKjQfTBcWgCXYrLazEFo0bl66RzU944fpeyyf6AODdGnf6P
Zxd/lnbzB0hG0c+COyq4c2p0gVGbsFhorlKU3oVNWDOhaCqYvKHProAdkz8R
ftaoT+S1IMMxX4Nh5M+1QZFUStwIBcJ6cLbKe8DzZCueEyKF5RJhI3r/HLhF
iaTi08OF/Irxthq6M2IxeKPht3eLkBMCCSPrGuY6hv7nTkf2PkcrywU3H1cP
9/5Foj82kIATB0VGIu28poTlWIYbBQF5CbhNRWBTsrx7AZVVJVJNHbFCkniN
KX2KPDszwRhevholUSm+zaJVbgYqLvYhIEtErC1Qw+RBJYGrn5ceUDOqiLPC
GP98saFMetP5hHpN0Xy2+tPN/lhmwcJxwqEAZ1osU2OlbqYhNJFylbAIbJCK
Veap5u6ISseimYhi2sbhsTCDOIJi/5t5CYRpL4F2JQCFAkhVPEYaVy2zCDci
WMf8xrcHBb3vxIOgrwKiKOrBoyJov9+IHFjTQzZAgVx7nnsjtGIJddpG5+9G
ayyDZ746Odlu5Ny112SkAjhFSXFj4MiRp4O7sISuQkQTjGMvaNZYMJET8ewG
vIzHFk6ENKJz049VMEEaNUj9UjgK+wD2wYZ9mKfZOthuNoPOm4HiTmqUG5vG
787aO1GGkHiUvsTT6xpABZRs8X8Ua0z7Ad++wjNfiWa7q2pSpaRIPQiwa5DQ
2xorzYegCA9S4KUFdf4GUrKBCHo8XVR2Xk9eS1dKxV5xC5GtjNwcLTd3kxbI
eGgeZ9KSzoy8dL5KaSKXWMpreHohrcCN7XjmHTeh6QM5eDZDjSgyzjpz0F+1
GYanIgVHEzikH6iNUZVnPy1O1iQbU1ApEH9Jo4qZJRmMaLWieYsNxtoStUNJ
Xgc3ndW/Q0V646GNm+iSEYkQYwzAyinQo8zqXSG+SHEBLz5IeWRn0LPn32vp
sVkKPJ80G4MyMVhF5MXjd3T8Pgwqeo5LjDRmr9QMUQM3SdXh5g8q+lkbc6+3
bG5kaqo5bU2ToS90vjCa+Cz1zXk3QkiJwyIwFvl1x/ILSW5T7nuCtwHtuwsN
3pURNSvfxA97O4qLCtYdYbXY556nf/r0h+evL345vjg9O0VR7enB4TPU4f40
9s/gb/DOH/O0X5vi6eS70Jj+8+fdkEW4P/lIBkA0SiFXsBxSaSKq6RU3Ejs5
fYWSdZ02mo3DtcZJQDNiATEMKQmm9gaUKCigh+sYUm10+IN9POHSmFjQBTdJ
oysqVkaeSatSmCJnbPMLNaZEH9ZZPPMl3auUWuhOYLDv64aRims4VbicvDIE
ALljH4B2sOw+PoiFGIxwndWoK1tubRgd71inpQ1UBR66lFdXUCrOO6WrH9ld
MBzNRiYxb6JvyUMQE0DTSHcDJFQ3qsVNIVXUZADCxSbOUQz+BfdjfxTRzCmO
Z1Mn8yEwm4VK2U0o6SLmY+8Vr1aZDwS/zecoHRm5FFhph9Sy1VNH2VBKF2Xa
miyMGvfBIGYBG/og5phgLhfRDH+nFoYa1vA2yKKfHm4R/O4VJiggwKh1Q/yc
pJwQW0hCNgsqI2IkuXYPmWvwSy7L5NJqYv0NhsywuIiTR6ZjpsrcL3w4CFIi
XOg6Y1MXK6n3GhzErlptsD4DYYQjvmfY56SRK0aJn9hCC6MA7b2h7NuSW0nd
ZmvbQsljkqmqKzY3lYacSEOcC2EihSRLJDT+hVWRsVidkhFcJEChalqMECcR
Rbmw78aCIJaGTag8/nKz5i2XSFex3tYZUipT4fgPvRLHpkEkyTUElLTxJaaG
mZpQdCoyp9nMUQVDzki6J305D333MPTClziW+DZyqXICyEYQW9weNdUSsGtb
qt5HuMvb1yHfzvLFEVEtSbbuM1vq7OX72FNwpovLMevM8OTPnKXUZAPfsx9j
sPmni0sYcyPNAbjH1yLqsoVBXxl1zjGBqPFpkGkdIPtz6uW44VMZPBKqfrpE
7oCJfkiXpYKtixVtgAJ1Ex6qGY2lbWneqFRIbxFOoIC9iELGSlR2qwN2ocQr
Gkqq8UZVY6MQbfOQqRFQxs7me3DUGYDYQLUA5gkHo8862tJJZHxGO5h2w90a
mW3c6iyCioF8uMs92daGm4NLj2MfYcTxMI1xicT2PcEndusqEccr6OtAU3BN
5ktwqhPBNjCUxG+5wI3Cob9HlGpBQNysZq3xE751GO9+sLVr1LLT5sfQGZwf
vzregD8H3UV16rWDRz9RHYBXr307jzVeYSzcQO4WOBVQsNnbkuwgEdyVPHOs
0x9aSPh253znuRTu588gXPPTpVT194TAXVKqCn6GgeJpieHMvd4ParzfaXY5
od22Fv0Htsik/DIjX0+TaE1+t7EJlP+fPN6jfWhfAl/v59Xrd/L9O8HY87NL
NFnN6bm9j8+Qw3Coxq0m5e/19jiwr39wW1xpAassuHrr6diNhRfogHqXz+xn
/5+/+Dy0/hT94quWLxUxvmXxXBEEaarkUX95L2+xrc+qm6olfJQAdcGE3hnl
GvtVD6YGm0YP7psaPVA372rVFZyKGRhDgBcQQhwptOcYI3yA1mo5K9/g5zMR
WbSlRH1tgN7MMYYbyMf/JGP8l8jPX/Pv3neT/4EpiFbAY6Y3R/Jt//4niUlD
/KXZxdGv3MTRl3fRyUquTN5Dtdlxc3LfLkxyxMaXMEUuj/1yk3HU3rd185zw
FFEOwjZA/Uo4ffm4sejKEHpqrRWliQO3Bkut4CCofyBnO44bXABbu6ikzgn7
kojzS5wkcL+UFATuvhbLNqxeywt5yIEUAuRv6N3dHXVxoFtKUM5wqubR94eP
mgKjz+TH+PtD3+nhyWQ1X/yeYuL8QNdwbbvpZFYtH62WIMqmJV30w3Es6WIq
5Kpq0uL3I4ADhvx8SF7S4y6d31bsd+svPpKYs8bvuO3QMGwaN6OKbupecCiB
EWbmeUMno3WnYyGcvLvNKmfLMxCdP2CPiwIoSbb2BGvcMBtFGxlnujKR/rFO
58kLepZI2otuBlI2HPUcm4JSWht1EZQLbfLfFgBysp2Q4HYntSoAp6sahHLu
ZlqSfVrN8K00a1TSLTLZsmpziZDm7jnSpgdDrEInPHy7t38uH4AVjUpuvi7+
Jc0sF441rTG9RML0pOvbhOkUN61BkymMflFNQaSqkjcZ8BD3EmOlSziJatlI
ENcrQLgi/8j+D18z646y0s2uNSK0WGt4g93xQIDKKqsQIdIpKOG9zuwJdlPG
yPnKq77Sdew2s9u1Td6MP4IbR3PFQO4+LbL7cQHQfV5jqEpRjNxxOa+zu+Qn
dLuV+Sg5qdP8OrlC0bkeJefw7OUd4M8o+Y/0791Nlbz+0I16qPIybWEFdyDg
fgTgoe3wR5AEqtUohiv+BYsF6H7E3wOVAND8OcXKHjc5a/tkpZc6N+qPLfte
f2uCw9xf7iPyorp27rcgPCVnp+dXry+OVCLA6oZaclwHlcQ2I0D8lqxe3IIO
sGvRjqOGMf5K7e+738qUXG1wPid38gs0VJwALB+BpPmTvyhfO+oejHoGGAJ/
YoUJHh8+O56jkS8DtbpmXQKNxHU3C1raJqkOQcgsqqD57OuWsfdscBlf+fL3
HjJFhSW2Pnarr373KbWFK9KPSRz2sjBJW/dL9xLjI0tORCXfebj/dP/xKIEf
B092cYHYTnSxHuooFcx0EiN420y8DZgGekIDHdJAG6vtFe4dqI3DOQ54cWFx
HEYq5bxgvbYJC072eJ8me/Ld7tfC8DtylgB1wDuTDSCT7p3Dijmj63IxNr2e
fOwhtk/kncN7lxSpwLXgucCeRzXCSS9PE+3HRoWNWg495wjt+752O08IyKic
zsPRn569uTg7AWAOYkCFNbTv1wEDFCR5h0onqDFBmI3wTZ9Ah1kmli3B+Xz3
9BmWuYMT2nvy1Sf0+P4tUWHb7Ru6d++4pL19RkyYTUQvYlgV+wrlJVgRPvzk
O8IveUdhEvsefVMofPzgq3d5KHSLIhc5wI9Q7Y7DmUPCYYjMnfgV+P6aXAcg
0X6GWICY2kBLw2gpxbRssgKt2LjEJ3u4oydPnuGOTjX/25Zy2LRxbUYW41CP
n9FNf/L48TcMZcJUAfQUmoZDHTyjofZoqEtO7R6mPDa2vC/vfeMRHNhlbzft
UcbM5kx7T77DNR8+fsLbJ4BvKQR/fqqdGfLQ7QX2RkdywEh2yHBEnEjvV8jh
ncOn+1+9zX30D29pACIsGrfzjLaz95ROAm4u/jj47oB/8F9P93WFKiLYcgfN
RrWIHkxxr8wdDg5l3O/4LpLs4dsHR9ybIvPUrWfunXeu4doPZLjHXw2UPQTK
SxJ58Pqn7CuiFfJe97/fHWDzKmpqRpAPkLny9m24uYea8IEScCimhhUoOU+w
woi0DMgGsCE5g8nGyj+QRDlIIHHtIL8s0RocFdt/a7M9BTaHdK4HAmpK6/B5
ACFhOQ428QEQ/apQIR0r4dHtCS7Zx4kLOTl9NX5RVSt6CO/ksOT2EhMxFAvn
3An8l59AXqzIxuKHBu7YtVylN7IT4/B4Ul8Nu0Pn5a+51GH3EV7v/zLeH333
V64B9Je90VP4defh0+95h5RNbnsqM3kus+sKi9uoatVTxdbkw81mgWzsEYnD
dstZaWSEkoQpfIARj0IXk6ocuER7T/im0v/zdSWivk90ZP/wG8BxQOCAcUFs
mUfl7yQcwPCnnYdEqJ4eGnrn2a5hskg6LVR2Hj75Ht777pl574v96UzABry/
LyAp0M/hb770NCzniQ3MhMcHpMGtECDqqEPjRdjoCBh8KhxyQe2Mv3b4PRcO
s4svJ+HcISLb9xP3/wCGpqEiqsQAAA==
</rfc> </rfc>
 End of changes. 168 change blocks. 
1120 lines changed or deleted 381 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/