<?xml version='1.0' encoding='utf-8'?> version="1.0" 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.29 (Ruby 3.3.8) -->
<?rfc tocindent="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-cache-groups-07" number="9875" submissionType="IETF" updates="" obsoletes="" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 --> version="3" xml:lang="en">

  <front>
    <title>HTTP
    <title abbrev="HTTP Cache Groups">HTTP Cache Groups</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-groups-07"/> name="RFC" value="9875"/>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization/>
      <address>
        <postal>
          <postalLine>Prahran</postalLine>
          <postalLine>Australia</postalLine>
        </postal>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <date/>
    <area>Web and Internet Transport</area>
    <workgroup>HTTP</workgroup>
    <keyword>HTTP, Caching, Invalidation</keyword>
    <date month="September" year="2025"/>
    <area>WIT</area>
    <workgroup>httpbis</workgroup>
    <keyword>HTTP</keyword>
    <keyword>Caching</keyword>
    <keyword>Invalidation</keyword>

    <abstract>
      <?line 48?>
<t>This specification introduces a means of describing the relationships between stored responses in HTTP caches, "grouping" them by associating a stored response with one or more strings.</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-cache-groups/"/>.
      </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/cache-groups"/>.</t>
    </note>
  </front>
  <middle>
    <?line 52?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>HTTP caching <xref target="HTTP-CACHING"/> target="RFC9111"/> operates at the granularity of a single resource; the freshness of one stored response does not affect that of others. This granularity can make caching more efficient -- for example, when a page is composed of many assets that have different requirements for caching.</t>
      <t>However, there are also cases where the relationship between stored responses could be used to improve cache efficiency.</t>
      <t>For example, it is often necessary to invalidate a set of related resources. This might be because a state-changing request has side effects on other resources, or it might be purely for administrative convenience (e.g., "invalidate this part of the site"). Grouping responses together provides a dedicated way to express these relationships, instead of relying on things like URL structure.</t>

<!-- [rfced] Will readers understand what "it" refers to here?

Original:
   In addition to sharing invalidation events, the relationships
   indicated by grouping can also be used by caches to optimise their
   operation; for example, it could be used to inform the operation of
   cache eviction algorithms.

Perhaps:
   In addition to sharing invalidation events, the relationships
   indicated by grouping can also be used by caches to optimise their
   operation; for example, grouping could be used to inform the operation of
   cache eviction algorithms.

Or:
   In addition to sharing invalidation events, the relationships
   indicated by grouping can also be used by caches to optimise their
   operation (e.g., to inform the operation of
   cache eviction algorithms).
-->

      <t>In addition to sharing invalidation events, the relationships indicated by grouping can also be used by caches to optimise their operation; for example, it could be used to inform the operation of cache eviction algorithms.</t>
      <t><xref target="cache-groups"/> introduces a means of describing the relationships between stored responses in HTTP caches, by associating those responses with one or more groups that reflect those relationships. It also describes how caches can use that information to apply invalidation events to members of a group.</t>
      <t><xref target="cache-group-invalidation"/> introduces one new source of such events: a an HTTP response header field that allows a state-changing response to trigger a group invalidation.</t>
      <t>These mechanisms operate within a single cache, across the stored responses associated with a single origin server (see <xref target="identify"/>). They do not address the issues of synchronising state between multiple caches (e.g., in a hierarchy or mesh), nor do they facilitate association of stored responses from disparate origins.</t>
      <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 specification uses the following terminology from <xref target="STRUCTURED-FIELDS"/>: target="RFC9651"/>: List, String, and Parameter.</t>
      </section>
    </section>
    <section anchor="cache-groups">
      <name>The Cache-Groups Response Header Field</name>

<!-- [rfced] Section 3.3.1 of [STRUCTURED-FIELDS] is titled "Integers". Was
the text/reference below instead meant to point to Section 3.3.3, which is
titled "Strings"?

Also, may we update "Cache-Groups HTTP Response Header" in the first sentence
to "Cache-Groups response header field" for consistency with other instances
in the document?

Original:
   The Cache-Groups HTTP Response Header is a List of Strings (Sections
   3.1 and 3.3.1 of [STRUCTURED-FIELDS]).
   ...
   The Cache-Group-Invalidation response header field is a List of
   Strings (Sections 3.1 and 3.3.1 of [STRUCTURED-FIELDS]).

Perhaps:
   The Cache-Groups response header field is a List of Strings (Sections
   3.1 and 3.3.3 of [STRUCTURED-FIELDS]).
   ...
   The Cache-Group-Invalidation response header field is a List of
   Strings (Sections 3.1 and 3.3.3 of [STRUCTURED-FIELDS]).
