<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!-- [CS] updated by Chris 01/21/22 -->
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.24 -->
<?rfc docindent="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-priority-12" number="9218" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.0 -->
  <front>
    <title abbrev="HTTP Priorities">Extensible Prioritization Scheme for HTTP</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-priority-12"/> name="RFC" value="9218"/>
        <author initials="K." surname="Oku" fullname="Kazuho Oku"> asciiFullname="Kazuho Oku" fullname="奥 一穂">
      <organization>Fastly</organization>
      <address>
        <email>kazuhooku@gmail.com</email>
      </address>
    </author>
    <author initials="L." surname="Pardue" fullname="Lucas Pardue">
      <organization>Cloudflare</organization>
      <address>
        <email>lucaspardue.24.7@gmail.com</email>
      </address>
    </author>
    <date year="2022" month="January" day="18"/> month="June"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>
    <keyword>Internet-Draft</keyword>
<keyword>Response priority</keyword>
<keyword>Stream multiplexing</keyword>
<keyword>Reprioritization</keyword>
<keyword>Server scheduling</keyword>
    <abstract>
      <t>This document describes a scheme that allows an HTTP client to communicate its
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
should be prioritized when they are forwarded.  This document defines the
Priority header field for communicating the initial priority in an HTTP
version-independent manner, as well as HTTP/2 and HTTP/3 frames for
reprioritizing responses. These share a common format structure that is designed
to provide future extensibility.</t>
    </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.org"/>),
        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.org/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/httpwg/http-extensions/labels/priorities"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <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
often discover these relationships while processing a retrieved representation,
which may lead to further retrieval requests.  Meanwhile, the nature of the
relationship
relationships determines whether the a client is blocked from continuing to process
locally available resources.  An example of this is the visual rendering of an HTML
document, which could be blocked by the retrieval of a CSS Cascading Style Sheets (CSS) file that the
document refers to. In contrast, inline images do not block rendering and get drawn
incrementally as the chunks of the images arrive.</t>
      <t>HTTP/2 <xref target="HTTP2" format="default"/> and HTTP/3
<xref target="HTTP3" format="default"/> support multiplexing of requests and responses in
a single connection. An important feature of any implementation of a protocol
that provides multiplexing is the ability to prioritize the sending of
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
HTTP responses, or the chunks of those HTTP responses, that it sends to a
client.</t>
      <t>HTTP/2 and HTTP/3 servers can schedule transmission of concurrent response data
by any means they choose. Servers can ignore client priority signals and still
successfully serve HTTP responses. However, servers that operate in ignorance
of how clients issue requests and consume responses can cause suboptimal client
application performance. Priority signals allow clients to communicate their
view of request priority. Servers have their own needs that are independent of
client needs, so they often combine priority signals with other available
information in order to inform scheduling of response data.</t>
      <t>RFC 7540 <xref target="RFC7540" format="default"/> stream priority allowed a client to send a series of
priority signals that communicate to the server a "priority tree"; the structure
of this tree represents the client's preferred relative ordering and weighted
distribution of the bandwidth among HTTP responses. Servers could use these
priority signals as input into prioritization decision-making.</t> decisions.</t>
      <t>The design and implementation of RFC 7540 stream priority was were observed to have
shortcomings, as explained in <xref target="motivation" format="default"/>. HTTP/2
<xref target="HTTP2" format="default"/> has consequently deprecated the use of
these stream priority signals. The prioritization scheme and priority signals
defined herein can act as a substitute for RFC 7540 stream priority.</t>
      <t>This document describes an extensible scheme for prioritizing HTTP responses
that uses absolute values. <xref target="parameters" format="default"/> defines priority parameters, which are
a standardized and extensible format of priority information. <xref target="header-field" format="default"/>
defines the Priority HTTP header field, a protocol-version-independent and which is an
end-to-end priority signal. 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
intermediary can use it to signal priority to the intermediary. After sending a
request, a client can change their view of response priority (see
<xref target="reprioritization" format="default"/>) by sending HTTP-version-specific frames as defined in
<xref
Sections&nbsp;<xref target="h2-update-frame" format="default"/> format="counter"/> and <xref target="h3-update-frame" format="default"/>.</t> format="counter"/>.</t>
      <t>Header field and frame priority signals are input to a server's response
prioritization process. They are only a suggestion and do not guarantee any
particular processing or transmission order for one response relative to any
other response. <xref Sections&nbsp;<xref target="server-scheduling" format="default"/> format="counter"/> and <xref target="retransmission-scheduling" format="default"/> format="counter"/> provide
consideration
considerations and guidance about how servers might act upon signals.</t>
      <section anchor="notational-conventions" numbered="true" toc="default">
        <name>Notational Conventions</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
        "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
        "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14
        <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
        <t>The terms Dictionary, sf-boolean, sf-dictionary, and sf-integer are imported
        <t>This document uses the following terminology from <xref target="STRUCTURED-FIELDS" format="default"/>.</t> section="3" sectionFormat="of" target="STRUCTURED-FIELDS"/> to specify syntax and parsing: "Boolean", "Dictionary", and "Integer".</t>
        <t>Example HTTP requests and responses use the HTTP/2-style formatting from
<xref target="HTTP2" format="default"/>.</t>
        <t>This document uses the variable-length integer encoding from
<xref target="QUIC" format="default"/>.</t>
        <t>The term control stream "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" sectionFormat="of" target="HTTP3" format="default"/>.</t>
        <t>The term HTTP/2 "HTTP/2 priority signal signal" is used to describe the priority information
sent from clients to servers in HTTP/2 frames; see <xref section="5.3.2" sectionFormat="of" target="HTTP2" format="default"/>.</t>
      </section>
    </section>
    <section anchor="motivation" numbered="true" toc="default">
      <name>Motivation for Replacing RFC 7540 Stream Priorities</name>
      <t>RFC 7540 stream priority (see <xref section="5.3" sectionFormat="of" target="RFC7540" format="default"/>) is a complex system
where clients signal stream dependencies and weights to describe an unbalanced
tree. It suffered from limited deployment and interoperability and was has been deprecated
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="of" target="HTTP2" format="default"/>), which
means that they might still be used even in the presence of alternative signaling,
such as the scheme this document describes.</t>
      <t>Many RFC 7540 server implementations do not act on HTTP/2 priority
signals.</t>
      <t>Prioritization can use information that servers have about resources or
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
that are critical to user experience above other images.  With RFC 7540 7540, it is
difficult for servers to interpret signals from clients for prioritization prioritization, as
the same conditions could result in very different signaling from different
clients. This document describes signaling that is simpler and more constrained,
requiring less interpretation and allowing less variation.</t>
      <t>RFC 7540 does not define a method that can be used by a server to provide a
priority signal for intermediaries.</t>
      <t>RFC 7540 stream priority is expressed relative to other requests sharing the same
