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

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

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-compression-dictionary-19" number="9842" category="std" updates="" obsoletes="" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.0 --> version="3" xml:lang="en">

  <front>
    <title>Compression
    <title abbrev="Compression Dictionary Transport">Compression Dictionary Transport</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-compression-dictionary-19"/> name="RFC" value="9842"/>
    <author initials="P." surname="Meenan" fullname="Patrick Meenan" role="editor">
      <organization>Google LLC</organization>
      <address>
        <email>pmeenan@google.com</email>
      </address>
    </author>
    <author initials="Y." surname="Weiss" fullname="Yoav Weiss" role="editor">
      <organization>Shopify Inc</organization>
      <address>
        <email>yoav.weiss@shopify.com</email>
      </address>
    </author>
    <date year="2024" month="August" day="28"/> year="2025" month="August"/>

    <area>ART</area>
    <workgroup>HTTP</workgroup>

    <keyword>compression dictionary</keyword>
    <keyword>shared brotli</keyword>
    <keyword>zstandard dictionary</keyword>
    <keyword>delta compression</keyword>
    <abstract>
      <?line 77?>
<t>This document specifies a mechanism for dictionary-based compression in the
Hypertext Transfer Protocol (HTTP). By utilizing this technique, clients and
servers can reduce the size of transmitted data, leading to improved performance
and reduced bandwidth consumption. This document extends existing HTTP compression
methods and provides guidelines for the delivery and use of compression
dictionaries within the HTTP protocol.</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-compression-dictionary/"/>.
      </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/compression-dictionary"/>.</t>
    </note>

  </front>
  <middle>
    <?line 86?>
<section anchor="introduction">
      <name>Introduction</name>
      <t>This specification defines a mechanism for using designated HTTP <xref target="HTTP"/> target="RFC9110"/> responses
as an external dictionary for future HTTP responses for compression schemes
that support using external dictionaries (e.g., Brotli <xref target="RFC7932"/> and
Zstandard <xref target="RFC8878"/>).</t>
      <t>This document describes the HTTP headers used for negotiating dictionary usage
and registers content encoding content-encoding values for compressing with Brotli and Zstandard
using a negotiated dictionary.</t>
      <t>The negotiation of dictionary usage leverages HTTP's content negotiation
(see <xref section="12" sectionFormat="of" target="HTTP"/>) target="RFC9110"/>) and is usable with all versions of HTTP.</t>
      <section anchor="use-cases">
        <name>Use Cases</name>
        <t>Any HTTP response can be specified to be used for use as a compression dictionary for
future HTTP requests requests, which provides a lot of flexibility. There are two Two common
use cases that are seen frequently:</t> frequently are described below.</t>
        <section anchor="version-upgrade">
          <name>Version Upgrade</name>
          <t>Using a previous version of a resource as a dictionary for a newer version
enables delivery of a delta-compressed version of the changes, usually
resulting in significantly smaller responses than what can be achieved by
compression alone.</t>
          <t>For example:</t>
          <figure>
            <name>Version Upgrade Example</name>
            <artset>
              <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="432" width="424" viewBox="0 0 424 432" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                  <path d="M 8,48 L 8,176" fill="none" stroke="black"/>
                  <path d="M 8,256 L 8,416" fill="none" stroke="black"/>
                  <path d="M 416,48 L 416,176" fill="none" stroke="black"/>
                  <path d="M 416,256 L 416,416" fill="none" stroke="black"/>
                  <path d="M 16,80 L 408,80" fill="none" stroke="black"/>
                  <path d="M 16,160 L 408,160" fill="none" stroke="black"/>
                  <path d="M 16,320 L 408,320" fill="none" stroke="black"/>
                  <path d="M 16,400 L 408,400" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="416,320 404,314.4 404,325.6" fill="black" transform="rotate(0,408,320)"/>
                  <polygon class="arrowhead" points="416,80 404,74.4 404,85.6" fill="black" transform="rotate(0,408,80)"/>
                  <polygon class="arrowhead" points="24,400 12,394.4 12,405.6" fill="black" transform="rotate(180,16,400)"/>
                  <polygon class="arrowhead" points="24,160 12,154.4 12,165.6" fill="black" transform="rotate(180,16,160)"/>
                  <g class="text">
                    <text x="28" y="36">Client</text>
                    <text x="396" y="36">Server</text>
                    <text x="32" y="68">GET</text>
                    <text x="92" y="68">/app.v1.js</text>
                    <text x="64" y="116">200</text>
                    <text x="92" y="116">OK</text>
                    <text x="124" y="132">Use-As-Dictionary:</text>
                    <text x="264" y="132">match="/app*js"</text>
                    <text x="72" y="148">&lt;full</text>
                    <text x="136" y="148">app.v1.js</text>
                    <text x="212" y="148">resource</text>
                    <text x="256" y="148">-</text>
                    <text x="288" y="148">100KB</text>
                    <text x="360" y="148">compressed&gt;</text>
                    <text x="20" y="212">Some</text>
                    <text x="60" y="212">time</text>
                    <text x="104" y="212">later</text>
                    <text x="144" y="212">...</text>
                    <text x="28" y="244">Client</text>
                    <text x="396" y="244">Server</text>
                    <text x="32" y="276">GET</text>
                    <text x="92" y="276">/app.v2.js</text>
                    <text x="104" y="292">Available-Dictionary:</text>
                    <text x="272" y="292">:pZGm1A...2a2fFG4=:</text>
                    <text x="84" y="308">Accept-Encoding:</text>
                    <text x="176" y="308">gzip,</text>
                    <text x="216" y="308">br,</text>
                    <text x="256" y="308">zstd,</text>
                    <text x="300" y="308">dcb,</text>
                    <text x="336" y="308">dcz</text>
                    <text x="72" y="356">200</text>
                    <text x="100" y="356">OK</text>
                    <text x="128" y="372">Content-Encoding:</text>
                    <text x="216" y="372">dcb</text>
                    <text x="128" y="388">&lt;delta-compressed</text>
                    <text x="240" y="388">app.v2.js</text>
                    <text x="316" y="388">resource</text>
                    <text x="360" y="388">-</text>
                    <text x="388" y="388">1KB&gt;</text>
                  </g>
                </svg>
              </artwork>
              <artwork type="ascii-art"><![CDATA[
Client                                        Server
|                                                  |
| GET /app.v1.js                                   |
|------------------------------------------------->|
|                                                  |
|     200 OK                                       |
|     Use-As-Dictionary: match="/app*js"           |
|     <full app.v1.js resource - 100KB compressed> |
|<-------------------------------------------------|
|                                                  |

Some time later ...

Client                                        Server
|                                                  |
| GET /app.v2.js                                   |
| Available-Dictionary: :pZGm1A...2a2fFG4=:        |
| Accept-Encoding: gzip, br, zstd, dcb, dcz        |
|------------------------------------------------->|
|                                                  |
|      200 OK                                      |
|      Content-Encoding: dcb                       |
|      <delta-compressed app.v2.js resource - 1KB> |
|<-------------------------------------------------|
|                                                  |
]]></artwork>
            </artset>
          </figure>
        </section>
        <section anchor="common-content">
          <name>Common Content</name>
          <t>If several resources share common patterns in their responses responses, then it can be
useful to reference an external dictionary that contains those common patterns,
effectively compressing them out of the responses. Some examples of this are
common template HTML for similar pages across a site and common keys and values
in API calls.</t>
          <t>For example:</t>
          <figure>
            <name>Common Content Example</name>
            <artset>
              <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="544" width="440" viewBox="0 0 440 544" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                  <path d="M 8,48 L 8,288" fill="none" stroke="black"/>
                  <path d="M 8,368 L 8,528" fill="none" stroke="black"/>
                  <path d="M 432,48 L 432,288" fill="none" stroke="black"/>
                  <path d="M 432,368 L 432,528" fill="none" stroke="black"/>
                  <path d="M 16,80 L 424,80" fill="none" stroke="black"/>
                  <path d="M 16,160 L 424,160" fill="none" stroke="black"/>
                  <path d="M 16,208 L 424,208" fill="none" stroke="black"/>
                  <path d="M 16,272 L 424,272" fill="none" stroke="black"/>
                  <path d="M 16,432 L 424,432" fill="none" stroke="black"/>
                  <path d="M 16,512 L 424,512" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="432,432 420,426.4 420,437.6" fill="black" transform="rotate(0,424,432)"/>
                  <polygon class="arrowhead" points="432,208 420,202.4 420,213.6" fill="black" transform="rotate(0,424,208)"/>
                  <polygon class="arrowhead" points="432,80 420,74.4 420,85.6" fill="black" transform="rotate(0,424,80)"/>
                  <polygon class="arrowhead" points="24,512 12,506.4 12,517.6" fill="black" transform="rotate(180,16,512)"/>
                  <polygon class="arrowhead" points="24,272 12,266.4 12,277.6" fill="black" transform="rotate(180,16,272)"/>
                  <polygon class="arrowhead" points="24,160 12,154.4 12,165.6" fill="black" transform="rotate(180,16,160)"/>
                  <g class="text">
                    <text x="28" y="36">Client</text>
                    <text x="412" y="36">Server</text>
                    <text x="32" y="68">GET</text>
                    <text x="96" y="68">/index.html</text>
                    <text x="64" y="116">200</text>
                    <text x="92" y="116">OK</text>
                    <text x="72" y="132">Link:</text>
                    <text x="144" y="132">&lt;.../dict&gt;;</text>
                    <text x="308" y="132">rel="compression-dictionary"</text>
                    <text x="72" y="148">&lt;full</text>
                    <text x="140" y="148">index.html</text>
                    <text x="220" y="148">resource</text>
                    <text x="264" y="148">-</text>
                    <text x="296" y="148">100KB</text>
                    <text x="368" y="148">compressed&gt;</text>
                    <text x="32" y="196">GET</text>
                    <text x="72" y="196">/dict</text>
                    <text x="168" y="244">200</text>
                    <text x="196" y="244">OK</text>
                    <text x="228" y="260">Use-As-Dictionary:</text>
                    <text x="364" y="260">match="/*html"</text>
                    <text x="20" y="324">Some</text>
                    <text x="60" y="324">time</text>
                    <text x="104" y="324">later</text>
                    <text x="144" y="324">...</text>
                    <text x="28" y="356">Client</text>
                    <text x="412" y="356">Server</text>
                    <text x="32" y="388">GET</text>
                    <text x="96" y="388">/page2.html</text>
                    <text x="104" y="404">Available-Dictionary:</text>
                    <text x="272" y="404">:pZGm1A...2a2fFG4=:</text>
                    <text x="84" y="420">Accept-Encoding:</text>
                    <text x="176" y="420">gzip,</text>
                    <text x="216" y="420">br,</text>
                    <text x="256" y="420">zstd,</text>
                    <text x="300" y="420">dcb,</text>
                    <text x="336" y="420">dcz</text>
                    <text x="72" y="468">200</text>
                    <text x="100" y="468">OK</text>
                    <text x="128" y="484">Content-Encoding:</text>
                    <text x="216" y="484">dcb</text>
                    <text x="128" y="500">&lt;delta-compressed</text>
                    <text x="244" y="500">page2.html</text>
                    <text x="324" y="500">resource</text>
                    <text x="368" y="500">-</text>
                    <text x="400" y="500">10KB&gt;</text>
                  </g>
                </svg>
              </artwork>
              <artwork type="ascii-art"><![CDATA[
Client                                          Server
|                                                    |
| GET /index.html                                    |
|--------------------------------------------------->|
|                                                    |
|     200 OK                                         |
|     Link: <.../dict>; rel="compression-dictionary" |
|     <full index.html resource - 100KB compressed>  |
|<---------------------------------------------------|
|                                                    |
| GET /dict                                          |
|--------------------------------------------------->|
|                                                    |
|                  200 OK                            |
|                  Use-As-Dictionary: match="/*html" |
|<---------------------------------------------------|
|                                                    |

Some time later ...

Client                                          Server
|                                                    |
| GET /page2.html                                    |
| Available-Dictionary: :pZGm1A...2a2fFG4=:          |
| Accept-Encoding: gzip, br, zstd, dcb, dcz          |
|--------------------------------------------------->|
|                                                    |
|      200 OK                                        |
|      Content-Encoding: dcb                         |
|      <delta-compressed page2.html resource - 10KB> |
|<---------------------------------------------------|
|                                                    |
]]></artwork>
            </artset>
          </figure>
        </section>
      </section>
      <section anchor="notational-conventions">
        <name>Notational Conventions</name>
        <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
        <?line -18?> here.
        </t>