-->
      <t>The Cache-Groups HTTP Response Header is a List of Strings (Sections <xref target="STRUCTURED-FIELDS" target="RFC9651" section="3.1" sectionFormat="bare"/> and <xref target="STRUCTURED-FIELDS" target="RFC9651" section="3.3.1" sectionFormat="bare"/> of <xref target="STRUCTURED-FIELDS"/>). target="RFC9651"/>). Each member of the list is a value that identifies a group that the response belongs to. These strings are opaque -- while they might have some meaning to the server that creates them, the cache does not have any insight into their structure or content (beyond uniquely identifying a group).</t>
      <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: max-age=3600
Cache-Groups: "scripts"
]]></sourcecode>
      <t>The ordering of members is not significant. Unrecognised Parameters are to be ignored.</t>
      <t>Implementations <bcp14>MUST</bcp14> support at least 32 groups in a field value, with up to at least 32 characters in each member. Note that generic limitations on HTTP field lengths may constrain the size of this field value in practice.</t>
      <section anchor="identify">
        <name>Identifying Grouped Responses</name>
        <t>Two responses stored in the same cache are considered to belong to the same group when all of the following conditions are met:</t>
        <ol spacing="normal" type="1"><li>

            <t>They both contain a Cache-Groups response header field that contains the same String (in any position in the List), when compared character-by-character (case sensitive).</t>
          </li>
          <li>
            <t>They both share the same URI origin (per <xref section="4.3.1" sectionFormat="of" target="HTTP"/>).</t> target="RFC9110"/>).</t>
          </li>
        </ol>
      </section>
      <section anchor="cache-behaviour">
        <name>Cache Behaviour</name>
        <section anchor="invalidation">
          <name>Invalidation</name>

          <t>A cache that invalidates a stored response <bcp14>MAY</bcp14> invalidate any stored responses that share groups (per <xref target="identify"/>) with that response. Note that further grouped invalidations are not triggered by a grouped invalidation; i.e., this mechanism does not "cascade."</t> "cascade".</t>
          <t>Cache extensions can explicitly strengthen the requirement above. For example, a targeted cache control header field <xref target="TARGETED"/> target="RFC9213"/> might specify that caches processing it are required to invalidate such responses.</t>
        </section>
      </section>
    </section>
    <section anchor="cache-group-invalidation">
      <name>The Cache-Group-Invalidation Response Header Field</name>
      <t>The Cache-Group-Invalidation response header field is a List of Strings (Sections <xref target="STRUCTURED-FIELDS" target="RFC9651" section="3.1" sectionFormat="bare"/> and <xref target="STRUCTURED-FIELDS" target="RFC9651" section="3.3.1" sectionFormat="bare"/> of <xref target="STRUCTURED-FIELDS"/>). target="RFC9651"/>). Each member of the list is a value that identifies a group that the response invalidates, per <xref target="invalidation"/>.</t>
      <t>For example, following a POST request that has side effects on two cache groups, the corresponding response could indicate that stored responses associated with either or both of those groups should be invalidated with:</t>
      <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Group-Invalidation: "eurovision-results", "australia"
]]></sourcecode>

      <t>The Cache-Group-Invalidation header field <bcp14>MUST</bcp14> be ignored on responses to requests that have a safe method (e.g., GET; see <xref section="9.2.1" sectionFormat="of" target="HTTP"/>).</t> target="RFC9110"/>).</t>
      <t>A cache that receives a Cache-Group-Invalidation header field on a response to an unsafe request <bcp14>MAY</bcp14> invalidate any stored responses that share groups (per <xref target="identify"/>) with any of the listed groups.</t>
      <t>Cache extensions can explicitly strengthen the requirement above. For example, a targeted cache control header field <xref target="TARGETED"/> target="RFC9213"/> might specify that caches processing it are required to respect the Cache-Group-Invalidation signal.</t>
      <t>The ordering of members is not significant. Unrecognised Parameters are to be ignored.</t>
      <t>Implementations <bcp14>MUST</bcp14> support at least 32 groups in a field value, with up to at least 32 characters in each member. Note that generic limitations on HTTP field lengths may constrain the size of this field value in practice.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
        <t>IANA should perform the following tasks:</t>
      <section anchor="http-field-names">
        <name>HTTP Field Names</name>
        <t>Enter has added the following into entries to the Hypertext "Hypertext Transfer Protocol (HTTP) Field Name Registry:</t>
        <ul spacing="normal">
          <li>
            <t>Field Name: Cache-Groups</t>
          </li>
          <li>
            <t>Status: permanent</t>
          </li>
          <li>
            <t>Reference: RFC nnnn</t>
          </li>
          <li>
            <t>Comments:</t>
          </li>
          <li>
            <t>Field Name: Cache-Group-Invalidation</t>
          </li>
          <li>
            <t>Status: permanent</t>
          </li>
          <li>
            <t>Reference: RFC nnnn</t>
          </li>
          <li>
            <t>Comments:</t>
          </li>
        </ul>
      </section> Registry":</t>
	<dl spacing="compact" newline="false">
          <dt>Field Name:</dt><dd>Cache-Groups</dd>
          <dt>Status:</dt><dd>permanent</dd>
          <dt>Reference:</dt><dd>RFC 9875</dd>
	</dl>
	<dl spacing="compact" newline="false">
          <dt>Field Name:</dt><dd>Cache-Group-Invalidation</dd>
          <dt>Status:</dt><dd>permanent</dd>
          <dt>Reference:</dt><dd>RFC 9875</dd>
        </dl>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This mechanism allows resources that share an origin to invalidate each other. Because of this,