connection at the same time. It is difficult to incorporate such a design into
applications that generate requests without knowledge of how other requests
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>
      <t>Experiments from independent research (<xref <xref target="MARX" format="default"/>) format="default"/> have shown
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
web
Web use case.</t>
      <section anchor="disabling" numbered="true" toc="default">
        <name>Disabling RFC 7540 Stream Priorities</name>
        <t>The problems and insights set out above provided the motivation for an
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
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
SETTINGS_NO_RFC7540_PRIORITIES <bcp14>MUST</bcp14> be 0 or 1. Any value other than 0 or 1 <bcp14>MUST</bcp14>
be treated as a connection error (see <xref section="5.4.1" sectionFormat="of" target="HTTP2" format="default"/>) of type
PROTOCOL_ERROR. The initial value is 0.</t>
        <t>If endpoints use SETTINGS_NO_RFC7540_PRIORITIES SETTINGS_NO_RFC7540_PRIORITIES, they <bcp14>MUST</bcp14> send it in the first
SETTINGS frame. Senders <bcp14>MUST NOT</bcp14> change the SETTINGS_NO_RFC7540_PRIORITIES value
after the first SETTINGS frame. Receivers that detect a change <bcp14>MAY</bcp14> treat it as a
connection error of type PROTOCOL_ERROR.</t>
        <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
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
server that receives SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 <bcp14>MUST</bcp14>
ignore HTTP/2 priority signals.</t>
        <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>
        <t>Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to use
alternative priority signals (for example, see <xref target="header-field" format="default"/> or
<xref target="h2-update-frame" format="default"/>) format="default"/>), but there is no requirement to use a specific signal type.</t>
        <section anchor="advice-when-using-extensible-priorities-as-the-alternative" numbered="true" toc="default">
          <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
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 HTTP/2
priority signals and the signals of this prioritization scheme (see
<xref
Sections&nbsp;<xref target="header-field" format="default"/> format="counter"/> and <xref target="h2-update-frame" format="default"/>).</t> format="counter"/>).</t>
          <t>Once the client receives the first SETTINGS frame that contains the
SETTINGS_NO_RFC7540_PRIORITIES parameter with a value of 1, it <bcp14>SHOULD</bcp14> stop sending
the HTTP/2 priority signals. This avoids sending redundant signals that are
known to be ignored.</t>
          <t>Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES with a value of 0