<t>This document uses the following terminology from Section 3 of <xref target="STRUCTURED-FIELDS"/>
target="RFC9651" sectionFormat="of" section="3"/> to specify
syntax and parsing: Dictionary, String, Inner List, Token, and Byte
Sequence.</t>
        <t>This document uses the line folding strategies described in <xref target="FOLDING"/>.</t> target="RFC8792"/>.</t>
        <t>This document also uses terminology from <xref target="HTTP"/> target="RFC9110"/> and <xref target="HTTP-CACHING"/>.</t> target="RFC9111"/>.</t>
      </section>
    </section>
    <section anchor="dictionary-negotiation">
      <name>Dictionary Negotiation</name>
      <section anchor="use-as-dictionary">
        <name>Use-As-Dictionary</name>
        <t>When responding to a an HTTP Request, a server can advertise that the response can
be used as a dictionary for future requests for URLs that match the rules
specified in the Use-As-Dictionary "Use-As-Dictionary" response header.</t>
        <t>The Use-As-Dictionary "Use-As-Dictionary" response header is a Structured Field
<xref target="STRUCTURED-FIELDS"/> target="RFC9651"/> Dictionary with values for "match", "match-dest", "id",
and "type".</t>
        <section anchor="match">
          <name>match</name>
          <name>"match"</name>
          <t>The "match" value of the Use-As-Dictionary "Use-As-Dictionary" response header is a String value that
provides the URL Pattern to use for request matching (see <xref target="URLPATTERN"/>).</t>
          <t>The URL Pattern used for matching does not support using regular expressions.</t>
          <t>The following algorithm is used to validate that a given String value is a
valid URL Pattern that does not use regular expressions and is for the same
Origin (<xref section="4.3.1" sectionFormat="of" target="HTTP"/>) target="RFC9110"/>) as the dictionary. It will return TRUE
for a valid match pattern and FALSE for an invalid pattern that <bcp14>MUST NOT</bcp14> be
used:</t>
used.</t>
          <ol spacing="normal" type="1"><li> type="1">
	    <li>
              <t>Let MATCH be the value of "match" for the given dictionary.</t>
            </li>
            <li>
              <t>Let URL be the URL of the dictionary request.</t>
            </li>
            <li>
              <t>Let PATTERN be a URL pattern created by running the steps to create a
URL pattern by setting input=MATCH, input=MATCH and baseURL=URL (see
<xref target="URLPATTERN" section="create" relative="#url-pattern-create"/>).</t>
            </li>
            <li>
              <t>If the result of running the "has regexp groups" steps for PATTERN returns
TRUE
TRUE, then return FALSE (see <xref target="URLPATTERN" section="has regexp groups" relative="#url-pattern-has-regexp-groups"/>).</t>
            </li>
            <li>
              <t>Return TRUE.</t>
            </li>
          </ol>
          <t>The "match" value is required and <bcp14>MUST</bcp14> be included in the
Use-As-Dictionary
"Use-As-Dictionary" response header for the dictionary to be considered valid.</t>
          <t>Operating at the HTTP-level, HTTP level, the specified match patterns will operate on the
percent-encoded version of the URL path (see <xref section="2" sectionFormat="of" target="URL"/>).</t> target="RFC3986"/>).</t>
          <t>For example example, the URL "http://www.example.com/düsseldorf" would be encoded as
"http://www.example.com/d%C3%BCsseldorf" and a relevant match pattern would be:</t>
          <sourcecode type="http-message"><![CDATA[
Use-As-Dictionary: match="/d%C3%BCsseldorf"
]]></sourcecode>
        </section>

<!-- [rfced] In an effort to make the text file reader-friendly and to keep
links to non-RFC references from degrading over time, we would like to
update six reference links that use the "relative" attribute to some more
meaningful text.

Please review the following instances and let us know if these changes are
acceptable.

a)
Current:
   (see Part RequestDestination of [FETCH])

Perhaps:
   (see "RequestDestination" in Section 5.4 of [FETCH])

b)
Current:
   (see Part has regexp groups of [URLPATTERN])

Perhaps:
   (see the last list in Section 1.4 of [URLPATTERN])

c)
Current:
   (see Part create of [URLPATTERN])

Perhaps:
   (see Section 1.4 of [URLPATTERN])

d)
Current:
   (see Part match of [URLPATTERN])

Perhaps:
   (see "Match" in Section 1.4 of [URLPATTERN])

e)
Current:
   (see Part CORS check of [FETCH])

Perhaps:
   (see Section 4.9 of [FETCH])
-->
        <section anchor="match-dest">
          <name>match-dest</name>
          <name>"match-dest"</name>
          <t>The "match-dest" value of the Use-As-Dictionary header is an Inner List of
String values that provides a list of Fetch request destinations for the
dictionary to match (see <xref target="FETCH" section="RequestDestination" relative="#requestdestination"/>).</t>
          <t>An empty list for "match-dest" <bcp14>MUST</bcp14> match all destinations.</t>
          <t>For clients that do not support request destinations, the client <bcp14>MUST</bcp14> treat it
as an empty list and match all destinations.</t>
          <t>The "match-dest" value is optional and defaults to an empty list.</t>
        </section>
        <section anchor="id">
          <name>id</name>
          <name>"id"</name>
          <t>The "id" value of the Use-As-Dictionary header is a String value that specifies
a server identifier for the dictionary. If an "id" value is present and has a
string length longer than zero zero, then it <bcp14>MUST</bcp14> be sent to the server in a
"Dictionary-ID" request header when the client sends an "Available-Dictionary"
request header for the same dictionary (see <xref target="available-dictionary"/>).</t>
          <t>The server identifier <bcp14>MUST</bcp14> be treated as an opaque string by the client.</t>
          <t>The server identifier <bcp14>MUST NOT</bcp14> be relied upon by the server to guarantee the
contents of the dictionary. The dictionary hash <bcp14>MUST</bcp14> be validated before use.</t>
          <t>The "id" value string length (after any decoding) supports up to 1024
characters.</t>
          <t>The "id" value is optional and defaults to the empty string.</t>
        </section>
        <section anchor="type">
          <name>type</name>
          <name>"type"</name>
          <t>The "type" value of the Use-As-Dictionary header is a Token value that
describes the file format of the supplied dictionary.</t>
          <t>"raw" is defined as a dictionary format which that represents an unformatted blob of
bytes suitable for any compression scheme to use.</t>
          <t>If a client receives a dictionary with a type that it does not understand, it
<bcp14>MUST NOT</bcp14> use the dictionary.</t>
          <t>The "type" value is optional and defaults to "raw".</t>
        </section>
        <section anchor="examples">
          <name>Examples</name>
          <section anchor="path-prefix">
            <name>Path Prefix</name>
<!-- [rfced] May we restructure and rephrase Sections 2.1.5.1 and 2.1.5.2 as
follows for readability?

Original (Section 2.1.5.1):
   A response that contained a response header:

   NOTE: '\' line wrapping per RFC 8792

   Use-As-Dictionary: \
     match="/product/*", match-dest=("document")

   Would specify matching any document request for a URL with a path
   prefix of /product/ on the same Origin (Section 4.3.1 of [HTTP]) as
   the original request.

Perhaps (Section 2.5.1.1):
   A response that contained a response header (as shown below) would
   specify matching any document request for a URL with a path prefix of
   /product/ on the same Origin (Section 4.3.1 of [HTTP]) as the original
   request:

   NOTE: '\' line wrapping per RFC 8792

   Use-As-Dictionary: \
     match="/product/*", match-dest=("document")

...
Original (Section 2.5.1.2):
   A response that contained a response header:

   Use-As-Dictionary: match="/app/*/main.js"

   Would match any path that starts with "/app/" and ends with
   "/main.js".

Perhaps (Section 2.5.1.2):
   A response that contained a response header (shown
   below) would match any path that starts with "/app/" and
   ends with "/main.js":

   Use-As-Dictionary: match="/app/*/main.js"
-->
            <t>A response that contained a response header:</t>
            <sourcecode type="http-message"><![CDATA[
NOTE: '\' line wrapping per RFC 8792

Use-As-Dictionary: \
  match="/product/*", match-dest=("document")
]]></sourcecode>
            <t>Would specify matching any document request for a URL with a path prefix of
/product/ on the same Origin (<xref section="4.3.1" sectionFormat="of" target="HTTP"/>) target="RFC9110"/>) as the original
request.</t>
          </section>
          <section anchor="versioned-directories">
            <name>Versioned Directories</name>
            <t>A response that contained a response header:</t>
            <sourcecode type="http-message"><![CDATA[
Use-As-Dictionary: match="/app/*/main.js"
]]></sourcecode>
            <t>Would match any path that starts with "/app/" and ends with "/main.js".</t>
          </section>
        </section>
      </section>
      <section anchor="available-dictionary">
        <name>Available-Dictionary</name>
        <t>When a an HTTP client makes a request for a resource for which it has an