origins that represent multiple parties (sometimes referred to as "shared hosting") might allow
one party to group its resources with those of others, others or to send signals which that have side effects upon them.</t>
      <t>Shared hosts that wish to mitigate these risks can control access to the header fields defined in this specification.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC9111" to="HTTP-CACHING"/>
    <displayreference target="RFC9651" to="STRUCTURED-FIELDS"/>
    <displayreference target="RFC9213" to="TARGETED"/>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <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
	<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.9651.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.9213.xml"/>
      </references>
    </references>

<section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>Thanks to <contact fullname="Stephen Ludin"/> for distributed, collaborative, hypertext information systems. This document describes his review and suggestions.</t>
    </section>
  </back>

<!-- [rfced] Are the overall architecture of HTTP, establishes common terminology, quotation marks needed around "grouping" and defines aspects "cascade" in
these sentences?

Original:
   This specification introduces a means of describing the protocol relationships
   between stored responses in HTTP caches, "grouping" them by
   associating a stored response with one or more strings.
   ...
   Note that further grouped invalidations are shared not triggered 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.
   grouped invalidation; i.e., this mechanism does not "cascade."

Perhaps:
   This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t>
              <t>This document obsoletes 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="STRUCTURED-FIELDS">
          <front>
            <title>Structured Field Values for HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="P-H. Kamp" surname="P-H. Kamp"/>
            <date month="September" year="2024"/>
            <abstract>
              <t>This document describes specification introduces a set means of data types and associated algorithms that are intended to make it easier and safer to define and handle describing the relationships
   between stored responses in HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use caches, grouping them by specifications of new HTTP fields.</t>
              <t>This document obsoletes RFC 8941.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9651"/>
          <seriesInfo name="DOI" value="10.17487/RFC9651"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words
   associating a stored response with one or more strings.
   ...
   Note that further grouped invalidations are used to signify the requirements not triggered by a
   grouped invalidation; i.e., this mechanism does not cascade.
-->

<!-- [rfced] We note inconsistencies 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 terms below throughout the Internet Community, and requests discussion
text. Please review all instances and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce let us know if any updates are
needed.

list vs. List
string vs. String
-->

<!-- [rfced] Please review the ambiguity by clarifying that only UPPERCASE usage "Inclusive Language" portion of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="TARGETED">
          <front>
            <title>Targeted HTTP Cache Control</title>
            <author fullname="S. Ludin" initials="S." surname="Ludin"/>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="Y. Wu" initials="Y." surname="Wu"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of caches. It also defines one such header field, the CDN-Cache-Control response header field, this nature typically
result in more precise language, which is targeted at content delivery network (CDN) caches.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9213"/>
          <seriesInfo name="DOI" value="10.17487/RFC9213"/>
        </reference>
      </references>
    </references>
    <?line 179?>