or if the settings parameter was absent, it <bcp14>SHOULD</bcp14> stop sending PRIORITY_UPDATE
frames (<xref target="h2-update-frame" format="default"/>), since those frames are likely to be ignored.
However, the client <bcp14>MAY</bcp14> continue sending the Priority header field
(<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>
        </section>
      </section>
    </section>
    <section anchor="applicability-of-the-extensible-priority-scheme" numbered="true" toc="default">
      <name>Applicability of the Extensible Priority Scheme</name>
      <t>The priority scheme defined by this document is primarily focused on the
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"/>) and a means of conveying those
parameters (<xref (Sections&nbsp;<xref target="header-field" format="default"/> format="counter"/> and <xref target="frame" format="default"/>), format="counter"/>), which is intended to communicate
the priority of responses to a server that is responsible for prioritizing
them. <xref target="server-scheduling" format="default"/> provides considerations for servers about acting on
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
tunnels. Signaling applies similarly to tunnels; additional considerations for
server prioritization are given in <xref target="connect-scheduling" format="default"/>.</t>
      <t><xref target="client-scheduling" format="default"/> describes how clients can optionally apply elements of
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 behavior or
define new data carriage mechanisms. Such extensions can define themselves define
how this priority scheme is to be applied.</t>
    </section>
    <section anchor="parameters" numbered="true" toc="default">
      <name>Priority Parameters</name>
      <t>The priority information is a sequence of key-value pairs, providing room for
future extensions. Each key-value pair represents a priority parameter.</t>
      <t>The Priority HTTP header field (<xref target="header-field" format="default"/>) is an end-to-end way to
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
(<xref target="reprioritization" format="default"/>) by sending HTTP-version-specific PRIORITY_UPDATE frames as
defined in <xref Sections&nbsp;<xref target="h2-update-frame" format="default"/> format="counter"/> and <xref target="h3-update-frame" format="default"/>. format="counter"/>. Frames transmit priority
parameters on a single hop only.</t>
      <t>Intermediaries can consume and produce priority signals in a PRIORITY_UPDATE
frame or Priority header field. Sending a PRIORITY_UPDATE frame An intermediary that passes only the Priority
request header field to the next hop preserves the original end-to-end signal
from the client carried by client; see <xref target="header-field-rationale" format="default"/>.
An intermediary could pass the Priority header field, but provides field and additionally send a
signal that overrides that for PRIORITY_UPDATE frame. This would have the effect of preserving the original client end-to-end signal, while instructing the next hop; see hop to use a different priority, per the guidance in <xref target="header-field-rationale" format="default"/>.
Replacing target="frame"/>. An intermediary that replaces or adding adds a Priority request header field overrides any signal from a the original client
and end-to-end signal, which can affect prioritization for all subsequent recipients.</t> recipients of the request.</t>
      <t>For both the Priority header field and the PRIORITY_UPDATE frame, the set of
priority parameters is encoded as a Structured Fields Dictionary (see
<xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS" format="default"/>).</t>
      <t>This document defines the urgency(<tt>u</tt>) urgency (<tt>u</tt>) and incremental(<tt>i</tt>) incremental (<tt>i</tt>) priority parameters.
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>
      <t>An intermediary can combine signals from requests and responses that it forwards.
Note that omission of priority parameters in responses is handled differently from
omission in requests; see <xref target="merging" format="default"/>.</t>
      <t>Receivers parse the Dictionary as defined described in <xref section="4.2" sectionFormat="of" target="STRUCTURED-FIELDS" format="default"/>. Where the Dictionary is successfully parsed, this document
places the additional requirement that unknown priority parameters, priority
parameters with out-of-range values, or values of unexpected types <bcp14>MUST</bcp14> be
ignored.</t>
      <section anchor="urgency" numbered="true" toc="default">
        <name>Urgency</name>
        <t>The urgency parameter (<tt>u</tt>) takes an integer parameter value is Integer (see <xref section="3.3.1" sectionFormat="of" target="STRUCTURED-FIELDS"/>), between 0 and 7, 7 inclusive, in descending order of priority.</t>
        <t>The value is encoded as an sf-integer. priority. The default value is 3.</t>
        <t>Endpoints use this parameter to communicate their view of the precedence of
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
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
<tt>0</tt>:</t>
        <sourcecode type="example"><![CDATA[
        <artwork type=""><![CDATA[
:method = GET
:scheme = https
:authority = example.net
:path = /style.css
priority = u=0
]]></sourcecode>
]]></artwork>
        <t>A client that fetches a document that likely consists of multiple HTTP resources
(e.g., HTML) <bcp14>SHOULD</bcp14> assign the default urgency level to the main resource.  This
convention allows servers to refine the urgency using
knowledge specific to the web-site website (see <xref target="merging" format="default"/>).</t>
        <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 fetching
responses that have any impact on user interaction.</t>
      </section>
      <section anchor="incremental" numbered="true" toc="default">
        <name>Incremental</name>
        <t>The incremental parameter (<tt>i</tt>) takes an sf-boolean as the parameter value that is Boolean (see <xref section="3.3.6" sectionFormat="of" target="STRUCTURED-FIELDS"/>). It indicates
if an HTTP response can be processed incrementally, i.e., provide some
meaningful output as chunks of the response arrive.</t>
        <t>The default value of the incremental parameter is false <tt>false</tt> (<tt>0</tt>).</t>
        <t>If a client makes concurrent requests with the incremental parameter set to
false,
<tt>false</tt>, there is no benefit in serving responses with the same urgency concurrently
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
requests were generated generated, is considered to be the best strategy.</t>
        <t>If a client makes concurrent requests with the incremental parameter set to
true,
<tt>true</tt>, serving requests with the same urgency concurrently might be beneficial.
Doing this distributes the connection bandwidth, meaning that responses take
longer to complete. Incremental delivery is most useful where multiple
partial responses might provide some value to clients ahead of a
complete response being available.</t>
        <t>The following example shows a request for a JPEG file with the urgency parameter
set to <tt>5</tt> and the incremental parameter set to <tt>true</tt>.</t>
        <sourcecode type="example"><![CDATA[
        <artwork type=""><![CDATA[
:method = GET
:scheme = https
:authority = example.net
:path = /image.jpg
priority = u=5, i
]]></sourcecode>
]]></artwork>
      </section>
      <section anchor="new-parameters" numbered="true" toc="default">
        <name>Defining New Priority Parameters</name>
        <t>When attempting to define new priority parameters, care must be taken so that
they do not adversely interfere with prioritization performed by existing
endpoints or intermediaries that do not understand the newly defined priority
parameter.
parameters. Since unknown priority parameters are ignored, new priority
parameters should not change the interpretation of, or modify, the urgency (see
<xref target="urgency" format="default"/>) or incremental (see <xref target="incremental" format="default"/>) priority parameters in a way
that is not backwards compatible or fallback safe.</t>
        <t>For example, if there is a need to provide more granularity than eight urgency
levels, it would be possible to subdivide the range using an additional priority
parameter. Implementations that do not recognize the parameter can safely
continue to use the less granular eight levels.</t>
        <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 being requested is
within the viewport.</t>
        <t>Generic priority parameters are preferred over vendor-specific,
application-specific
application-specific, or deployment-specific values. If a generic value cannot be
agreed upon in the community, the parameter's name should be correspondingly
specific (e.g., with a prefix that identifies the vendor, application application, or
deployment).</t>
        <section anchor="register" numbered="true" toc="default">
          <name>Registration</name>
          <t>New priority parameters can be defined by registering them in the HTTP Priority
Parameters Registry. The "HTTP Priority"
registry. This registry governs the keys (short textual strings) used
in the Structured Fields Dictionary (see <xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS" format="default"/>).
Since each HTTP request can have associated priority signals, there is value
in having short key lengths, especially single-character strings. In order to
encourage extension extensions while avoiding unintended conflict among attractive key
values, the HTTP Priority Parameters Registry "HTTP Priority" registry operates two registration policies policies,
depending on key length.</t>
          <ul spacing="normal">
            <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" target="RFC8126" format="default"/>.</li>
            <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" target="RFC8126" format="default"/>. A
specification document is appreciated, appreciated but not required.</li>
          </ul>
          <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
for rejection.</t>
          <t>Registration requests should use the following template:</t>
          <dl>
            <dt>
Name:  </dt>
            <dd>
              <t>[a name for the Priority Parameter priority parameter that matches the parameter key]</t>
            </dd>
            <dt>
Description:  </dt>
            <dd>
              <t>[a description of the priority parameter semantics and value]</t>
            </dd>
            <dt>
Reference:  </dt>
            <dd>
              <t>[to a specification defining this priority parameter]</t>
            </dd>
          </dl>
          <t>See the registry at <eref target="https://iana.org/assignments/http-priority">https://iana.org/assignments/http-priority</eref> target="https://www.iana.org/assignments/http-priority" brackets="angle"/> for details on
where to send registration requests.</t>
        </section>
      </section>
    </section>
    <section anchor="header-field" numbered="true" toc="default">
      <name>The Priority HTTP Header Field</name>
      <t>The Priority HTTP header field is a Dictionary that carries priority parameters (see <xref target="parameters" format="default"/>).
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.
<xref target="merging" format="default"/> describes how intermediaries can combine the priority information
sent from clients and servers. Clients cannot interpret the appearance or
omission of a Priority response header field as acknowledgement that any
prioritization has occurred. Guidance for how endpoints can act on Priority
header values is given in <xref Sections&nbsp;<xref target="client-scheduling" format="default"/> format="counter"/> and <xref target="server-scheduling" format="default"/>.</t>
      <t>Priority is a Dictionary (<xref section="3.2" sectionFormat="of" target="STRUCTURED-FIELDS" format="default"/>):</t>
      <sourcecode type="abnf"><![CDATA[
Priority   = sf-dictionary
]]></sourcecode> format="counter"/>.</t>
      <t>An HTTP request with a Priority header field might be cached and re-used reused for
subsequent requests; see <xref target="CACHING" format="default"/>. When an origin
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
the applicability of the cached response, response by using header fields that control
the caching behavior (e.g., Cache-Control, Vary).</t>
    </section>
    <section anchor="reprioritization" numbered="true" toc="default">
      <name>Reprioritization</name>
      <t>After a client sends a request, it may be beneficial to change the priority of
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
set to <tt>u=7</tt> (background). Then, when the user navigates to a page which that
references the new JavaScript file, while the prefetch is in progress, the
browser would send a reprioritization signal with the priority field value Priority Field Value set
to <tt>u=0</tt>. The PRIORITY_UPDATE frame (<xref target="frame" format="default"/>) can be used for such
reprioritization.</t>
    </section>
    <section anchor="frame" numbered="true" toc="default">
      <name>The PRIORITY_UPDATE Frame</name>
      <t>This document specifies a new PRIORITY_UPDATE frame for HTTP/2 <xref target="HTTP2" format="default"/>
and HTTP/3 <xref target="HTTP3" format="default"/>. It carries priority parameters and
references the target of the prioritization based on a version-specific
identifier. In HTTP/2, this identifier is the Stream stream ID; in HTTP/3, the
identifier is either the Stream stream ID or Push push ID. Unlike the Priority header field,
the PRIORITY_UPDATE frame is a hop-by-hop signal.</t>
      <t>PRIORITY_UPDATE frames are sent by clients on the control stream, allowing them
to be sent independent independently of the stream that carries the response. This means
they can be used to reprioritize a response or a push stream; stream, or to signal the
initial priority of a response instead of the Priority header field.</t>
      <t>A PRIORITY_UPDATE frame communicates a complete set of all priority parameters
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</bcp14> be treated
as a connection error. In HTTP/2 HTTP/2, the error is of type PROTOCOL_ERROR; in HTTP/3 HTTP/3,
the error is of type H3_GENERAL_PROTOCOL_ERROR.</t>
      <t>A client <bcp14>MAY</bcp14> send a PRIORITY_UPDATE frame before the stream that it references
is open (except for HTTP/2 push streams; see <xref target="h2-update-frame" format="default"/>). Furthermore,
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
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
scheduling, the most recently received PRIORITY_UPDATE frame can be considered
as the most up-to-date information that overrides any other signal. Servers
<bcp14>SHOULD</bcp14> buffer the most recently received PRIORITY_UPDATE frame and apply it once
the referenced stream is opened. Holding PRIORITY_UPDATE frames for each stream
requires server resources, which can be bounded by local implementation policy.
Although there is no limit to the number of PRIORITY_UPDATE frames that can be
sent, storing only the most recently received frame limits resource commitment.</t>
      <section anchor="h2-update-frame" numbered="true" toc="default">
        <name>HTTP/2 PRIORITY_UPDATE Frame</name>
        <t>The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to signal the
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
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
PRIORITY_UPDATE frame header <bcp14>MUST</bcp14> be zero (0x0). Receiving a PRIORITY_UPDATE
frame with a field of any other value <bcp14>MUST</bcp14> be treated as a connection error of
type PROTOCOL_ERROR.</t>
        <figure anchor="fig-h2-reprioritization-frame">
          <name>HTTP/2 PRIORITY_UPDATE Frame Payload</name>
          <sourcecode type="drawing"><![CDATA[ Format</name>
          <artwork type=""><![CDATA[
HTTP/2 PRIORITY_UPDATE Frame {
  Length (24),
  Type (8) = 0x10,

  Unused Flags (8). (8),

  Reserved (1),
  Stream Identifier (31),

  Reserved (1),
  Prioritized Stream ID (31),
  Priority Field Value (..),
}
]]></sourcecode>
]]></artwork>
        </figure>
        <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are
described in <xref section="4" sectionFormat="of" target="HTTP2" format="default"/>. The PRIORITY_UPDATE frame payload
contains the following additional fields:</t>
        <dl>
          <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 receiving.</t>
          </dd>
          <dt>
Prioritized Stream ID:  </dt>
          <dd>
            <t>A 31-bit stream identifier for the stream that is the target of the priority
update.</t>
          </dd>
          <dt>
Priority Field Value:  </dt>
          <dd>
            <t>The priority update value in ASCII text, encoded using Structured Fields. This
is the same representation as the Priority header field value.</t>
          </dd>
        </dl>
        <t>When the PRIORITY_UPDATE frame applies to a request stream, clients <bcp14>SHOULD</bcp14>
provide a Prioritized Stream prioritized stream ID that refers to a stream in the "open",
"half-closed (local)", or "idle" state. state (i.e., streams where data might still be received). Servers can discard frames where the
Prioritized Stream
prioritized stream ID refers to a stream in the "half-closed (local)" or
"closed" state. state (i.e., streams where no further data will be sent).
 The number of streams which that have been prioritized but remain in
the "idle" state plus the number of active streams (those in the "open" state or
in either of the "half-closed" state; 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
such a PRIORITY_UPDATE <bcp14>MUST</bcp14> respond with a connection error of type
PROTOCOL_ERROR.</t>
        <t>When the PRIORITY_UPDATE frame applies to a push stream, clients <bcp14>SHOULD</bcp14> provide
a Prioritized Stream prioritized stream ID that refers to a stream in the "reserved (remote)" or
"half-closed (local)" state. Servers can discard frames where the Prioritized
Stream prioritized
stream ID refers to a stream in the "closed" state. Clients <bcp14>MUST NOT</bcp14> provide a
Prioritized Stream
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>
respond with a connection error of type PROTOCOL_ERROR.</t>
        <t>If a PRIORITY_UPDATE frame is received with a Prioritized Stream prioritized stream ID of 0x0, the
recipient <bcp14>MUST</bcp14> respond with a connection error of type PROTOCOL_ERROR.</t>
        <t>Servers <bcp14>MUST NOT</bcp14> send PRIORITY_UPDATE frames. If a client receives a
PRIORITY_UPDATE frame, it <bcp14>MUST</bcp14> respond with a connection error of type
PROTOCOL_ERROR.</t>
      </section>
      <section anchor="h3-update-frame" numbered="true" toc="default">
        <name>HTTP/3 PRIORITY_UPDATE Frame</name>
        <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
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 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 push streams.</t>
        <t>The PRIORITY_UPDATE frame <bcp14>MUST</bcp14> be sent on the client control stream
(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
error of type H3_FRAME_UNEXPECTED.</t>
        <figure anchor="fig-h3-reprioritization-frame">
          <name>HTTP/3 PRIORITY_UPDATE Frame</name>
          <sourcecode type="drawing"><![CDATA[
          <artwork type=""><![CDATA[
HTTP/3 PRIORITY_UPDATE Frame {
  Type (i) = 0xF0700..0xF0701,
  Length (i),
  Prioritized Element ID (i),
  Priority Field Value (..),
}
]]></sourcecode>
]]></artwork>
        </figure>
        <t>The PRIORITY_UPDATE frame payload has the following fields:</t>
        <dl>
          <dt>
Prioritized Element ID:  </dt>
          <dd>
            <t>The stream ID or push ID that is the target of the priority update.</t>
          </dd>
          <dt>
Priority Field Value:  </dt>
          <dd>
            <t>The priority update value in ASCII text, encoded using Structured Fields. This
is the same representation as the Priority header field value.</t>
          </dd>
        </dl>
        <t>The request-stream variant of PRIORITY_UPDATE (type=0xF0700) <bcp14>MUST</bcp14> reference a
request stream. If a server receives a PRIORITY_UPDATE (type=0xF0700) for a
Stream
stream ID that is not a request stream, this <bcp14>MUST</bcp14> be treated as a connection
error of type H3_ID_ERROR. The Stream stream ID <bcp14>MUST</bcp14> be within the client-initiated
bidirectional stream limit. If a server receives a PRIORITY_UPDATE
(type=0xF0700) with a Stream stream ID that is beyond the stream limits, this <bcp14>SHOULD</bcp14> be
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
determining the active stream concurrency limit that is applied by the QUIC
layer.</t>
        <t>The push-stream variant of PRIORITY_UPDATE (type=0xF0701) <bcp14>MUST</bcp14> reference a promised
push stream. If a server receives a PRIORITY_UPDATE (type=0xF0701) with a Push push ID
that is greater than the maximum Push push ID or which that has not yet been promised, this
<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
receives a PRIORITY_UPDATE frame, this <bcp14>MUST</bcp14> be treated as a connection error of
type H3_FRAME_UNEXPECTED.</t>
      </section>
    </section>
    <section anchor="merging" numbered="true" toc="default">
      <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
HTTP responses deserve to be prioritized. The server might have additional
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
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
requests for a font <xref target="RFC8081" format="default"/> and images with the same urgency might give
higher precedence to the font, so that a visual client can render textual
information at an early moment.</t>
      <t>An origin can use the Priority response header field to indicate its view on how
an HTTP response should be prioritized. An intermediary that forwards an HTTP
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
its prioritization process. No guidance is provided for merging priorities; this
is left as an implementation decision.</t>
      <t>Absence
      <t>The absence of a priority parameter in an HTTP response indicates the server's
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 of their its default values value (see <xref target="parameters" format="default"/>).</t>
      <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>true</tt></t>
      <sourcecode type="example"><![CDATA[
      <artwork type=""><![CDATA[
:method = GET
:scheme = https
:authority = example.net
:path = /menu.png
priority = u=5, i
]]></sourcecode>
]]></artwork>
      <t>and the origin responds with</t>
      <sourcecode type="example"><![CDATA[
      <artwork type=""><![CDATA[
:status = 200
content-type = image/png
priority = u=1
]]></sourcecode>
]]></artwork>
      <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
value continues to be <tt>true</tt>, i.e., the value specified by the client, as the server did
not specify the incremental(<tt>i</tt>) incremental (<tt>i</tt>) parameter.</t>
    </section>
    <section anchor="client-scheduling" numbered="true" toc="default">
      <name>Client Scheduling</name>
      <t>A client <bcp14>MAY</bcp14> use priority values to make local processing or scheduling choices
about the requests it initiates.</t>
    </section>
    <section anchor="server-scheduling" numbered="true" toc="default">
      <name>Server Scheduling</name>
      <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
could be competition between the requests for resources such as connection
bandwidth. This section describes considerations regarding how servers can
schedule the order in which the competing responses will be sent when such
competition exists.</t>
      <t>Server scheduling is a prioritization process based on many inputs, with
priority signals being only one form of input. Factors such as implementation
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
to describe a universal scheduling algorithm. This document provides some basic,
non-exhaustive recommendations for how servers might act on priority
parameters. It does not describe in detail how servers might combine priority
signals with other factors. Endpoints cannot depend on particular treatment
based on priority signals. Expressing priority is only a suggestion.</t>
      <t>It is <bcp14>RECOMMENDED</bcp14> that, when possible, servers respect the urgency parameter
(<xref target="urgency" format="default"/>), sending higher urgency higher-urgency responses before lower urgency lower-urgency responses.</t>
      <t>The incremental parameter indicates how a client processes response bytes as
they arrive. It is <bcp14>RECOMMENDED</bcp14> that, when possible, servers respect the
incremental parameter (<xref target="incremental" format="default"/>).</t>
      <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
the order in which clients make requests. Doing so ensures that clients can use
request ordering to influence response order.</t>
      <t>Incremental responses of the same urgency <bcp14>SHOULD</bcp14> be served by sharing bandwidth
among them. Payload The message content of incremental responses are is used in as parts, or chunks, as
they
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
portion of the resource is needed to be useful in improving performance varies.
Some resource types place critical elements early; others can use information
progressively. This scheme provides no explicit mandate about how a server
should use size, type type, or any other input to decide how to prioritize.</t>
      <t>There can be scenarios where a server will need to schedule multiple incremental
and non-incremental responses at the same urgency level. Strictly abiding by the
scheduling guidance based on urgency and request generation order might lead
to suboptimal results at the client, as early non-incremental responses might
prevent the serving of incremental responses issued later. The following are
examples of such challenges.</t> challenges:</t>
      <ol spacing="normal" type="1"><li>At the same urgency level, a non-incremental request for a large resource
followed by an incremental request for a small resource.</li>
        <li>At the same urgency level, an incremental request of indeterminate length
followed by a non-incremental large resource.</li>
      </ol>
      <t>It is <bcp14>RECOMMENDED</bcp14> that servers avoid such starvation where possible. The method
to do
for doing so is an implementation decision. For example, a server might
pre-emptively
preemptively send responses of a particular incremental type based on other
information such as content size.</t>
      <t>Optimal scheduling of server push is difficult, especially when pushed resources
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
the request that triggered the push, the count of active concurrent responses,
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
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>
      <t>Priority signals are a factor for server push scheduling. The concept of
parameter value defaults applies slightly differently because there is no
explicit client-signalled 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"/>.
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
can signal the intended priority to the client by including the Priority field
in a PUSH_PROMISE or HEADERS frame.</t>
      <section anchor="intermediaries-with-multiple-backend-connections" numbered="true" toc="default">
        <name>Intermediaries with Multiple Backend Connections</name>
        <t>An intermediary serving an HTTP connection might split requests over multiple
backend connections. When it applies prioritization rules strictly, low priority low-priority
requests cannot make progress while requests with higher priorities are in
flight. This blocking can propagate to backend connections, which the peer might
interpret as a connection stall. Endpoints often implement protections against
stalls, such as abruptly closing connections after a certain time period. To
reduce the possibility of this occurring, intermediaries can avoid strictly
following prioritization and instead allocate small amounts of bandwidth for all
the requests that they are forwarding, so that every request can make some
progress over time.</t>
        <t>Similarly, servers <bcp14>SHOULD</bcp14> allocate some amount of bandwidths to streams acting
as tunnels.</t>
      </section>
    </section>
    <section anchor="connect-scheduling" numbered="true" toc="default">
      <name>Scheduling and the CONNECT Method</name>
      <t>When a request stream carries the a CONNECT method, request, the scheduling guidance in
this document applies to the frames on the stream.  A client that issues multiple
CONNECT requests can set the incremental parameter to <tt>true</tt>. Servers that
implement the recommendations for handling of the incremental parameter in
<xref (<xref target="server-scheduling" format="default"/> format="default"/>) are likely to schedule these fairly, avoiding preventing one
CONNECT stream from blocking others.</t>
    </section>
    <section anchor="retransmission-scheduling" numbered="true" toc="default">
      <name>Retransmission Scheduling</name>
      <t>Transport protocols such as TCP and QUIC provide reliability by detecting packet
losses and retransmitting lost information. In addition to the considerations in
<xref target="server-scheduling" format="default"/>, scheduling of retransmission data could compete with new
data. The remainder of this section discusses considerations when using QUIC.</t>
      <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
application indicate otherwise". When an HTTP/3 application uses the priority
scheme defined in this document and the QUIC transport implementation supports
application indicated
application-indicated stream priority, a transport that considers the relative
priority of streams when scheduling both new data and retransmission data might
better match the expectations of the application. However, there are no
requirements on how a transport chooses to schedule based on this information
because the decision depends on several factors and trade-offs. It could
prioritize new data for a higher urgency higher-urgency stream over retransmission data for a
lower priority
lower-priority stream, or it could prioritize retransmission data over new data
irrespective of urgencies.</t>
      <t><xref section="6.2.4" sectionFormat="of" target="QUIC-RECOVERY" format="default"/> also highlights consideration of considerations regarding
application priorities when sending probe packets after Probe Timeout timer
expiration. A QUIC implementation supporting application-indicated priorities
might use the relative priority of streams when choosing probe data.</t>
    </section>
    <section anchor="fairness" numbered="true" toc="default">
      <name>Fairness</name>
      <t>Typically, HTTP implementations depend on the underlying transport to maintain
fairness between connections competing for bandwidth. When an intermediary receives HTTP requests are
forwarded through intermediaries, progress made by each connection originating
from end clients can become different over time, depending on client connections, it forwards them to backend connections. Depending on how intermediaries
coalesce the intermediary coalesces or split splits requests into across different backend connections. connections, different clients might experience dissimilar performance. This unfairness can dissimilarity might expand if the intermediary also uses priority signals are used. <xref when
forwarding requests. Sections&nbsp;<xref target="coalescing" format="default"/> format="counter"/> and <xref target="h1-backends" format="default"/> format="counter"/> discuss
mitigations against of this expansion of unfairness.</t>
      <t>Conversely, <xref target="intentional-unfairness" format="default"/> discusses how servers might intentionally
allocate unequal bandwidth to some connections connections, depending on the priority
signals.</t>
      <section anchor="coalescing" numbered="true" toc="default">
        <name>Coalescing Intermediaries</name>
        <t>When an intermediary coalesces HTTP requests coming from multiple clients into
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
those coming from others.</t>
        <t>It is sometimes beneficial for the server running behind an intermediary to obey
Priority header field values. As an example, a resource-constrained
server might defer the transmission of software update files that have the
background urgency. urgency level (7). However, in the worst case, the asymmetry
between the priority declared by multiple clients might cause all responses going to
one user agent to be delayed totally after those until all responses going to another.</t> another user agent have
 been sent.</t>
        <t>In order to mitigate this fairness problem, a server could use knowledge about
the intermediary as another input in its prioritization decisions. For
instance, if a server knows the intermediary is coalescing requests, then it
could avoid serving the responses in their entirety and instead distribute
bandwidth (for example, in a round-robin manner). This can work if the
constrained resource is network capacity between the intermediary and the user
agent, as the intermediary buffers responses and forwards the chunks based on
the prioritization scheme it implements.</t>
        <t>A server can determine if a request came from an intermediary through
configuration,
configuration or by consulting can check to see if that the request contains one of the following
header fields:</t>
        <ul spacing="normal">
          <li>Forwarded <xref target="FORWARDED" format="default"/>, X-Forwarded-For</li>
          <li>Via (see <xref section="7.6.3" sectionFormat="of" target="HTTP" format="default"/>)</li>
        </ul>
      </section>
      <section anchor="h1-backends" numbered="true" toc="default">
        <name>HTTP/1.x Back Ends</name>
        <t>It is common for CDN Content Delivery Network (CDN) infrastructure to support different HTTP versions on the
front end and back end. For instance, the client-facing edge might support
HTTP/2 and HTTP/3 while communication to back end backend servers is done using
HTTP/1.1. Unlike with connection coalescing, the CDN will "de-mux" "demux" requests into
discrete connections to the back end. HTTP/1.1 and older do not support response Response multiplexing in a single connection, connection is not supported by HTTP/1.1 (or older), so there is not a fairness problem.
However, back end backend servers <bcp14>MAY</bcp14> still use client headers for request scheduling.
Back end
Backend servers <bcp14>SHOULD</bcp14> only schedule based on client priority information where
that information can be scoped to individual end clients. Authentication and
other session information might provide this linkability.</t>
      </section>
      <section anchor="intentional-unfairness" numbered="true" toc="default">
        <name>Intentional Introduction of Unfairness</name>
        <t>It is sometimes beneficial to deprioritize the transmission of one connection
over others, knowing that doing so introduces a certain amount of unfairness
between the connections and therefore between the requests served on those
connections.</t>
        <t>For example, a server might use a scavenging congestion controller on
connections that only convey background priority responses such as software
update images. Doing so improves responsiveness of other connections at the cost
of delaying the delivery of updates.</t>
      </section>
    </section>
    <section anchor="header-field-rationale" numbered="true" toc="default">
      <name>Why use Use an End-to-End Header Field?</name>
      <t>In contrast to the prioritization scheme of HTTP/2 that HTTP/2, which uses a hop-by-hop frame,
the Priority header field is defined as end-to-end.</t> "end-to-end".</t>
      <t>The way that a client processes a response is a property associated with the
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
header field affect the prioritization between the responses that share a
connection is a hop-by-hop issue.</t>
      <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
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
end-to-end rather than hop-by-hop.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t><xref target="frame" format="default"/> describes considerations for server buffering of PRIORITY_UPDATE
frames.</t>
      <t><xref target="server-scheduling" format="default"/> presents examples where servers that prioritize responses
in a certain way might be starved of the ability to transmit payload.</t> responses.</t>
      <t>The security considerations from <xref target="STRUCTURED-FIELDS" format="default"/> apply to the processing of
priority parameters defined in <xref target="parameters" format="default"/>.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This specification registers the following entry in the Hypertext "Hypertext Transfer
Protocol (HTTP) Field Name Registry established by Registry" defined in <xref target="HTTP" target="HTTP2" format="default"/>:</t>
      <dl>
      <dl spacing="compact">
        <dt>
Field name: Name:  </dt>
        <dd>
          <t>Priority</t>
        </dd>
        <dt>
Status:  </dt>
        <dd>
          <t>permanent</t>
        </dd>
        <dt>
Specification document(s):
Reference:  </dt>
        <dd>
          <t>This document</t>
        </dd>
      </dl>
      <t>This specification registers the following entry in the HTTP/2 Settings "HTTP/2 Settings" registry
established by
defined in <xref target="RFC7540" target="HTTP2" format="default"/>:</t>
      <dl>
      <dl spacing="compact">
        <dt>
Name:
Code:  </dt>
        <dd>
          <t>SETTINGS_NO_RFC7540_PRIORITIES</t>
          <t>0x9</t>
        </dd>
        <dt>
Code:
Name:  </dt>
        <dd>
          <t>0x9</t>
          <t>SETTINGS_NO_RFC7540_PRIORITIES</t>
        </dd>
        <dt>
Initial value: Value:  </dt>
        <dd>
          <t>0</t>
        </dd>
        <dt>
Specification:
Reference:  </dt>
        <dd>
          <t>This document</t>
        </dd>
      </dl>
      <t>This specification registers the following entry in the HTTP/2 "HTTP/2 Frame Type Type"
registry established by defined in <xref target="RFC7540" target="HTTP2" format="default"/>:</t>
      <dl>
      <dl spacing="compact">
        <dt>
Frame Type:
Code:  </dt>
        <dd>
          <t>PRIORITY_UPDATE</t>
          <t>0x10</t>
        </dd>
        <dt>
Code:
Frame Type:  </dt>
        <dd>
          <t>0x10</t>
          <t>PRIORITY_UPDATE</t>
        </dd>
        <dt>
Specification:
Reference:  </dt>
        <dd>
          <t>This document</t>
        </dd>
      </dl>
      <t>This specification registers the following entries entry in the HTTP/3 "HTTP/3 Frame Type Types"
registry established by <xref target="HTTP3" format="default"/>:</t>
      <dl>
      <dl spacing="compact">
        <dt>
Value:  </dt>
        <dd>
          <t>0xF0700-0xF0701</t>
        </dd>
        <dt>
Frame Type:  </dt>
        <dd>
          <t>PRIORITY_UPDATE</t>
        </dd>
        <dt>
Code:
Status:  </dt>
        <dd>
          <t>0xF0700 and 0xF0701</t>
          <t>permanent</t>
        </dd>
        <dt>
Specification:
Reference:  </dt>
        <dd>
          <t>This document</t>
        </dd>
        <dt>
Change Controller:  </dt>
        <dd>
          <t>IETF</t>
        </dd>
        <dt>
Contact:  </dt>
        <dd>
          <t>ietf-http-wg@w3.org</t>
        </dd>
      </dl>
      <t>Upon publication, please create
      <t>IANA has created the HTTP Priority Parameters "Hypertext Transfer Protocol (HTTP) Priority" registry at
<eref target="https://iana.org/assignments/http-priority">https://iana.org/assignments/http-priority</eref> target="https://www.iana.org/assignments/http-priority" brackets="angle"/> and populate has populated it with the entries in
<xref target="iana-parameter-table" format="default"/>; see <xref target="register" format="default"/> for its associated procedures.</t>
      <table anchor="iana-parameter-table" align="center">
        <name>Initial Priority Parameters</name>
        <thead>
          <tr>
            <th align="left">Name</th>
            <th align="center">Description</th>
            <th align="left">Specification</th> align="left">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">u</td>
            <td align="center">The urgency of an HTTP response.</td>
            <td align="left">
              <xref target="urgency" format="default"/></td>
          </tr>
          <tr>
            <td align="left">i</td>
            <td align="center">Whether an HTTP response can be processed incrementally.</td>
            <td align="left">
              <xref target="incremental" format="default"/></td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
<displayreference target="HTTP2" to="HTTP/2"/>
<displayreference target="HTTP3" to="HTTP/3"/>
<displayreference target="I-D.lassey-priority-setting" to="PRIORITY-SETTING"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<!-- [HTTP] draft-ietf-httpbis-semantics (RFC 9110) AUTH48 -->
        <reference anchor="HTTP"> anchor='HTTP' target="https://www.rfc-editor.org/info/rfc9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="Roy T. Fielding">
              <organization>Adobe</organization> initials='R' surname='Fielding' fullname='Roy Fielding' role="editor">
              <organization />
            </author>
            <author fullname="Mark Nottingham">
              <organization>Fastly</organization> initials='M' surname='Nottingham' fullname='Mark Nottingham' role="editor">
              <organization />
            </author>
            <author fullname="Julian Reschke">
              <organization>greenbytes GmbH</organization> initials='J' surname='Reschke' fullname='Julian Reschke' role="editor">
              <organization />
            </author>
            <date day="12" month="September" year="2021"/>
            <abstract>
              <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   level protocol for distributed, collaborative, hypertext information
   systems.  This document describes the overall architecture of HTTP,
   establishes common terminology, and defines aspects of the protocol
   that are shared by all versions.  In this definition are core
   protocol elements, extensibility mechanisms, and the "http" and
   "https" Uniform Resource Identifier (URI) schemes.

   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> year='2022' month='June'/>
          </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 fullname="Cory Benfield">
              <organization>Apple Inc.</organization>
            </author>
            <date day="18" month="November" year="2021"/>
            <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> name="STD" value="97"/>
          <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-06"/> name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
<!-- [HTTP/2] draft-ietf-httpbis-http2bis (RFC 9113) AUTH48 -->
        <reference anchor="HTTP3"> anchor='HTTP2' target="https://www.rfc-editor.org/info/rfc9113">
          <front>
            <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
            <title>HTTP/2</title>
            <author fullname="Mike Bishop">
              <organization>Akamai</organization> initials='M' surname='Thomson' fullname='Martin Thomson' role="editor">
              <organization />
            </author>
            <date day="2" month="February" year="2021"/>
            <abstract>
              <t>   The QUIC transport protocol has several features that are desirable
   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</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/> initials='C' surname='Benfield' fullname='Cory Benfield' role="editor">
              <organization />
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract> year='2022' month='June'/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/> value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/> value="10.17487/RFC9113"/>
        </reference>
<!-- [HTTP/3] draft-ietf-quic-http (RFC 9114) AUTH48 -->
        <reference anchor="RFC8174"> anchor='HTTP3' target="https://www.rfc-editor.org/info/rfc9114">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <title>HTTP/3</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/> initials='M' surname='Bishop' fullname='Mike Bishop' role="editor">
              <organization />
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract> year='2022' month='June'/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/> value="9114"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/> value="10.17487/RFC9114"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <reference anchor="STRUCTURED-FIELDS"> anchor="STRUCTURED-FIELDS" target="https://www.rfc-editor.org/info/rfc8941">
          <front>
            <title>Structured Field Values for HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="P-H. Kamp" initials="P-H." surname="Kamp">
              <organization/>
            </author>
            <date month="February" year="2021"/>
            <abstract>
              <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8941"/>
          <seriesInfo name="DOI" value="10.17487/RFC8941"/>
        </reference>
        <reference anchor="QUIC"> anchor="QUIC" target="https://www.rfc-editor.org/info/rfc9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <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 communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <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 constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="MARX" target="https://www.doi.org/10.5220/0008191701300143">
          <front>
            <title>Of the Utmost Importance: Resource Prioritization in HTTP/3 over QUIC</title>
            <author initials="R." surname="Marx" fullname="Robin Marx">
              <organization/>
            </author>
            <author initials="T.D." surname="Decker" initials="T." surname="De Decker" fullname="Tom De Decker">
              <organization/>
            </author>
            <author initials="P." surname="Quax" fullname="Peter Quax">
              <organization/>
            </author>
            <author initials="W." surname="Lamotte" fullname="Wim Lamotte">
              <organization/>
            </author>
            <date year="2019" month="September"/>
          </front>
          <seriesInfo name="DOI" value="10.5220/0008191701300143"/>
          <seriesInfo name="SCITEPRESS" value="Proceedings
          <refcontent>SCITEPRESS Proceedings of the 15th International Conference on Web Information Systems and Technologies (pages 130-143)"/>
        </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="Thomson">
              <organization/>
            </author>
            <date month="May" year="2015"/>
            <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 perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited 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"/> 130-143)</refcontent>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml"/>
<!-- [CACHING] draft-ietf-httpbis-cache (RFC 9111) AUTH48 -->
        <reference anchor="CACHING"> anchor='CACHING' target="https://www.rfc-editor.org/info/rfc9111">
          <front>
            <title>HTTP Caching</title>
            <author fullname="Roy T. Fielding">
              <organization>Adobe</organization> initials='R' surname='Fielding' fullname='Roy Fielding' role="editor">
              <organization />
            </author>
            <author fullname="Mark Nottingham">
              <organization>Fastly</organization> initials='M' surname='Nottingham' fullname='Mark Nottingham' role="editor">
              <organization />
            </author>
            <author fullname="Julian Reschke">
              <organization>greenbytes GmbH</organization> initials='J' surname='Reschke' fullname='Julian Reschke' role="editor">
              <organization />
            </author>
            <date day="12" month="September" year="2021"/>
            <abstract>
              <t>   The Hypertext Transfer Protocol (HTTP) is a stateless application-
   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> year='2022' month='June'/>
          </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>
            <date month="February" year="2017"/>
            <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 registered.  This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations.</t>
            </abstract>
          </front> name="STD" value="98"/>
          <seriesInfo name="RFC" value="8081"/> value="9111"/>
          <seriesInfo name="DOI" value="10.17487/RFC8081"/> value="10.17487/RFC9111"/>
         </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8081.xml"/>
        <reference anchor="QUIC-RECOVERY"> anchor="QUIC-RECOVERY" target="https://www.rfc-editor.org/info/rfc9002">
          <front>
            <title>QUIC Loss Detection and Congestion Control</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="I. Swett" initials="I." role="editor" surname="Swett">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document describes loss detection and congestion control mechanisms for QUIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9002"/>
          <seriesInfo name="DOI" value="10.17487/RFC9002"/>
        </reference>
        <reference anchor="FORWARDED"> anchor="FORWARDED" target="https://www.rfc-editor.org/info/rfc7239">
          <front>
            <title>Forwarded HTTP Extension</title>
            <author fullname="A. Petersson" initials="A." surname="Petersson">
              <organization/>
            </author>
            <author fullname="M. Nilsson" initials="M." surname="Nilsson">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, 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 possible 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 administrator to anonymize the origin of a request.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7239"/>
          <seriesInfo name="DOI" value="10.17487/RFC7239"/>
        </reference>
        <reference anchor="I-D.lassey-priority-setting">
          <front>
            <title>Declaring Support for HTTP/2 Priorities</title>
            <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 shown 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>
<!-- draft-lassey-priority-setting (Expired) -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.lassey-priority-setting.xml"/>
    </references>
    </references>
    <section anchor="acknowledgements" numbered="true" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Roy Fielding
      <t><contact fullname="Roy Fielding"/>
presented the idea of using a header field for representing
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.pdf</eref>. target="https://www.ietf.org/proceedings/83/slides/slides-83-httpbis-5.pdf" brackets="angle"/>.
In <eref target="https://github.com/pmeenan/http3-prioritization-proposal">https://github.com/pmeenan/http3-prioritization-proposal</eref>, Patrick Meenan target="https://github.com/pmeenan/http3-prioritization-proposal" brackets="angle"/>, <contact fullname="Patrick Meenan"/>
advocated for representing the priorities using a tuple of urgency and
concurrency. The ability to disable HTTP/2 prioritization is inspired by
<xref target="I-D.lassey-priority-setting" format="default"/>, authored by Brad Lassey <contact fullname="Brad Lassey"/> and Lucas Pardue, <contact fullname="Lucas Pardue"/>, with
modifications based on feedback that was not incorporated into an update to that
document.</t>
      <t>The motivation for defining an alternative to HTTP/2 priorities is drawn from
discussion within the broad HTTP community. Special thanks to Roberto Peon,
Martin Thomson <contact fullname="Roberto Peon"/>,
<contact fullname="Martin Thomson"/>, and Netflix for text that was incorporated explicitly in this
document.</t>
      <t>In addition to the people above, this document owes a lot to the extensive
discussion in the HTTP priority design team, consisting of Alan Frindell,
Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku, Lucas Pardue, Matthew Cox,
Mike Bishop, Roberto Peon, Robin Marx, Roy Fielding.</t>
      <t>Yang Chi contributed <contact fullname="Alan Frindell"/>,
<contact fullname="Andrew Galloni"/>, <contact fullname="Craig Taylor"/>, <contact fullname="Ian Swett"/>, <contact fullname="Matthew Cox"/>,
<contact fullname="Mike Bishop"/>, <contact fullname="Roberto Peon"/>, <contact fullname="Robin Marx"/>, <contact fullname="Roy Fielding"/>, and the section on retransmission scheduling.</t>
    </section>
    <section anchor="change-log" numbered="true" toc="default">
      <name>Change Log</name>
      <t><em>RFC EDITOR: please remove this section before publication</em></t>
      <section anchor="since-draft-ietf-httpbis-priority-11" numbered="true" toc="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 population</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 authors
 of receiving SETTINGS_NO_RFC7540_PRIORITIES that changes
value (#1714, #1725)</li>
          <li>Clarify how intermediaries might use frames vs. headers (#1715, #1735)</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 on 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 extensions can
use it but must define how themselves (#1550, #1559)</li>
          <li>Describe scheduling considerations for document.</t>
      <t><contact fullname="Yang Chi"/> contributed 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, #1345)</li>
          <li>Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261, #1344)</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 (#1022, #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" toc="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" toc="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 deprecation (#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" toc="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" toc="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" toc="default">
        <name>Since draft-kazuho-httpbis-priority-00</name>
        <ul spacing="normal">
          <li>Expand urgency levels from 3 to 8.</li>
        </ul>
      </section> retransmission scheduling.</t>
    </section>
  </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>