appropriate dictionary, it can add a an "Available-Dictionary" request header
to the request to indicate to the server that it has a dictionary available to
use for compression.</t>
        <t>The "Available-Dictionary" request header is a Structured Field
<xref target="STRUCTURED-FIELDS"/> target="RFC9651"/> Byte Sequence containing the SHA-256 <xref target="SHA-256"/> target="RFC6234"/> hash of the
contents of a single available dictionary.</t>
        <t>The client <bcp14>MUST</bcp14> only send a single "Available-Dictionary" request header
with a single hash value for the best available match that it has available.</t>
        <t>For example:</t>
        <sourcecode type="http-message"><![CDATA[
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
]]></sourcecode>
        <section anchor="dictionary-freshness-requirement">
          <name>Dictionary freshness requirement</name> Freshness Requirement</name>
          <t>To be considered as a match, the dictionary resource <bcp14>MUST</bcp14> be either fresh
<xref target="HTTP-CACHING"/> target="RFC9111"/> or allowed to be served stale (see eg <xref target="RFC5861"/>).</t>
        </section>
        <section anchor="dictionary-url-matching">
          <name>Dictionary URL matching</name> Matching</name>
          <t>When a dictionary is stored as a result of a "Use-As-Dictionary" directive, it
includes a "match" string and an optional "match-dest" string that are used to
match an outgoing request from a client to the available dictionaries.</t>
          <t>To see if an outbound request matches a given dictionary, the following
algorithm will return TRUE for a successful match and FALSE for no-match:</t>
          <ol spacing="normal" type="1"><li>
              <t>If the current client supports request destinations and a "match-dest"
string was provided with the dictionary:
              </t>
              <ul spacing="normal">
                <li>
                  <t>Let DEST be the value of "match-dest" for the given dictionary.</t>
                </li>
                <li>
                  <t>Let REQUEST_DEST be the value of the destination for the current
 request.</t>
                </li>
                <li>
                  <t>If DEST is not an empty list and if REQUEST_DEST is not in the DEST list
 of destinations, return FALSE</t> FALSE.</t>
                </li>
              </ul>
            </li>
            <li>
              <t>Let BASEURL be the URL of the dictionary request.</t>
            </li>
            <li>
              <t>Let URL represent the URL of the outbound request being checked.</t>
            </li>
            <li>
              <t>If the Origin of BASEURL and the Origin of URL are not the same, return
FALSE (see <xref section="4.3.1" sectionFormat="of" target="HTTP"/>).</t> target="RFC9110"/>).</t>
            </li>
            <li>
              <t>Let MATCH be the value of "match" for the given dictionary.</t>
            </li>
            <li>
              <t>Let

<!--[rfced] Is "by running the steps to create a URL pattern" needed
in this sentence or may it be rephrased as follows for conciseness?

Original:
   6.  Let PATTERN be a URL pattern created by running the steps to
       create a URL pattern by setting input=MATCH, and baseURL=URL
       (see Part create of [URLPATTERN]).

Perhaps:
   6.  Let PATTERN be a URL pattern; the URL pattern is created by
       setting input=MATCH and baseURL=URL (see Part create of
       [URLPATTERN]).
-->

              <t>Let PATTERN be a URL pattern created by running the steps to create a
URL pattern by setting input=MATCH and baseURL=URL (see
<xref target="URLPATTERN" section="create" relative="#url-pattern-create"/>).</t>
            </li>
            <li>
              <t>Return the result of running the "match" steps on PATTERN with input=URL input=URL,
which will check for a match between the request URL and the supplied "match"
string (see <xref target="URLPATTERN" section="match" relative="#url-pattern-match"/>).</t>
            </li>
          </ol>
        </section>
        <section anchor="multiple-matching-dictionaries">
          <name>Multiple matching dictionaries</name> Matching Dictionaries</name>
          <t>When there are multiple dictionaries that match a given request URL, the client
<bcp14>MUST</bcp14> pick a single dictionary using the following rules:</t>
          <ol spacing="normal" type="1"><li>
              <t>For clients that support request destinations, a dictionary that specifies
and matches a "match-dest" takes precedence over a match that does not use a
destination.</t>
            </li>
            <li>
              <t>Given equivalent destination precedence, the dictionary with the longest
"match" takes precedence.</t>
            </li>
            <li>
              <t>Given equivalent destination and match length precedence, the most recently
fetched dictionary takes precedence.</t>
            </li>
          </ol>
        </section>
      </section>
      <section anchor="dictionary-id">
        <name>Dictionary-ID</name>

        <t>When a an HTTP client makes a request for a resource for which it has an
appropriate dictionary and the dictionary was stored with a server-provided
"id" in the Use-As-Dictionary response then response, the client <bcp14>MUST</bcp14> echo the stored
"id" in a "Dictionary-ID" request header.</t>
        <t>The "Dictionary-ID" request header is a Structured Field <xref target="STRUCTURED-FIELDS"/> target="RFC9651"/>
String of up to 1024 characters (after any decoding) and <bcp14>MUST</bcp14> be identical to
the server-provided "id".</t>
        <t>For example, given a an HTTP response that set a dictionary ID:</t>
        <sourcecode type="http-message"><![CDATA[
Use-As-Dictionary: match="/app/*/main.js", id="dictionary-12345"
]]></sourcecode>
        <t>A future request that matches the given dictionary will include both the hash
and the ID:</t>
        <sourcecode type="http-message"><![CDATA[
Available-Dictionary: :pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=:
Dictionary-ID: "dictionary-12345"
]]></sourcecode>
      </section>
    </section>
    <section anchor="the-compression-dictionary-link-relation-type">
      <name>The 'compression-dictionary' "compression-dictionary" Link Relation Type</name>
      <t>This specification defines the 'compression-dictionary' "compression-dictionary" link relation type
<xref target="WEB-LINKING"/> target="RFC8288"/> that provides a mechanism for a an HTTP response to provide a URL
for a compression dictionary that is related to, to but not directly used by the
current HTTP response.</t>
      <t>The 'compression-dictionary' "compression-dictionary" link relation type indicates that fetching and
caching the specified resource is likely to be beneficial for future requests.
The response to some of those future requests are likely to be able have the ability to use
the indicated resource as a compression dictionary.</t>
      <t>Clients can fetch the provided resource at a time that they determine would
      be appropriate.</t>

<!--[rfced] May we update this sentence for clarity? Should "caching
response header" be singular (option A) or plural (option B)?
Should "caching" contain quote marks for consistency or is it
correct as is?

Current:
   The response to the fetch for the compression dictionary needs to
   include a "Use-As-Dictionary" and caching response headers for it to
   be usable as a compression dictionary.

Perhaps A:
   The response to the fetch for the compression dictionary needs to
   include a "Use-As-Dictionary" response header and a caching response
   header for it to be usable as a compression dictionary.

Perhaps B:
   The response to the fetch for the compression dictionary needs to
   include a "Use-As-Dictionary" response header and caching response
   headers for it to be usable as a compression dictionary.
-->

      <t>The response to the fetch for the compression dictionary needs to include a
"Use-As-Dictionary" and caching response headers for it to be usable as a
compression dictionary. The link relation only provides the mechanism for
triggering the fetch of the dictionary.</t>
      <t>The following example shows a link to a resource at
https://example.org/dict.dat that is expected to produce a compression
dictionary:</t>
      <sourcecode type="http-message"><![CDATA[
Link: <https://example.org/dict.dat>; rel="compression-dictionary"
]]></sourcecode>
    </section>
    <section anchor="dictionary-compressed-brotli">
      <name>Dictionary-Compressed Brotli</name>
      <t>The "dcb" content encoding identifies a resource that is a
"Dictionary-Compressed Brotli" stream.</t>
      <t>A "Dictionary-Compressed Brotli" stream has a fixed header that is followed by
a Shared Brotli <xref target="SHARED-BROTLI"/> target="RFC9841"/> stream. The header consists of a fixed 4-byte
sequence and a 32-byte hash of the external dictionary that was used.  The
Shared Brotli stream is created using the referenced external dictionary and a
compression window that is at most 16 MB in size.</t>
      <t>The
<!-- [rfced] The following sentence points to a section (Section 9.2) that
doesn't exist. The term "prefix dictionary" is used in Section 8.2. May
we update as follows?

Original:
   The dictionary used for the "dcb" content encoding is a "raw"
   dictionary type as defined in <xref target="type"/> Section 2.1.4 and is treated as a
   prefix dictionary as defined in
section Section 9.2 of [SHARED-BROTLI].

Perhaps:
   The dictionary used for the Shared Brotli Compressed Data Format draft. "dcb" content encoding is a "raw"
   dictionary type as defined in Section 2.1.4 and is treated as a
   prefix dictionary as defined in Section 8.2 of [SHARED-BROTLI].
-->

      <t>The dictionary used for the "dcb" content encoding is a "raw" dictionary type
as defined in <xref target="type"/> and is treated as a prefix dictionary as defined in
<xref target="SHARED-BROTLI"/></t> target="RFC9841" sectionFormat="of" section="9.2"/>.</t>
      <t>The 36-byte fixed header is as follows:</t>
      <dl>
        <dt>Magic_Number:</dt>
        <dd>
          <t>4 fixed bytes: bytes -- 0xff, 0x44, 0x43, 0x42.</t>
        </dd>
        <dt>SHA_256_Hash:</dt>
        <dd>
          <t>32 bytes. SHA-256 hash digest of the dictionary <xref target="SHA-256"/>.</t> target="RFC6234"/>.</t>
        </dd>
      </dl>
      <t>Clients that announce support for dcb content encoding <bcp14>MUST</bcp14> be able to
decompress resources that were compressed with a window size of up to 16 MB.</t>
      <t>With Brotli compression, the full dictionary is available during compression
and decompression independent of the compression window, allowing for
delta-compression of resources larger than the compression window.</t>
    </section>
    <section anchor="dictionary-compressed-zstandard">
      <name>Dictionary-Compressed Zstandard</name>
      <t>The "dcz" content encoding identifies a resource that is a
"Dictionary-Compressed Zstandard" stream.</t>
      <t>A "Dictionary-Compressed Zstandard" stream is a binary stream that starts with