<section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Thanks to Stephen Ludin helpful for his review and suggestions.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1Z624jtxX+P0/BaoHCLjSy5d0mWW2a1PF6Y6Ne2/UFQRAE
ATVDSaxnhhOSY61iOM/SZ+mT9TuHHGlGdrZt0AIt0ABZS7wcnut3LkrTNPHa
F2oiTm5uLsWRzBZKfG1NU7tETqdW3U+S3GSVLHEkt3LmU638LF14X0+1SzO6
kM75Qrr/aZJLj4MPbw9vjh+TDF/mxq4mwvk8SXRtJ8LbxvmD/f3X+wfJnVot
jc3D20N+XFfzoTit7mWhQUqbKsGJO6YfjiXSKjkR36ipkFWOo17ZSnlxY2Xl
amN9kjiPnR9kYSqwslIucaW0/ocfG+OVm4jKJLWeiO+8yYYC/+gqV5UfCofL
Vs0cPq3K+MFbnWErM2Ut44cSh7Glq0JX6vskuVdVoyaJEF0mhfCrGq9/A+Yh
UtAoVheG9EjKc5O9Pfq7nI+Mne9hr5S6mIi1dtPl/I/Ll7SJPWmzxeZeoZ13
o7C5d4gtfa/c3mUzLXS21yVAZK2qzebqXPtFMx1Bjvg6/0nVB68qB3W7vUJO
VeH2uoZNwq1UO9eolA9MRO9AIhu/MBZqSPGkgHag6PcjcW68h/wLWfJycKP3
0t5t70ASWemf2OQTXqkN7FiEz0Kk4tLKBWzM3zPTVJ786hDOZOErkpdVUGFZ
Gf9H+mcEx+CNxuqNCpbL5ajd3UuSytgSz96zDcl4E3H17uj1eLwfv6dHh0cn
p+dft+tjrF/fXN0e3dxeHb9N350en729Dpuf/H4MN69mXZI3h1dfH98cvw0n
DsYvkwQepP2KNq+Pz95NxAA7osJ/gyRJ01TIKUmVwZVvFtoJV6tMz3TGyoFq
vTV5kyknpCgVvF6YmciVy6yekq95RLBVBZ92C107MVV+qVQFdzZW5dhEoFQO
BHQVwp5tCacesDlBZEBUSjFdCekcQkSSrfDeFgWxhGMIxBnsJ0psccRUczcK
gpQ6zwuVJMkLClRmm2M6Wb9KZB8eump+fBSmVhbQAQE9SzOH3ZtCWiiNZAUb
uFaQlM40NlNv+NQMXxeVcqwP4mmb2dyAJAwv5GymMiIN+nQWt60bCVZ2961M
VojKO7XmlEVUM9hCw4YCEsLUQn2QZV2ooVguoGQpajlXAqQINYwDB3ijlBXr
UnkX3l3Ie3CkwYklUlb92GirGFyYaHwSijwxS3Wv7JCExPOS/i+cwQky4ZIX
t23+yyZH6BQ5tkVDnHkjdFlbcx9k3AiXrfDyu65w2pNMZgagEJWC+zlpV0yg
RWtFllGsUuYlvMsWarVb6vnC0+tTlUlwwC6Fk2m2kNWcVEyKUI70A8fXOXME
Y+HlKhhqQ3NIXge21kTrBu+uWH0yL3WlKYwoDiF1BZwmuZTYUaP5CL7e4dsT
bzWSBPFOunTaq8HuKOB2YKtVoDdzxXyQ2sAghWGucgpPCLyUrBP1obbkiTjo
tqKRUofzSuZRTysiD+E8mduJQsPfbq/OKJIQLZAIhjiFW+W55vgHdbeQFGUb
zdM6fIQT09PwR4KL3CGe2whn52Y/an1huoo4QE+Y2utSO/YsbWNEguKbvsdD
+08divGP+VhfI1mjg91rxgC8jdIA8FESWDw8dNMJIOA/iXJbqIbExTZqjz/B
tMBUCFvUBUXADrNt2JE49UGjkU3QWphlq1TSd8MKBZl1jggGlXUNv33GnLRZ
qnIKfArIx7xsKyzt3uwrj+So1FKEkCEarskWkfoEBFkza4hcwC/h2jOtYFPm
VBaFWbrn4jReAYfA/Pkc1yJ7PUFGlMQoCEpFd7UrXYvvrGldbfCcRRoKmVkT
YuepLVvDUaiRndZ34UvgC/hjgZVixymFvKKpstOz1ePjLgGQWiEHhAyQ5218
Cq5qWL1uVWULa8AkScgCr72qbAqv65ZJ16IIs7/QkAdl2IpdBllod4hXLD3m
6dGZzHShmdza8UJMPJFvZk2JtOAARnQ8SEURkrx4QTUT35SFOGJAY99jBQvU
0oKKaScG72+vbwbD8FecX/Dnq+M/356iXKHP1yeHZ2frD0k8cX1ycXv2dvNp
c/Po4v374/O34TJWRW8pGbw//BY7VI0PLi5vTi/OD88GpBhGVTQPDWU1zlue
0UZTzQ58JCNKl7TRktOdr44u//bX8SvY7jcoig7G49fw5/Dls/Gnr/CFkmx4
zVQImvCV1JwgipS0bJKigJ1qqLxAvFMmQSBWglIlVPm770gz30/E59OsHr/6
Ii6QwL3FVme9RdbZ05Unl4MSn1l65pm1NnvrW5ru83v4be97q/fO4udfUoMi
0vFnX36RPFtJNpzOqHIyFOSMhcoib5rCzFfBFR8enpS6j48TcYbUOhTXXOwN
xSWctYQ5LfspBVpoJNPQSIqrFitOAry8Y3h5eNHD/ODGvXuMTduXNYERvU/x
EzhANIJPxXnFiZejMbvHyxF9okNPJQAcHOOliK1t1qe+KtAHfjUtVAcM0ZyJ
Ar7xekhAkTd0RIb48IZxxq0LYXZ7U0sUNVQuLhe6UAEUQtXCZaBDV8hJjk1g
AvIFIOOnMrS8PtiqDAk+5NJ1QctUqMIEVjBZhJiJqXtdRxA4oQ7yFIw7U7Uy
0FFTaXBGuSciZSjzWcxdWPPnn3/mviktqd6bKy7c98bQK1p4cfGn5CgQTG+4
3aU8Fr1r7y/yXlJg1z4JRqWj1lB/Jj+koPWHl5/s7yddg6MTCjfcgF4OHgFM
U1ztUBUdU6EOYkPWit258iNxW1mVGSxQGbL2SNfFnXlFaEv1FFUvhEohewsO
f9fUND+gpqNQEp7w8qBN/YzyISmyZwxD8iFXML3zSHHUuDGPyOEbF+NWOHrU
XFWQKIO7lbrlwMQaJTxSqGruFyiXUU3CZFTGMp5SYfqTCu4KHXQ4oudqelpn
BHFIFqcdi7J6oZardZ55eLHOjVDz0nRSUMxJ7YPQY3Q30iRxg5s2lHrB7dcu
S0dDhIROCCgcI2uDMCAQCtlgGRhpkiTjmJ2nqPDZRyVrvAcGH6lR4g234SLg
gtghMggLtGE6Ns98huBjN/ZrPNsheda2S6erdP1F7FCfhXCsiMS9QlQcdLml
WlxtHr69Om1LkR1UOWKNS+JVC0dkZ0KgkNPDxO0rhRDWqNFo7UVvAEam6pZ3
SXIY7RErybaLcc/058gTvf4MunhScjCZIEZ098h5p3oK/h4r4HCx69GzxnJL
NI9+1mU42JnCNZaJodWQzx5+I/RIjYbBvdcV4wboBjBGBvOPBklADrGZXHGF
jcYLCKR9QYJaDiNVRaxed9hCTtHxjkSvv5XCSzvnoiSoNwt41fe3h4d2noNS
JEB4SKqr6IqhOkRvSB0yN2mh9InP51sdM1fja1s8mz/Tnjf8E7k03fKXj9J7
Pqz+K5Nsx9WHIrpor/HZHllsUEeKywtAfDtciBOYpxMGvzTR+iEUYrY1NjCR
9zqf0Pm23XWMo3/UsCjNkQI2GT5YKdRKxtBDoRrb6Y204ebkX87GHrGxt/Bl
kfyS9ZFwVUNjDAqgFEyjyXFU5ct2rtpJxL/oQj3P4VS6Sbai42LczUYTdKdg
gC0541SwMHnbWCHG3ojQxbUI+np0sI2gPShE/lc0Ce9njo/wSlOIXiNLLXrF
zLSe8u8FULreCQNQCRdG/8toRooII5GP+AiVarIY/b+k+/UlnTg9PD+kxp8L
MBl7f16MqAGvW4/eOj2ddHduwsUG8xMyxjmUievH1ItvXWibB3ECGLGEIuHX
tRlOXlrjTQY/2iFaux1iyExzGriu8FTaWZ/0yjhsXUNBDWp90C5lBYth7Urx
HDyj3w4ffku/ijw+Yvko/tz2MZI9P/vV5KFewEzDY/9tFd/0i5E4EVuPobvx
j5iN1V8/zbPb8Ph6hFovjL6jyYdJHPK0IEaTYwrr9cSJBtOUGXeoT/QadqMx
pLIx/pDGBvx6LpBJaKQ52I3BzKwmNAMkGjyZjhM63xUgFncmMBV+DuHhOs2a
FbJ8iF76sUFDjtCzdjNnU/MAW5Xw0+sNK1GkpXYLHmSigJ6HTMlTcQ2/ZJhr
sUlmGQ/lgvd1kcqJXM101bYl26MMqpvo96apzO7IlIfZXWWWhcrn4RcVsqGs
7pj0tVc1oehZg2zO02wiZ9W9VksuaVyDKtWx7UH37xxWSHEiHwAA readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>