a 40-byte fixed header and is followed by a Zstandard <xref target="RFC8878"/> stream of the
response that has been compressed with an external dictionary.</t>
      <t>The dictionary used for the "dcz" content encoding is a "raw" dictionary type
as defined in <xref target="type"/> and is treated as a raw dictionary as per section 5 of
RFC 8878.</t> <xref target="RFC8878" sectionFormat="of" section="5"/>.</t>
      <t>The 40-byte header consists of a fixed 8-byte sequence followed by the
32-byte SHA-256 hash of the external dictionary that was used to compress the
resource:</t>
      <dl>
        <dt>Magic_Number:</dt>
        <dd>
          <t>8 fixed bytes: bytes -- 0x5e, 0x2a, 0x4d, 0x18, 0x20, 0x00, 0x00, 0x00.</t>
        </dd>
        <dt>SHA_256_Hash:</dt>
        <dd>
          <t>32 bytes. SHA-256 hash digest of the dictionary <xref target="SHA-256"/>.</t> target="RFC6234"/>.</t>
        </dd>
      </dl>
      <t>The 40-byte header is a Zstandard skippable frame (little-endian 0x184D2A5E)
with a 32-byte length (little-endian 0x00000020) that is compatible with
existing Zstandard decoders.</t>
      <t>Clients that announce support for dcz content encoding <bcp14>MUST</bcp14> be able to
decompress resources that were compressed with a window size of at least 8 MB
or 1.25 times the size of the dictionary, which ever whichever is greater, up to a
maximum of 128 MB.</t>
      <t>The window size used will be encoded in the content (currently, this can be
expressed in powers of two only) and it <bcp14>MUST</bcp14> be lower than this limit. An
implementation <bcp14>MAY</bcp14> treat a window size that exceeds the limit as a decoding
error.</t>
      <t>With Zstandard compression, the full dictionary is available during compression
and decompression until the size of the input exceeds the compression window.
Beyond that point point, the dictionary becomes unavailable. Using a compression
window that is 1.25 times the size of the dictionary allows for full delta
compression of resources that have grown by 25% between releases while still
giving the client control over the memory it will need to allocate for a given
response.</t>
    </section>
    <section anchor="negotiating-the-content-encoding">
      <name>Negotiating the Content Encoding</name>
<!-- [rfced] The phrase "available for use compressing the response..." is
difficult to parse. Please let us know if option A or B is preferred.

Original:
   When a compression dictionary is available for use compressing the
   response to a given request, the encoding to be used is negotiated
   through the regular mechanism for negotiating content encoding in
   HTTP through the "Accept-Encoding" request header and "Content-
   Encoding" response header.

Perhaps A (removing "for use"):
   When a compression dictionary is available to compress the
   response to a given request, the encoding to be used is negotiated
   through the regular mechanism for negotiating content encoding in
   HTTP through the "Accept-Encoding" request header and "Content-
   Encoding" response header.

Or

Perhaps B (adding "to" for readability):
   When a compression dictionary is available for use to compress the
   response to a given request, the encoding to be used is negotiated
   through the regular mechanism for negotiating content encoding</name> encoding in
   HTTP through the "Accept-Encoding" request header and "Content-
   Encoding" response header.
-->

      <t>When a compression dictionary is available for use compressing the response to
a given request, the encoding to be used is negotiated through the regular
mechanism for negotiating content encoding in HTTP through the "Accept-Encoding"
request header and "Content-Encoding" response header.</t>
      <t>The dictionary to use is negotiated separately and advertised in the
"Available-Dictionary" request header.</t>
      <section anchor="accept-encoding">
        <name>Accept-Encoding</name>
        <t>When a dictionary is available for use on a given request, request and the client
chooses to make dictionary-based content-encoding content encoding available, the client adds
the dictionary-aware content encodings that it supports to the
"Accept-Encoding" request header. e.g.:</t> For example:</t>
        <sourcecode type="http-message"><![CDATA[
Accept-Encoding: gzip, deflate, br, zstd, dcb, dcz
]]></sourcecode>
        <t>When a client does not have a stored dictionary that matches the request, request or
chooses not to use one for the request, the client <bcp14>MUST NOT</bcp14> send its
dictionary-aware content-encodings content encodings in the "Accept-Encoding" request header.</t>
      </section>
      <section anchor="content-encoding">
        <name>Content-Encoding</name>
        <t>If a server supports one of the dictionary encodings advertised by the client
and chooses to compress the content of the response using the dictionary that
the client has advertised advertised, then it sets the "Content-Encoding" response header
to the appropriate value for the algorithm selected. e.g.:</t> For example:</t>
        <sourcecode type="http-message"><![CDATA[
Content-Encoding: dcb
]]></sourcecode>
        <t>If the response is cacheable, it <bcp14>MUST</bcp14> include a "Vary" header to prevent caches from
serving dictionary-compressed resources to clients that don't support them or
serving the response compressed with the wrong dictionary:</t> dictionary. For example:</t>
        <sourcecode type="http-message"><![CDATA[
Vary: accept-encoding, available-dictionary
]]></sourcecode>
      </section>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="content-encoding-1">
        <name>Content Encoding</name> Encoding Registration</name>
        <t>IANA is asked to enter has added the following into entries to the "HTTP Content Coding
        Registry"
registry maintained at
&lt;<eref target="https://www.iana.org/assignments/http-parameters/http-parameters.xhtml"/>&gt;:</t>
        <ul spacing="normal">
          <li>
            <t>Name: dcb</t>
          </li>
          <li>
            <t>Description: "Dictionary-Compressed <eref
        target="https://www.iana.org/assignments/http-parameters/"
        brackets="angle"/>:</t>

        <dl spacing="compact" newline="false">
          <dt>Name:</dt><dd>dcb</dd>
          <dt>Description:</dt><dd>"Dictionary-Compressed Brotli" data format.</t>
          </li>
          <li>
            <t>Reference: This document</t>
          </li>
          <li>
            <t>Notes: format.</dd>
          <dt>Reference:</dt><dd>RFC 9842, <xref target="dictionary-compressed-brotli"/></t>
          </li>
        </ul>
        <t>IANA is asked to enter the following into the "HTTP Content Coding Registry"
registry maintained at
&lt;<eref target="https://www.iana.org/assignments/http-parameters/http-parameters.xhtml"/>&gt;:</t>
        <ul spacing="normal">
          <li>
            <t>Name: dcz</t>
          </li>
          <li>
            <t>Description: "Dictionary-Compressed target="dictionary-compressed-brotli"/></dd>
        </dl>

        <dl spacing="compact" newline="false">
          <dt>Name:</dt><dd>dcz</dd>
          <dt>Description:</dt><dd>"Dictionary-Compressed Zstandard" data format.</t>
          </li>
          <li>
            <t>Reference: This document</t>
          </li>
          <li>
            <t>Notes: format.</dd>
          <dt>Reference:</dt><dd>RFC 9842, <xref target="dictionary-compressed-zstandard"/></t>
          </li>
        </ul> target="dictionary-compressed-zstandard"/></dd>
        </dl>

      </section>
      <section anchor="header-field-registration">
        <name>Header Field Registration</name>
        <t>IANA is asked has added the following entries to update the
"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry maintained at
&lt;<eref target="https://www.iana.org/assignments/http-fields/http-fields.xhtml"/>&gt; according
to the table below:</t>
<eref brackets="angle" target="https://www.iana.org/assignments/http-fields/"/>:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Field Name</th>
              <th align="left">Status</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Use-As-Dictionary</td>
              <td align="left">permanent</td>
              <td align="left"> align="left">RFC 9842, <xref target="use-as-dictionary"/> of this document</td> target="use-as-dictionary"/></td>
            </tr>
            <tr>
              <td align="left">Available-Dictionary</td>
              <td align="left">permanent</td>
              <td align="left"> align="left">RFC 9842, <xref target="available-dictionary"/> of this document</td> target="available-dictionary"/></td>
            </tr>
            <tr>
              <td align="left">Dictionary-ID</td>
              <td align="left">permanent</td>
              <td align="left"> align="left">RFC 9842, <xref target="dictionary-id"/> of this document</td> target="dictionary-id"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="link-relation-registration">
        <name>Link Relation Registration</name>
        <t>IANA is asked has added the following entry to update the "Link Relation Types" registry
        maintained at
&lt;<eref target="https://www.iana.org/assignments/link-relations/link-relations.xhtml"/>&gt;:</t>
        <ul spacing="normal">
          <li>
            <t>Relation Name: compression-dictionary</t>
          </li>
          <li>
            <t>Description: Refers <eref
        target="https://www.iana.org/assignments/link-relations/"
        brackets="angle"/>:</t>

        <dl spacing="compact" newline="false">
          <dt>Relation Name:</dt><dd>compression-dictionary</dd>
          <dt>Description:</dt><dd>Refers to a compression dictionary used for content encoding.</t>
          </li>
          <li>
            <t>Reference: This document, encoding.</dd>
          <dt>Reference:</dt><dd>RFC 9842, <xref target="the-compression-dictionary-link-relation-type"/></t>
          </li>
        </ul> target="the-compression-dictionary-link-relation-type"/></dd>
        </dl>

      </section>
    </section>
    <section anchor="compatibility-considerations">
      <name>Compatibility Considerations</name>
      <t>It is not unusual for there devices to be devices on the network path that intercept,
inspect
inspect, and process HTTP requests (web proxies, firewalls, intrusion detection
systems, etc). etc.). To minimize the risk of these devices incorrectly processing
dictionary-compressed responses, compression dictionary transport <bcp14>MUST</bcp14> only be
used in secure contexts (HTTPS).</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security considerations for Brotli <xref target="RFC7932"/>, Shared Brotli
<xref target="SHARED-BROTLI"/> target="RFC9841"/>, and Zstandard <xref target="RFC8878"/> apply to the
dictionary-based versions of the respective algorithms.</t>
      <section anchor="changing-content">
        <name>Changing content</name> Content</name>
        <t>The dictionary must be treated with the same security precautions as
the content, content because a change to the dictionary can result in a
change to the decompressed content.</t>
        <t>The dictionary is validated using a an SHA-256 hash of the content to make sure
that the client and server are both using the same dictionary. The strength
of the SHA-256 hash algorithm isn't explicitly needed to counter attacks
since the dictionary is being served from the same origin as the content. That
said, if a weakness is discovered in SHA-256 and it is determined that the
dictionary negotiation should use a different hash algorithm, the
"Use-As-Dictionary" response header can be extended to specify a different
algorithm and the server would just ignore any "Available-Dictionary" requests
that do not use the updated hash.</t>
      </section>
      <section anchor="reading-content">
        <name>Reading content</name> Content</name>
        <t>The compression attacks in <xref section="2.6" sectionFormat="of" target="RFC7457"/> show that it's a bad idea
to compress data from mixed (e.g. (e.g., public and private) sources -- the sources. The data
sources include not only the compressed data but also the dictionaries. For
example, if you compress secret cookies are compressed using a public-data-only dictionary,
you still leak
information about the cookies.</t>
        <t>Not cookies is still leaked.</t>

<!-- [rfced] FYI: We rephrased the following sentence for clarity.

Original:
   Not only can the dictionary reveal information about the compressed
   data, but vice versa, data compressed with the dictionary can reveal
   the contents of the dictionary when an adversary can control parts of
   data to compress and see the compressed size.

Current:
   The dictionary can reveal information about the compressed data and
   vice versa. That is, data compressed with the dictionary can reveal
   contents of the dictionary when an adversary can control parts of
   the data to compress and see the compressed size.
-->
        <t>The dictionary can reveal information about the compressed
data and vice versa. That is, data compressed with the dictionary can reveal
contents of the dictionary when an adversary can control parts of
the data to compress and see the compressed size. On the other hand, if
the adversary can control the dictionary, the adversary can learn
information about the compressed data.</t>
      </section>
      <section anchor="security-mitigations">
        <name>Security Mitigations</name>
        <t>If any of the mitigations do not pass, the client <bcp14>MUST</bcp14> drop the response and
return an error.</t>
        <section anchor="cross-origin-protection">
          <name>Cross-origin protection</name>
          <name>Cross-Origin Protection</name>
          <t>To make sure that a dictionary can only impact content from the same origin
where the dictionary was served, the URL Pattern used for matching a dictionary
to requests (<xref target="match"/>) is guaranteed to be for the same origin that the
dictionary is served from.</t>
        </section>
        <section anchor="response-readability">
          <name>Response readability</name> Readability</name>
          <t>For clients, like web browsers, that provide additional protection against the
readability of the payload of a response and against user tracking, additional
protections <bcp14>MUST</bcp14> be taken to make sure that the use of dictionary-based
compression does not reveal information that would not otherwise be available.</t>
          <t>In these cases, dictionary compression <bcp14>MUST</bcp14> only be used when both the
	  dictionary and the compressed response are fully readable by the client.</t>
          <t>In

<!--[rfced] Please clarify the phrasing in this "either" sentence. Is
the intended meaning that the dictionary and compressed response
are same-origin or the response is cross-origin?

Original:
   In browser terms, that means that both are either same-origin to the context
   they are being fetched from or that the response is cross-origin and passes
   the CORS check (see Part CORS check of [FETCH]).

Perhaps:
   In browser terms, that means either the dictionary and compressed
   response are same-origin to the context they are being fetched from or
   the response is cross-origin and passes the Cross-Origin Resource
   Sharing (CORS) check (see Part CORS check of [FETCH]).
-->

          <t>In browser terms, that means that both are either same-origin to the context
they are being fetched from or that the response is cross-origin and passes
the Cross-Origin Resource Sharing (CORS) check (see <xref target="FETCH" section="CORS check" relative="#cors-check"/>).</t>
        </section>
        <section anchor="server-responsibility">
          <name>Server Responsibility</name>
          <t>As with any usage of compressed content in a secure context, a potential
timing attack exists if the attacker can control any part of the dictionary, dictionary
or if it can read the dictionary and control any part of the content being
compressed,
compressed while performing multiple requests that vary the dictionary or
injected content. Under such an attack, the changing size or processing time
of the response reveals information about the content, which might be
sufficient to read the supposedly secure response.</t>
          <t>In general, a server can mitigate such attacks by preventing variations per
request, as in preventing active use of multiple dictionaries for the same
content, disabling compression when any portion of the content comes from
uncontrolled sources, and securing access and control over the dictionary
content in the same way as the response content. In addition, the following
requirements on a server are intended to disable dictionary-aware compression
when the client provides CORS request header fields that indicate a
cross-origin request context.</t>
          <t>The following algorithm will return FALSE for cross-origin requests where
precautions such as not using dictionary-based compression should be
considered:</t>
          <ol spacing="normal" type="1"><li>
              <t>If there is no "Sec-Fetch-Site" request header then header, return TRUE.</t>
            </li>
            <li>
              <t>if
              <t>If the value of the "Sec-Fetch-Site" request header is "same-origin" then "same-origin",
return TRUE.</t>
            </li>
            <li>
              <t>If there is no "Sec-Fetch-Mode" request header then header, return TRUE.</t>
            </li>
            <li>
              <t>If the value of the "Sec-Fetch-Mode" request header is "navigate" or
"same-origin" then
"same-origin", return TRUE.</t>
            </li>
            <li>
              <t>If the value of the "Sec-Fetch-Mode" request header is "cors":
              </t>
              <ul spacing="normal">
                <li>
                  <t>If the response does not include an "Access-Control-Allow-Origin" response header then header, return FALSE.</t>
                </li>
                <li>
                  <t>If the request does not include an "Origin" request header then header, return FALSE.</t>
                </li>
                <li>
                  <t>If the value of the "Access-Control-Allow-Origin" response header is "*" then "*", return TRUE.</t>
                </li>
                <li>
                  <t>If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header then header, return TRUE.</t>
                </li>
              </ul>
            </li>
            <li>
              <t>return
              <t>Return FALSE.</t>
            </li>
          </ol>
        </section>
      </section>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>Since dictionaries are advertised in future requests using the hash of the
content of the dictionary, it is possible to abuse the dictionary to turn it
into a tracking cookie.</t>
      <t>To mitigate any additional tracking concerns, clients <bcp14>MUST</bcp14> treat dictionaries
in the same way that they treat cookies <xref target="RFC6265"/>.
<!-- [rfced] May we rephrase the following sentence to improve readability?

Original:
   This includes partitioning the storage as cookies are partitioned as well
   as clearing the dictionaries whenever cookies are cleared.

Perhaps:
   This includes partitioning the storage (just as cookies are
   partitioned), as well as clearing the dictionaries whenever cookies are
   cleared.
-->
This includes partitioning
the storage as cookies are partitioned as well as clearing the dictionaries
whenever cookies are cleared.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC8792" to="FOLDING"/>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC9111" to="HTTP-CACHING"/>
    <displayreference target="RFC6234" to="SHA-256"/>
    <displayreference target="RFC9841" to="SHARED-BROTLI"/>
    <displayreference target="RFC9651" to="STRUCTURED-FIELDS"/>
    <displayreference target="RFC3986" to="URL"/>
    <displayreference target="RFC8288" to="WEB-LINKING"/>

<!-- [rfced] We note that both symbolic citation tags and numeric
citation tags are used for normative RFCs throughout the
document. May we make this convention consistent by including a
symbolic tag for RFC 8878 (perhaps "[ZSTD]")?
-->

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="FETCH" target="https://fetch.spec.whatwg.org/">
          <front>
            <title>Fetch - Living Standard</title>
            <author>
              <organization>WHATWG</organization>
            </author>
            <date/>
          </front>
          <refcontent>WHATWG Living Standard</refcontent>
          <annotation>Commit snapshot: <eref brackets="angle" target="https://fetch.spec.whatwg.org/commit-snapshots/5a9680638ebfc2b3b7f4efb2bef0b579a2663951/"/></annotation>
        </reference>
        <reference anchor="FOLDING">
          <front>
            <title>Handling Long Lines in Content of Internet-Drafts and RFCs</title>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="E. Auerswald" initials="E." surname="Auerswald"/>
            <author fullname="A. Farrel" initials="A." surname="Farrel"/>
            <author fullname="Q. Wu" initials="Q." surname="Wu"/>
            <date month="June" year="2020"/>
            <abstract>
              <t>This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8792"/>
          <seriesInfo name="DOI" value="10.17487/RFC8792"/>
        </reference>
        <reference anchor="HTTP">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="HTTP-CACHING">
          <front>
            <title>HTTP Caching</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t>
              <t>This document obsoletes

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8792.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9111.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8878.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>

<!-- [RFCYYY1]
draft-vandevenne-shared-brotli-format-15 companion doc RFC 7234.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="98"/>
          <seriesInfo name="RFC" value="9111"/>
          <seriesInfo name="DOI" value="10.17487/RFC9111"/>
        </reference>
        <reference anchor="RFC8878">
          <front>
            <title>Zstandard Compression and the 'application/zstd' Media Type</title>
            <author fullname="Y. Collet" initials="Y." surname="Collet"/>
            <author fullname="M. Kucherawy" initials="M." role="editor" surname="Kucherawy"/>
            <date month="February" year="2021"/>
            <abstract>
              <t>Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME.</t>
              <t>Despite use of the word "standard" 9841,
in AUTH48 as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.</t>
              <t>This document replaces and obsoletes RFC 8478.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8878"/>
          <seriesInfo name="DOI" value="10.17487/RFC8878"/>
        </reference>
        <reference anchor="SHA-256">
          <front>
            <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="T. Hansen" initials="T." surname="Hansen"/>
            <date month="May" year="2011"/>
            <abstract>
              <t>Federal Information Processing Standard, FIPS</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6234"/>
          <seriesInfo name="DOI" value="10.17487/RFC6234"/>
        </reference> 08/27/25.
 -->
<reference anchor="SHARED-BROTLI" target="https://datatracker.ietf.org/doc/draft-vandevenne-shared-brotli-format/"> anchor="RFC9841" target="https://www.rfc-editor.org/info/rfc9841">
  <front>
      <title>Shared Brotli Compressed Data Format</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="September"/>
          </front>
        </reference>
        <reference anchor="STRUCTURED-FIELDS" target="https://datatracker.ietf.org/doc/draft-ietf-httpbis-sfbis/">
          <front>
            <title>Structured Field Values for HTTP</title>
            <author>
              <organization/>
      <author initials="J." surname="Alakuijala" fullname="Jyrki Alakuijala">
         <organization>Google, Inc.</organization>
      </author>
            <date year="2024" month="May"/>
          </front>
        </reference>
        <reference anchor="URL">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
      <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/> surname="Duong" fullname="Thai Duong">
         <organization>Google, Inc.</organization>
      </author>
      <author fullname="R. Fielding" initials="R." surname="Fielding"/> initials="E." surname="Kliuchnikov" fullname="Evgenii Kliuchnikov">
         <organization>Google, Inc.</organization>
      </author>
      <author initials="Z." surname="Szabadka" fullname="Zoltan Szabadka">
         <organization>Google, Inc.</organization>
      </author>
      <author fullname="L. Masinter" initials="L." surname="Masinter"/> surname="Vandevenne" fullname="Lode Vandevenne">
         <organization>Google, Inc.</organization>
      </author>
    <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract> month='August' year='2025'/>
  </front>
  <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/> value="9841"/>
  <seriesInfo name="DOI" value="10.17487/RFC3986"/> value="10.17487/RFC9841"/>
</reference>

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

        <reference anchor="URLPATTERN" target="https://urlpattern.spec.whatwg.org/">
          <front>
            <title>URL Pattern - Living Standard</title>
            <author>
              <organization>WHATWG</organization>
            </author>
            <date/>
          </front>
          <refcontent>WHATWG Living Standard</refcontent>
          <annotation>Commit snapshot: <eref brackets="angle" target="https://urlpattern.spec.whatwg.org/commit-snapshots/696b4029d52e5854044bac6b72cdb198cb962ed0/"/></annotation>
        </reference>
        <reference anchor="WEB-LINKING">
          <front>
            <title>Web Linking</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="October" year="2017"/>
            <abstract>
              <t>This specification defines a model for the relationships between resources on the Web ("links") and

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

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5861.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6265.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7457.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7932.xml"/>
      </references>
    </references>

<!-- [rfced] Terminology

a) Throughout the type of those relationships ("link relation types").</t>
              <t>It also defines text, the serialisation of such links in HTTP headers with the Link header field.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8288"/>
          <seriesInfo name="DOI" value="10.17487/RFC8288"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs following term appears to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are be used to signify the requirements in the specification. These words are often capitalized. This document defines
inconsistently. Please review these words as occurrences and let us
know if/how they should may be interpreted in IETF documents. This document specifies an Internet Best Current Practices for made consistent.

  URL Pattern vs. URL pattern

b) We note the Internet Community, and requests discussion and suggestions following forms. Are these terms different or are any
updates needed for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity consistency (i.e., should any of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may these forms be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words
updated as '"Use-As-Dictionary" response header')?

  "Use-As-Dictionary" response header (3 instances)
  Use-As-Dictionary header (4 instances)
  Use-As-Dictionary response (1 instance)
-->

<!-- [rfced] FYI - We have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC5861">
          <front>
            <title>HTTP Cache-Control Extensions added an expansion for Stale Content</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="May" year="2010"/>
            <abstract>
              <t>This document defines two independent HTTP Cache-Control extensions that allow control over the following
abbreviation upon first use per Section 3.6 of stale responses by caches. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5861"/>
          <seriesInfo name="DOI" value="10.17487/RFC5861"/>
        </reference>
        <reference anchor="RFC6265">
          <front>
            <title>HTTP State Management Mechanism</title>
            <author fullname="A. Barth" initials="A." surname="Barth"/>
            <date month="April" year="2011"/>
            <abstract>
              <t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6265"/>
          <seriesInfo name="DOI" value="10.17487/RFC6265"/>
        </reference>
        <reference anchor="RFC7457">
          <front>
            <title>Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)</title>
            <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
            <author fullname="R. Holz" initials="R." surname="Holz"/>
            <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/>
            <date month="February" year="2015"/>
            <abstract>
              <t>Over 7322 ("RFC
Style Guide"). Please review each expansion in the last few years, there have been several serious attacks on Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with to
ensure correctness.

  Cross-Origin Resource Sharing (CORS)
-->

<!-- [rfced] Please review the goal "Inclusive Language" portion of motivating generic and protocol-specific recommendations on the usage
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of TLS and Datagram TLS (DTLS).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7457"/>
          <seriesInfo name="DOI" value="10.17487/RFC7457"/>
        </reference>
        <reference anchor="RFC7932">
          <front>
            <title>Brotli Compressed Data Format</title>
            <author fullname="J. Alakuijala" initials="J." surname="Alakuijala"/>
            <author fullname="Z. Szabadka" initials="Z." surname="Szabadka"/>
            <date month="July" year="2016"/>
            <abstract>
              <t>This specification defines a lossless compressed data format this
nature typically result in more precise language, which is
helpful for readers.

Note that compresses data using our script did not flag any words in particular, but this should
still be reviewed as a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7932"/>
          <seriesInfo name="DOI" value="10.17487/RFC7932"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9U9aXMbN5bf8SuwdE3FTpGUJR9RuHFmZEm2tZGPleS4MplU
CuwGyY6a3dw+RMuK57fsD9lPu39s3wGgge6mLB+ZqXFVFLHZAB4e3n1Ao9FI
VEmV6oncz5erQpdlkmfyIIkq+L8qLuVZobJylReViPMoU0t4My7UrBolupqN
FlW1miblKGoGj2I3eLT9rYhUped5cTmRZRULEeVZqbOyLieyKmotLibynlCF
VhO5d3Imynq6TGia6nIFSx0dnj0R67w4nxd5vZrIZ2dnr8S5voRH8UTIkfQW
ls3C+E25gGljOS3yKk3wwbuyUlmsirj1YqzTSvkTCXGhs1rD/NJfVkqG6Q2A
k2Rz+RS/g6eLHJGCmCgnW1v4//V8nBfzLfhuqZJ0Ih2qRuv5X9b38Ev4ThXR
ohmXJmVVjvnLrT34KrnQ5darepom0ZY/AU5b6FXeDJ0n1aKejmEHZnX630i/
rQDTsJ9yK1VTnZZb/ackePwI8F7rEb06kRteFaquFnmBqBnBf1ImGZzkq7F8
rnWmMnrERPJKVUUSnftfFDnSmY6TKi/oAWxVZck7hbNP5NM8n6daHh/v05ea
cbda0gR/mdO3uMlw7Z/G8o0G0L2lf8rVhffwA8ueLvJVMruUR1nkr3sJk4zX
OMlfSn6D1hZZXixh5AWRx5PDs/1nExpmuOiJrqIFENVxcoE0cmpIjl6JgRUm
cqbSUvMQVcx11ZzjDMeOy5WOxuuFqhoqAlpxaJd292YnQI/P9s7ePEVoXh4f
HL14OpEnT/Z3v/l2Bx4h4dLnb7e375rPo/29/Wf2PXi+Dc9xxO43uxMpb8m/
lg3Qp8/2RjsPHtKrD3fu3edHJ4cHo8cnL8+Oj4K9nzLHPSaOc/IEnhwoYLAn
hDgPETu78lSvKr2c6kLu3N3Z6UUKvAuUpKJzXYyRDQgnIIq2WApdAKga2DXT
I2b4ETP8aEbLIfZOz05e75+9RqCfHB0eH5yGQIMYiqoaAX+S6DSWP6q01qWE
8ZbtLcDb8rm6REjvfwqkgbwsZ/ATgXt9ckzIvfft7kP++Grv7Ozw5EUAJDxG
hqp0kX0ibdVFuuIJPoPA3hw+Hh0fvfjBEdnO7q4QSTbzeQKeP9h9uE2kBCCm
evRmkcDPE32h0gTh5Jce7jx8QC/t5/l5okt++s39B9/Q07PjU7lXVYBO+823
93boG6YvIUajkVTTElFeCXG2SEoJ2K6XOqsk7jGZwaxSyaWOFsDv5ZLO1NNO
U4XE6WuQJJPVQotnIOeLCuQna78Z0OcrWDSP8lTeRqK4M5aPL2VdJWnyDo+i
wsUrWCdL/qvWQxmlCUABi2exKHVxoYtSRioDuR3XkcY1ZJm80zKfgRaEFZYJ
HE2Mh6iGMtUqpklzmQBo+QV8A/AQkrNIC5jUTATaDT6sk7haSFSs9XKFexvL
EBmkCOIS/g86BmfGLQQKb6nh9GOCV+KKSQyYm9fwvzTJDDMg0PgZNnNJL9Yl
bcCfxyEXMb8GtcII5QVXBoVjPrplEsepFuIWSN6qyGE/Felegt2cX0QyGpad
ERjts6xL3A3AmswzhQi8usKV3r8H/IDNApZGKRTuilBQZCr1jp9mmNXI+gyf
G0Pf+GRRRgu9hLkqYBpZ1is0h8zi3Ylx67f1eD4eWkl4dWXIFwBDinAClr9B
wfv+/Z1xm4ZhX1GRTGE6h8IFkAbSUo2Ei1BmYFtViaJT9bZWl2puCWUOh070
BzYVUUMW5URfF42gc5uFx3hsFnKcoVEHvGPlFtW+JUXg6wYgQBsQRxsmIG6g
H/ilpA191YDlDRS3S60BN6eaBsvtHZyKT/YOwZQgCtQUrAWCVqWpRB5DW8e+
CvDcuiVfA43uK6QDsZddhudMHDnVTlbEyHHwmZCLZLPBuESMiZBwgOnBepPr
RQLK3zGQkmleITyzFFhvCsKiukTe1DAQVJWs1jkusYQd1wROSWcNNIbfAg4y
OaO5syq9nOB+bskfeZvy9WpeAC0I8docCgB6keR1aRGB6yrca14XIHJoPy3i
x5Ncg2wzIwTYWYDSsuFymoLMY2fgA2q8BZAwkSHhPIeAtxoO4lLAa3VKFAnc
j6xJjIx7kOUS3oAVG1aD7Wb2IBQYvRql3fRS+KhXaZ5pOE+wIIDf1HIFKlGI
v//971Kp8mIu9knayhv+OyV5LH6/6fvNv99h0NPDM7mlVqvxxfb4t/Jmg0Yf
++/73z8VPPy3c/eufPnDRw4CRhntlaPG8ZuA7wLm6KMB7vbr38pBz6DvZjVw
XoMNR20juX337g+PZUM13+Og7z4aE5+ICHEKPhkYT/AjBTlVyPEY6OefQyc7
N6YTuXcBrgfyYHAOk9Vfny6392ALO2pn9uTp/UeTYFAUgRU9OjRifSLn75LV
EPzeIXq88VDG0RR/vPMG/YMp8qNI0g3aZ83g7Qx28qFB33XEVXMIPnn+8Pgf
S5EgrcTVhO35R4OWFJeHLNUG71nI75NSsAgQ4mgG2gD1Zur2UHJ8w+gPaWz7
0liwSShiQZEklZGyqGqAbVHXFRosWzAH9CYLiXQRKmgFrjZ8ysvOgkOhZzPU
0xca5LtvR8CyS5nXldUTDqCxJO40krzk70Gjw3aEmR2cwhUyLujX58ekq8pk
CaxRwLpoO6ioyEvUaGVSabIIzMBzfclWLBs34JvIvVdHsPU0Lb+YBvkc2eBJ
hwQ817fjRbVMbzjso2n1U/n2E3VJM+w4yc4n8jsQWVtITt//O5x++mjQH1Qa
tPSJh5drFcqn8e8ncrB3bgj5Rw37J5xb8O/Dh9g77BqT4Gs8ncE//AC+hFr/
QsyLcmjnY5j345X7J6r3fxrJfZys+CQ1f62i944kkBufrOo/g1JDdR/q81Db
yxd5RV4vqF544QJeQDeWvWlQZxJTHaUcPH99ejYY8v/li5f0+8nhf74+Ojk8
wN9Pn+0dH7tfhHnj9NnL18cHzW/NyP2Xz58fvjjgwfBUBo/E4PneT/ANqtLB
y1dnRy9f7B0P2LrwYxTkxpLXnMDeCjiKipxnYYMXMY55vP/qf/97+z649P92
8mR/Z3v72/fvzYfd7W/uw4c12Ci8Wp6BHcEfwWq4FGC+adD7SUZefqRWSaVS
8DYVWkD5OpPoToMU+PpnxMwvoHWm0Wr7/vfmAW44eGhxFjwknHWfdAYzEnse
9SzjsBk8b2E6hHfvp+Czxbv38Ls/Y0BOjrZ3//y9aAeMamPtgcGUpvmajDBd
LJMsT/M5uPxFvpQ2pnIPzC5xddWJjcNZwHlySAT89Uuw/d5yWFAVJXFnI72G
GDyHZ0NxlGUgjY+TshrKs/zcnuXjS7DOTimCEelOfMuBS1sCmCkqhfHcSs8T
ikN4NHR1ZdIb7993ZgKCyM107f26iCDCwx9s/oMmuuXnOl94MSgTPQo1oBBv
0JhmU9YGaRVHgU44CjREq5Q0DBncKobfqqTUbEz7hjB+L4J4U39w0oWX8Nnr
k2MTIyJdzBPWYEaLJoxlgq4d6JuVOY5oQnYffA/DbaqTKNlAPd40FJvzoowD
AhnlDf0ygvOt8FMSg8AhSYMJ1sGYnSB6hyE0A3ku6090wW5B62KchC/hwnI0
2EuoVEQ7BKFBNa+N400ksknL2EBtOIWLx7qBcQ4rZXk7XFzoeY1ujH5rDeHS
TNfwrErneQGoW3KYk+OSNndi4oNyDg5XFu4S9y3ovXB7OMCBgzvtAcJGVW2g
v1RLLV4WyRxo6XYTib0/vjfeDoKxjE4vDCyPKjj4FHUwEEsmgUQOBUcbGTam
W+M/0rpP9o5PDzkiiSkYfm3lg28lufFfY3DetsfyWMM3e2f7z1D/IBiOPizB
2O0wtvxgtRmOiDKD8VdDWrHPCkQRboAhAwpX0hALZ1RoiohPYUydZcYDBnGm
VyUeIH8PJ+QPgpdLXZlY6aquHtF2WHhidgrefYTvIxmKkAyvJiUfCrhVNPUA
fSzKwj0a3KqLdGQWGZmvkXBhE0fOG69T8s19aAcLhWGSOVAGlz6UA7MDxKTd
O59sKfBoObpgzpoPsodnPGC7K4gNcMObI35zZN40WzhpKGvcJyCSko4tQVGF
mCTqIRMlSuvYCUjxYcHn8l5eTISsHcy2gTDBFYhcAY6XK11wIsbIedI1mO9I
h0wKTkAHLFAyu+Q0HKiXYYNPEVrFlK3pBt0NES1kK1VCmRL4ksWUF+5wowaY
EZ5sba3X67H5jipH4v/7H7Ci0zgvZgOwOes0xn3a5cGi2zjwT/v3/vR4vxmM
KMfMA2xdZVWL3+3MJvxChSpLEEKYr7rG4WwvQgZ2oyZIlfikwLrlIxRGJhsb
Bk0jX7IahevndfgtU+1htQaumWRkPjhJKkLSYWSYQ6PqkYA5jA1x0EwUcIdZ
yFuHWELsZVIvV9Ulw9WoWoMFon9eGW1oH0xDJDZfbXRFoLj6dscEzaN4+gqF
jEwqm29twEFy2Lj4hhODE8lXxinC8bGeKRBXJEiD2Y2tkMRmKjAlPstKaAoH
hDPj4MzBJ4NnffKABCqA5K0MM6NeJcMUYEeBp0TJK6U6mwPXpnk21wUnv97p
IncxWiuqaHSVs9wwYICyFINmI6Ojg4E7HLMp9Jv8oykp74/g9UUfkLaC4b72
92WeoVfl5mi+a+yhLrbsZiqjGpk08pWCRaVByPTSg/f6mVj/o2BBGVqDoLaj
zQDA17xWBQgdTfJOmNxy2dXrlIb1twintHAAW2MLBRXghEz0cYfCwiO9rWYY
kVLZJVArRzLuWB4CM26F0G1j6VC0UFixAvK8O+V1dI8bYMLnhQ3po8ls5iHr
+WPIn1w130YOSw5mSUpmMfCnnQ83ROgPEv+DQq0HOCUXavR6MzgJ58cLbdiD
yKE21UOE7TSfovCdgt8I7n0Nrv6UQSC8dksyjO0+phSJslRf6Ehj9WQIA1cK
EL6Y1RPfLM6wrgILHYYoxBy91aVuU04Psq87NsKNOSsT+Cnp0y200BfyVQE4
ewsyvDE+/LSLZl0amCV9uhOAPZzIr/72FXvT60KtVkidYEdg8ZSkesA+Dfs3
qlJlLbviMpytr8Era4Tyo9sD62kP7rDifUNa3EYJnNNDxG+dcitb2PZH08Oc
ANktK9o2HrZb1Zg+LH1u7nvk9KZKhTPVGbsmx4blh2AJRlWOlTmfjefr8+Rb
X28tYbLxb+XAR5RRf4Ad2jsrmkqhYCCc8Fi2nEhim6d2Lq5l6RPhJiBhQhCG
/pfqnIg/PAEXE8WPzInAAaSdMoyyFfmqwKIej9aHNm2oYkRPvxJp6SBhRJV9
ilVsWYyVXLql0CwTLtrSwukZGCCsa+4xv2XBm4DzUbGLIF5lKcP6RjCEi2Hh
RdIWLBIDJYMJyQyLmJstdCSHbzVRsBOVdDPyZkg2rGTGEDgsiqwKn+LLDRQ2
WORh3H7XmxYNaP7azMXF3aPDxz/snUTv3n2j356/+Kn863T3+J16Xvz4zX/c
c0mNxmD3dNEMDnSRwSrWX1tSuvus7WIRgdAWhl3/3FC11d0aMIOmDE4tfvbj
fb9I5AOMsrhSL6LEGHkRcERWjp7Ln00F6y93xh2IUYxZced4zwMHSxdB0liY
Gy8buKcjOgYwsuDcOWkd45/iQOvQGhuDAuNWwwT2snnBVY2ZeJGwIgcz8POc
Q09GGmBY1OlKw5I99ArSckxngWhJZmauaV5TVaEXJyOA2xGWYRiIFk1Qqx0c
MuKprKMIKAFLEyzsfmQoy0f0mCM/JogR1UWBm7DWrrW2eh0ydkt95FmjfK1K
69zFLHpDIuOq6K8p/nNwaGzabrjJnMjmmFMzCyYhYKJfe2fjQlsHuZvQ7JZ7
Gqyu4zkBHzRVwtZM1wGD8wvWNC+aSDE9wne5PWLW8vX86I6Ngz3eOz386OAZ
vuWsv/a4DnFNNR4O0Fd0rmM/dmVsAxhnocAtht/QU+AH3KU1KuxORBCn2mRf
jL9QiPFfPmJowm3XRA2dsELIAZV2y8RLDCYAItjoIP6nUzWcz+w+1dVa6yyw
HfyjdZ6HWc0y7/XRRgPZhn3yt++tnH+OZasrqy2DkmoyHd8Y79qU7y7t60Hp
t5ebsVLR244fOGEvY4VNUk6TB/XSFr9NaoAyPSwCO2Gb6+M1qlPX5UU6bITG
Uz1GmFVkSq7Qo4rJKMrRclO+PRGkFpTwliXqeUooQPUOrGPK2p1oaybuKHYn
hylWAqLJnmUbpA+v0kSgjK/eXnaZl+w1YpGyoDaswMXtWVMEdsHo6OCPtcQd
G/gYUs7YsOYgGdYjq8sERRY+nA2sWlEjoksdLYy1Tku4uYBAro1BWeP8+kBV
r1Uue61yG4oFodNEUWQTRemPvARxfwokRQqLHkXjgDg8UQQmNIOHhnVVq2WA
OUdXIT8dHXyWqwjGX/xo4LfN7ty7/8B4kHutNLAnYEyYpq15WMIaY1JOc8NH
6CQIS0b9EH8RQz84+InctK9bFIH7qr8k8CuqIATNkzIHn5kg18bOoOq6uVKc
q7BzUcDs6srrZcOah1aAP+wz6lBBbt9llW7ymxvaRdjrKhkCss6HclpXJDPZ
AUgv2W7ncKawZm2wqOGrj9ik87uNgiC5ZrwJESn+PUxMOckE4KbJOZb0sqM0
1RlgOkqAh3oqE8YEmo+eEgv1yLDDmuF2IQNqz2B64+wjFohBLeQeRNc05Lga
QG6yo33SxhyDN7Mg51IBoS3HQKHBVSOak1NYkuEJYYN3f3Okk2kRZ5r3n3ym
dVxyBISZUYk+L5Dql815tEJQnEdKKteaRJiijMIGXBBbhcRAUYag/CEgbwHy
dT7XhTM3aGvdkHm7TsFmFrEMi5NisCjVw3joFrYB1aYMqSkWJh3HqnKsod8C
CTJvSA4H6vC0vTRan+Ay9cbXrfWBGmQrlDzp5TUw25ZT0mxxNB10u+lctqL0
EWA3GGZuOjOTH6/VEnN58kZvmqjZLHkLXxmlahfjI+I+KtXqyqYoVtO/DaLP
rEx0Yyai0EtpQ1q8xv0RRuVFaaNj7E7f26HHfkBscycBGiwo58YSFxMhYGZb
AL71ixoD2DUqxL2TEygBPwB9xvm6wX7FJt72Q/n8MXelvbOMHVjcpoqnuuaY
yUSmfIe/PdQpqsl/UL0aPjSFZ9gd7CXBbPTb34M/WBj/RX473rFYvUlzPd/M
MRadQ+at3nvIhxUQDW7Ikgy6Fs/VPIl+fVFjV/5ETOR98zrlZCby7tvZbAg/
79+nn/fo5w7gElb8defBw1+fASXguHs7PGRs7xBgGokTNOZ7YgVeeNWT5xzX
yrK8RpqzLg71cUfT7ulYi88Gj9EeZER5jTNMi7rQXjeBtaAN4djmbGNwItkA
UG+8zliP2kyoC1sXwkigF1SrSbr6Ao3zRGHzeaxXOkM54norOzQ95Agmzoai
OyyCNgUizVZTvAXA5Jn75xtvFnpN46+Ve+++nNxzk99E9HVeZjacJoRp86id
VQHRd/9uD8G7SjcnJGGq3pZsO7MJ9IdOAMrfKQYsOkTU20v1YWnTi9wvIm1g
fEvUYFbQypgHmISjFCFs2oBpEXeNPtjlN5w+8PGJ2LKaIeD+m2oICn9ZzjW4
J8LqEVC7bQH1QKNQ2lEkmmL8ub1LT+7iz7vBzy8uuHqwR4fYEFh5nqxWnNcu
MNN5O02qClwu4PwEaAehvX+ws/fg8I7N8lhU2kqD9oC79G/n7h3Hdog7sP1s
g7xwNz80YJCrzEUINxG27/54YQsvploBjndB3ApYdXu884CMdTZa3Y0ZizBH
yREUfcGonhPlF0Mju5VYqrfJsiYu3t7ZZUmOp+SvXjNUIMG9mrfEykze923j
lqWU20hK209pqmh5wApYoOB6k3VOhre5sKAp7UEucSKZ/KxlUo3lXiYSNFox
BcZm+/O9n0xZVYgqQql+G7FzQdY+zGBqLkwAROiiyAurs5pT/wPUVg3iP+0c
EEV9Ayj7dM9jfZlTRAK97zwxSQEPnCkuBedfZ02+UtorD3y4WhbfjUiHVWlp
PFoqTgNtKjZqUyP3LzRWrq4pFr/z4E8uco0Vj3SFwxrvuwHlAfQk5nxXjxdd
Q3oq8pQjqeyMLXPEvKmbRqeRKBeAo6w5BxcoyuN0EKntF97lHz6lWg51IckN
7mlw1nyfindMzvZ2jq9oBbSZgpw88G7PwPRSc0lItSjyem56Fbj2XIQBFv8a
k64SzDgS4k8zaLXFdUrZqJ2g3Vo22NABEdZoIhbCDZR6pbA4NzW+hu3pcJXE
N0ramyqOEPANSeTuuWAcu41+G80z+YRokefUBJNT4LnvqiPGh0OtWyYo6FRx
XIqQVUZqzd3m4dmUrqTA5V45PiI6B9RGhsQrcnqDkP0Nj2DsYPisr/PRlNoY
Wuc9uKwE8auygfK2weHHUR1awa62qKT0YW4OoKmuCBjAj5pjzRjVcyRVKTah
b9Sgz+iYD2KLSKdNzqbqzZTTuBNAQLuyrlnTI9+g+pJku0dDvgHmTr7VzO85
6S3UCg81FKtoVq1MsWupK578w4xqq4r87EhY8NIUGJQghzGYtJnEeltOmYqO
WvsjPQ8kwkxi1biL58nBj8TpNgKT0z08JOZxVEm3f4WXM/ktq55uydtF2NlX
TU6vorsUCjdbAGLbsMIv10UeLNqHhR8puq+Y8ix5DGVfla+Njh3tvdhDMqTC
HE4t+pQpPcrENym2cM7qTGN/aCudCQqfj3VAAt7Oss/C6YSuruIyZf4Nr9N0
1XqV+O7nX27bkB92JYA1rCjmp0q8dggtqZKvwkTxvcQwb+fz+C02DN/5HhA0
ki/4elOghZE8oFJYqrmZfCgkh/e2mRrXMQw9seGqSXgRG66Qk5NyddVLD+bu
QozX/Evj790N8ef59V8Mhe6W1/fcXv2MOZMTjAYlpsOzg+N6ZVrsQH99+A5A
MyduusG1/Gxcz3DW4HeLY+TVvCD+MufO9dFTDfQAB7Ch6//3Db/fpPnd26LX
3o73OlZ1yb+3/7mj6+vd//IQdvPaBBUc3lJlyA2/A6mA/h6pMmhbcNfOuIJl
ufmehs6E/a0Q3TlxwiAh2uAwnNAj5iTeAN0fhEPkkjDdemM2kYNunrb8PB7A
LNLIpq7aHwNp41ZlsbPhxuKWJCLq5D6iTW6RC8y1rd3rBNMQQ3ALveki7GAb
I47VoULdN4Eauhuwo1mPKluoV2d0u561dtytC7G+SNB8MKXzGbiieXHulZnT
tQyo4YciyTDRW9lLPrHasnV/4e21nuJXbxO8z2+WFHqNFycNcZaiZjyB1Kdd
ifKyrPQSvtRVdGcsz8DpSLJkyREKME+S8txYi2UDJxhOeWFS3gYGFGcbrSO+
MWq4MbVuLyf3yqlNizCleXRUW7P7Le4Pt3tK5V54EUJd9CH9jApEzJdR8CWh
v3up5zBMznTTL+E9mkGIGQxazoJXQa+gcdj8Sy2tzccFw429WxrnAK9h9Pzn
jme7rKmm0oWGna1I/RZux1jkpGpTMstuoJlxiNEYRVVe5tJHmwz3VuFbbqlK
kBrWWi9q73jNtF0fHGi+6cCyl472xZEtg1qHt4TTFu6eBevNZrF1kdAHo3qY
xmtptbpxGhTj/hhqFTb35q/tt+ejja7frtIkSpCiMXRjg9c12WvK3GAM60Xt
TiLcJ9e4mjJ0qsx2QHFfi+1yscgC+ECSlirBRiX0/tZanVMJPQqjpIwwrMTU
b6E28UdqzzKVDrErf/D7U/27W8sFda7wacfJjKRe1cLAkE2lnpKGdiO1ueGT
byJmFNnuIW96r0rclX3yyXHb8G9IwqApsCUPy72uD7uY+3pNO6vt5GLlRW2Z
C+acE3PfcsA4wf2jfIicZ3Gd1uOHSIbmympMFi1c/LH6itJTKsbsmBK+L812
Lh70krIWdFOwXNE1/0YyJxcA4B1pPcPRiOkGBgr7zPqfuDESen6A1VwkTTVG
dDNKQHZY1o/pYuEq3YCMLvO6ARFEQaExTknXcjsGZBhHOPWI1vRi8AInoIAn
hvDPpbsSHLE3xUsAGUCaEbD+wsIdmcRkUDR+oVW6cQq7R8GXZeMmUbWQqITP
tPM+j7gjo3AVX7z1dIlyP629xaW0Y20Ed0W5xnxGoAQRE5Y5un0sVHYgX/KW
c9TjQIbUcjgjSPqXaec7um8CzotMfAhjhBsmeaf8nidVMnfmxoy4yqBh2Xxl
eWgFhlo35hUX+SqMSGCBmWkawGyoSUXQzZZ4b+PIiDa8ENwYE9hn4kS4SUS1
j4wIJgF7Kaqc5O8TmWLNBlJPtSzJWd7B9de3+IsLuirTmkhXV/QSNiBitsn2
G9uOoqCF2uyzT9YmpS/1DXZOLAJBRceKjcKgQX9IZXMSzbRpka9hBjqPpnYR
Y7cJrZF66JVqjjd4ViaV6ua2R71Sl2kO0speGe1O0Q0EDBWS/rgBx4jcKqJZ
pWwavhX2FVedIyX5y7fGt02dsJzNBm97ZAEnFEkdkPRDLlrj/UpTHfS0HWXG
9KRrtYcBMXlL+XajSQMiz9uqWf/IXLS9a6GSZYEppEtzdOiVtzrbASBzZnRL
lT24pVaZifnRojiT6WFDGrK8YgwoY8qitLhkc4YMCFuyTuyQFw22gzimz3t8
pVdZajbx9l+enJqmjI2XUzTvBA0VYNCXI37sOin4ikVLz4ml5L3SlkjY6+C9
vx/QWIRcZh4a79jBsMrx2wTFNvgZdNEKKmb+uwYl6jESjfTQ2BxWhnLvbdGT
vx9iphmGmk5XPL5OmjCLN05kQaZzEM1ehiYLaP5wA0Lr+kWcMKFjuuCIebAi
qOck+41LIp3l9xp71LFPjmpMeJtGGlvbn/OchedaURJUtKP2zFflRiVr7H3O
rC+T+QI3KMp6hjXAxuJ2mKIgNWyZWlkjLvR1WUqg+rnO8Ori1sVoRr1osyFj
Yk0vbQCd7+UoEqOBAI+iyXuRLea9qNgnMrKlvzEnuNrKbRFMZuDWVpbb6n0A
BnzLxLvr3pw2J6WR20SdGdJIUcGzfTY0BkDE+XNFnY0BGbnkr6dmPOp3GmSt
Lq0H4MX7DUEcZU4Qt9stvX7aklOHnguEMQFrhfP+e1N9XnK91SDiaolJJLQv
EaGYpY0+cB03OoK+9LFDDHNfcwWa3y3adIP2TYZ5d9D7wndgmbZse1IrD9P9
8y/G6ZkSfZjmY7/htODEcC4HYECN6PKf0WnCjXQBDirvUiy+pgrmMPIp6PP8
0ESw3MBTAwOaWbRn3gzd8zy+IXRH10PXOxFCl6kL4uMBCq0urF9sHVQzg0nT
7xqwhDMYXGIu45wqUMk+s9xoD4lr9NLA1nZQq/Y1ZuP2Uqarrm+lZtKNeO6b
M8TBR4GLGPm6D8NfagE/MR5Oc4PNusMONy9uyVfo3UbdoNspxUcCeY1CKKy0
aLeRNFGcnvsY+irFOAoCyqpMTMOJmnZveCFbC8GmlnyKFFvL17iw3BfvNBgq
Cs/u9l6GTeEd+S61612VFbSWtkV+05zCL1tf/Gfzd7N+MX/iyd0YgCYJrU/J
oQV37aGBpUo3GBHq3uPa0LXGv98Br6AH2UnkI2Qo+qm0zp+FXseebPpDTlPY
rvh/VryWtklyAAA= practice.
-->

  </back>

</rfc>