<?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.8 (Ruby 3.2.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpapi-link-template-04" number="9652" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.20.1 --> version="3" xml:lang="en">

  <front>
    <title abbrev="Link-Template">The Link-Template HTTP Header Field</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-link-template-04"/> name="RFC" value="9652"/>
    <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 year="2024" month="April" day="01"/>
    <area>Applications and Real-Time</area>
    <workgroup>Building Blocks for HTTP APIs</workgroup> month="September"/>

    <area>WIT</area>
    <workgroup>httpapi</workgroup>

    <keyword>link relation</keyword>

    <abstract>
      <?line 52?>
<t>This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, resources so that new links can be generated.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://ietf-wg-httpapi.github.io/link-template/draft-ietf-httpapi-link-template.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpapi-link-template/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Building Blocks for HTTP APIs Working Group mailing list (<eref target="mailto:httpapi@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/httpapi/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/httpapi/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ietf-wg-httpapi/link-template"/>.</t>
    </note>
  </front>
  <middle>
    <?line 57?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="URI-TEMPLATE"/> target="RFC6570"/> defines a syntax for templates that, when expanded using a set of variables, results in a URI <xref target="URI"/>.</t> target="RFC3986"/>.</t>
      <t>This specification defines a HTTP header field <xref target="HTTP"/> target="RFC9110"/> for conveying templates for links in the headers of a HTTP message. It is complimentary to the Link header field defined in <xref section="3" sectionFormat="of" target="WEB-LINKING"/>, target="RFC8288"/>, which carries links directly.</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 terms from <xref target="STRUCTURED-FIELDS"/>: List, String, Display String, and Parameter.</t>
      </section>
    </section>
    <section anchor="the-link-template-header-field">
      <name>The Link-Template Header Field</name>
      <t>The Link-Template header field is a Structured Field <xref target="STRUCTURED-FIELDS"/> that serializes one or more links into HTTP message metadata. It is semantically equivalent to the Link header field defined in <xref section="3" sectionFormat="of" target="WEB-LINKING"/>, target="RFC8288"/>, except that the link target and link anchor can contain URI Templates <xref target="URI-TEMPLATE"/>.</t> target="RFC6570"/>.</t>
<!-- [rfced] Section 2. We're having difficulty parsing the following sentence. It's not clear what "it" is.

Original:
   Its value is a List of Strings.  Each String is a URI Template, and
   Parameters on it carry associated metadata.

Perhaps:
   The Link-Template header field value is a List of Strings.  Each String
   is a URI Template, and the header field Parameters carry associated
   metadata.
-->
      <t>Its value is a List of Strings. Each String is a URI Template, and Parameters on it carry associated metadata.</t>
      <t>For example:</t>
      <sourcecode type="http-message"><![CDATA[
Link-Template: "/{username}"; rel="item"
]]></sourcecode>
      <t>indicates that a resource with the relation type "item" for a given "username" can be found by expanding the "username" variable into the template given.</t>
<!-- [rfced] Section 2. We're having difficulty parsing the second parenthetical phrase below. Can the link target become an absolute URI after expansion?

Original:
   The link target (as defined in Section 2 of [WEB-LINKING]) is the
   result of expanding the URI Template [URI-TEMPLATE] (being converted
   to an absolute URI after expansion, if necessary).

Perhaps:
   Expanding the URI Template [URI-TEMPLATE] creates the link target
   (as defined in Section 2 of [WEB-LINKING]), which can be an
   absolute URI, if necessary.
-->
      <t>The link target (as defined in <xref section="2" sectionFormat="of" target="WEB-LINKING"/>) target="RFC8288"/>) is the result of expanding the URI Template <xref target="URI-TEMPLATE"/> target="RFC6570"/> (being converted to an absolute URI after expansion, if necessary).</t>
      <t>The link context and link relation type for the link (as defined in <xref section="2" sectionFormat="of" target="WEB-LINKING"/>) target="RFC8288"/>) are conveyed using the "anchor" and "rel" Parameters, as they are for the Link header field in <xref section="3" sectionFormat="of" target="WEB-LINKING"/>. target="RFC8288"/>. Their values <bcp14>MUST</bcp14> be Strings.</t>
      <t>However, the "anchor" Parameter <bcp14>MAY</bcp14> contain a URI Template. For example:</t>
      <sourcecode type="http-message"><![CDATA[
Link-Template: "/books/{book_id}/author";
               rel="author"; anchor="#{book_id}"
]]></sourcecode>
      <t>Here, the link to the author for a particular book in a list of books can be found by following the link template.</t>
      <t>This specification defines additional semantics for the "var-base" Parameter on templated links; see below.</t> <xref target="the-var-base-parameter" format="default"/>.</t>
      <t>The link's target attributes (as defined in <xref section="2.2" sectionFormat="of" target="WEB-LINKING"/>) target="RFC8288"/>) are conveyed using other Parameters, in a manner similar to the Link header field. These Parameter values <bcp14>MUST</bcp14> be Strings, unless they contain non-ASCII characters, in which case they <bcp14>MUST</bcp14> be Display Strings. Note that some target attribute names will not serialise serialize as Structured Field Parameter keys (see <xref section="3.1.2" sectionFormat="of" target="STRUCTURED-FIELDS"/>).</t>
      <t>For example:</t>
      <sourcecode type="http-message"><![CDATA[
Link-Template: "/author"; rel="author";
               title=%"Bj%c3%b6rn J%c3%a4rnsida"
]]></sourcecode>
      <t>Implementations <bcp14>MUST</bcp14> support all levels of template defined by <xref target="URI-TEMPLATE"/> target="RFC6570"/> in the link String and the anchor Parameter.</t>
      <section anchor="the-var-base-parameter">
        <name>The 'var-base' parameter</name> Parameter</name>
        <t>When a templated link has a 'var-base' parameter, Parameter, its value conveys a URI-reference that is used as a base URI for the variable names in the URI template. Template. This allows template variables to be globally identified, rather than specific to the context of use.</t>
        <t>Dereferencing the URI for a particular variable might lead to more information about the syntax or semantics of that variable; specification of particular formats for this information is out of scope for this document.</t>
        <t>To determine the URI for a given variable, the value given is used as a base URI in reference resolution (as specified in <xref target="URI"/>). target="RFC3986"/>). If the resulting URI is still relative, the context of the link is used as the base URI in a further resolution; see <xref target="WEB-LINKING"/>.</t> target="RFC8288"/>.</t>
        <t>For example:</t>
        <sourcecode type="http-message"><![CDATA[
Link-Template: "/widgets/{widget_id}";
               rel="https://example.org/rel/widget";
               var-base="https://example.org/vars/"
]]></sourcecode>
        <t>indicates that a resource with the relation type "https://example.org/rel/widget" can be found by expanding the "https://example.org/vars/widget_id" variable into the template given.</t>
        <t>If the current context of the message that the header appears within is "https://example.org/", the same information could be conveyed by this header field:</t>
        <sourcecode type="http-message"><![CDATA[
Link-Template: "/widgets/{widget_id}";
               rel="https://example.org/rel/widget";
               var-base="/vars/"
]]></sourcecode>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security consideration considerations for the Link header field in <xref target="WEB-LINKING"/> target="RFC8288"/> and those for URI Templates <xref target="URI-TEMPLATE"/> both target="RFC6570"/> apply.</t>
      <t>Target attributes that are conveyed via Display Strings can be vulnerable to a wide variety of attacks. See <xref target="UNICODE-SECURITY"/> for advice regarding their handling. Specific advice is not given by this specification, specification since there are a variety of potential use cases for such attributes.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This specification enters the "Link-Template" field name into the Hypertext "Hypertext Transfer Protocol (HTTP) Field Name Registry.</t>
      <ul spacing="normal">
        <li>
          <t>Field Name: Link-Template</t>
        </li>
        <li>
          <t>Status: permanent</t>
        </li>
        <li>
          <t>Specification document: [this document]</t>
        </li>
      </ul> Registry".</t>
      <table anchor="http-field-name-registry">
        <name></name>
        <thead>
          <tr>
            <th>Field Name</th>
            <th>Status</th>
            <th>Reference</th>
          </tr>
         </thead>
       <tbody>
         <tr>
           <td>Link-Template</td>
           <td>Permanent</td>
           <td>This document</td>
         </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC6570" to="URI-TEMPLATE"/>
    <displayreference target="RFC3986" to="URI"/>
    <displayreference target="RFC8288" to="WEB-LINKING"/>

    <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 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

      <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.6570.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8288.xml"/>

<!-- [I-D.ietf-httpbis-sfbis] [STRUCTURED-FIELDS] now 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="URI-TEMPLATE">
        <front>
          <title>URI Template</title>
          <author fullname="J. Gregorio" initials="J." surname="Gregorio"/>
          <author fullname="R. Fielding" initials="R." surname="Fielding"/>
          <author fullname="M. Hadley" initials="M." surname="Hadley"/>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="D. Orchard" initials="D." surname="Orchard"/>
          <date month="March" year="2012"/>
          <abstract>
            <t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6570"/>
        <seriesInfo name="DOI" value="10.17487/RFC6570"/>
      </reference>
      <reference anchor="URI">
        <front>
          <title>Uniform Resource Identifier (URI): Generic Syntax</title>
          <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
          <author fullname="R. Fielding" initials="R." surname="Fielding"/>
          <author fullname="L. Masinter" initials="L." surname="Masinter"/>
          <date month="January" year="2005"/>
          <abstract>
            <t>A Uniform Resource Identifier (URI) is a compact sequence of 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 9651 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 AUTH48, 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>
        </front>
        <seriesInfo name="STD" value="66"/>
        <seriesInfo name="RFC" value="3986"/>
        <seriesInfo name="DOI" value="10.17487/RFC3986"/>
      </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 the type of those relationships ("link relation types").</t>
            <t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8288"/>
        <seriesInfo name="DOI" value="10.17487/RFC8288"/>
      </reference> be updated -->
      <reference anchor="STRUCTURED-FIELDS"> anchor="STRUCTURED-FIELDS" target="https://www.rfc-editor.org/info/rfc9651">
        <front>
          <title>Structured Field Values for HTTP</title>
          <author fullname="Mark Nottingham" initials="M." surname="Nottingham"> surname="Nottingham" fullname="Mark Nottingham">
           <organization>Cloudflare</organization>
          </author>
          <author initials="P.-H." surname="Kamp" fullname="Poul-Henning Kamp" initials="P." surname="Kamp"> Kamp">
           <organization>The Varnish Cache Project</organization>
          </author>
          <date day="23" month="January" month="September" year="2024"/>
          <abstract>
            <t>   This document describes a set of data types and associated algorithms
   that are intended to make it easier and safer to define and handle
   HTTP header and trailer fields, known as "Structured Fields",
   "Structured Headers", or "Structured Trailers".  It is intended for
   use by specifications of new HTTP fields that wish to use a common
   syntax that is more restrictive than traditional HTTP field values.

   This document obsoletes RFC 8941.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-sfbis-05"/> name="RFC" value="9651"/>
        <seriesInfo name="DOI" value="10.17487/RFC9651"/>
      </reference>

<!-- [rfced] Informative References. FYI, because a date was provided in the following reference, we have updated it to provide both a versioned and versionless URL. Please let us know if any changes are necessary.

Original:
   [UNICODE-SECURITY]
              Davis, M. and M. Suignard, "Unicode Security
              Considerations", Unicode Technical Report #16, 19
              September 2014, <http://www.unicode.org/reports/tr36/>.

Current:
   [UNICODE-SECURITY]
              Davis, M. and M. Suignard, "Unicode Security
              Considerations", Unicode Technical Report #36, 19
              September 2014,
              <https://www.unicode.org/reports/tr36/tr36-15.html>.
              Latest version available at
              <https://www.unicode.org/reports/tr36/>.
-->
      <reference anchor="UNICODE-SECURITY" target="http://www.unicode.org/reports/tr36/"> target="https://www.unicode.org/reports/tr36/">
        <front>
          <title>Unicode Security Considerations</title>
          <author initials="M." surname="Davis" fullname="Mark Davis">
            <organization/>
          </author>
          <author initials="M." surname="Suignard" fullname="Michel Suignard">
            <organization/>
          </author>
          <date year="2014" month="September" day="19"/>
        </front>
        <seriesInfo name="Unicode Technical Report" value="#16"/>
        <annotation>Latest version available at <eref target="https://www.unicode.org/reports/tr36/" brackets="angle"/>.</annotation>
      </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 are used to signify the requirements in

      <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>
  </back>
<!-- [rfced] Terminology. Should the specification. These words are often capitalized. This document defines these words as they should Parameters var-base, anchor, and rel be interpreted placed in IETF documents. This document specifies an Internet Best Current Practices for double quotes, single quotes, or left bare? We see instances of all three formats (e.g., "rel", 'var-base', anchor) within the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity text.
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed.  Updates of 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 this nature typically result in protocol specifications. This document aims to reduce the ambiguity by clarifying more precise language, which is helpful for readers.

Note that only UPPERCASE usage of the key our script did not flag any 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>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81Z23LbOBJ951dglUo5mTIly/FmbGUyM47tjLXr21pypVJT
U1sQCUkYU4QWAKVoXM637Lfsl+1pgKBJS7nNvmweLBJANxrdp083mDiOIytt
JnqsNZwKdibz23goZvOMW8FOh8Mrdip4KjR7K0WWtiI+GmmxwOrGylaU4O9E
6VWPGZtGUaqSnM+gNdV8bGMp7DieWjvncxlnJGlLyXhnL4K6FxHXgkPt4Xye
SSiTKjeM5ym7FjyLh3KGPZZK3060KuZY96aQWSrzCXuTqeTWsLHS3tzDq75p
RXKue8zqwtjdnZ2Dnd0ouhUryKc9d8TmG9Q8DLwTo/VBMplpkTm7omgh8kL0
Isa+0hrG7GpOLn6HE9CyX0iOxmdcZhgvXfMz+amt9ISmuE6m5ZTpdTq0kobk
QrTDsg4NdEZaLY3olDo6JDuRdlqMIO0cv5wE33cavqeV9GtsbZ9HEm2vqi1V
U7bzpcC2p3aWtaKIF3aqNJwVYzfGZG567LzNLpS18MSUz9ywB8s517ePZ3BM
nss/nOd7bmSujOWZf2YsZleaTzXP3XuiitwSCg8Res0zyd2w8H6e5cr+TH/a
ubBuotCyx8LRl8tlO8x2oihXeoZtFy7SFM0eu357dNDt7uD95rofD0/Or84O
hydu/OVfvy/H3euLg/2XeH138iY+61/8vX/xixve393fx/BgeH1zNLy5PjmO
3/ZPzo4HPdaPj9uVN0fSxGaMv6Txon90eXwSD06OoHz43h+8TNqbXCYqFWwg
EhzFrtgR8kYiX30GuaVVBJy3ap4+5gtpmsMymYqMDQo5yblO3VyKYPbY7k53
L945iLsHbtAILYWR+ViFOGwFU4YimeKRZ0jdudJ2q8e2nnRfbnmzuZ4I611e
erzwcg7P2kmYjtUvXiICcRwzPqJAJjaKhlNpmJmLRI5LhmCpGMtcGGY3U9fU
U9eYqGubzbVaSJelnM0Ez32apsIkWo5omLRgsyKxhRZMjbHOJf5I2KUQObNL
BRIwqtCJMNvMKEhwy3KxdOsMS3iOxWwicgqASNuRP8NMpmkm8PKE9QFPlWIL
RyR3d3Uc3d9XB+LMrHLLPzgTQ0oZt982W05hjPgwBz2KlBXGH8kISzYvuJZ8
lJGBsLXIrEHOYRobMbfd/X37s77k676DII3BPjInUflCrJzDKsNo3PsAm5Ef
vbjxXnQKZ8IYPhFt1rcMmycKsqB1nFKvmFVVDJs7e6tSUnt3B5Q7U1+Q2lpq
3d+TU4BdREATMEtbUqkhka1w4CdPiFjcSYHMIzpC7lMkoroHpmdE9Ya1zm8G
w9a2/2UXl+75+uQfN31kKz0PTg/PzqqHqFwxOL28OTt+eHqQPLo8Pz+5OPbC
GGWNoah1fvgeM1TqWpdXw/7lxeFZy3sRXkIdLchHqAaCnAR0ydwKPdcC+GLc
RCV+vYveHF3959/dPbjqLyCb3W73ADHzL/vd7/fwQtjxu6k8W5WvcP0q4vO5
4NqBJcvgyLkEywJFHECZqmWOuGgBT373K3nmtx77YZTMu3s/lgN04MZg8Flj
0PlsfWRN2Dtxw9CGbSpvNsYfebpp7+H7xnvwe23wh58AIcHi7v5PP0Yb86Uw
JfGMVZappc8HPUMuaDUjsD7m+Pt7ajcMEnhgNZZvs2NpkD+r6v2Ka9AwtLQd
V2xoyGq9mAduc76ROpJyeRD4LPVSmw3zREakjpL5B86lcHak9EwBdiGvAb96
IuPXchQHHjLaoMoip8D8AJb4VyEXPCPo/u+5LT4kYm69kaTKsbIvJQ7K7p3n
yZTYCRwMhrIcWonzhhVHPSZbOLkPdoSVhfDOoujQ9j4eps1OODjFv/kVdY0+
jaqYkdOYtI6CVsgaoxJJReDBT1H0FgaKDxzyaCqijx8/ukIYlx6NGsFET9a5
A8g0leb71ivqP1+3JDi3RZJRJPOUsFiWBRgXahNbomdzjgotq+s/mRd2XM3R
IoIBWSts0ArFa4wOKmWjVVlgQl2sLQwVxkOCJkMd8ErbHpn1ID0DiWyM9u5a
tJ+To73tVL1ovmlJPQRrMWXPRoIWuhqlyfswEQdDF6GywnppNK5Ce60GRmwz
OUYRTygIevW8bj4BSXyogazpUFecw9pvOiPRua+jVQV3XvYgbvlygM1aNXw5
KiaqdtJh7/W0+kI6tYlXpPa4N8xxN+IeMB9Fp2op4LztpkWVHQzsWWVYMyPa
7FsBPlLq1nTu6OefMr3v+F619apsKqt/Dvthskz1160nlWCZEqcoUds1ivDw
9HIl7udcg6MK3KUYCfvmKCsT35mzlgk1gq80hxN/vpVKU1l2HIEcTRW4FvIo
HnEj6r4lZJWqPeLMK4gKmAMLasjcMhX/WQRuVBANfBqB7a/EoIJhugE55x6Y
jo6WGTmjO+gnCd0hy4jacTZjbJsVORrUEswBSrnK48PBUb/Pkimnjj/sHzo7
aHYCQVuzehp3pxRlJVMzseYgd8cxIEe0N7jlhXIHtfDbWp18OAR6Q/iWolBL
q3bX+3RDMX3+J4i+gnYD6I+zwF36Xj9tvfn9afLi6eilztnf6Invabr18TIL
+rSt66z9ZxTnMFPM6W7lmrsM+Z253rxi7oAbwH2NU8uW3gG/LIbETy61fNFt
Ni6+c9kK+N6inPPTUfSO7i78EcjZlFNx3SQBBFQ12oO1LMOxFmNke56UIUcS
okRRS4x5UuKYKSRbVbM8BsoT0Yoqk5lLZE6pbh78Ul2nyu57kqmRa3BwyUY+
A/e4WeKyR3kDO/KKCUKWhBICZ8M++OdYBMvrFW2NnCqLZ3IytQgZd7XMdWR0
73bfJhRVNlX4rqi8MULRA9lQiMk7QdurR0yF+dqeXmugKGkaG+GVdoKESVRV
/Gp3FKInBSBRF0y9c/Novt8IdmyXUaGw+pnN8UOgHuJM/Q2KOBlDVFeeJJCd
u9o+RzM6rrUP5GKnB8stJb4v4IvSgFpwKoTXDKGxuimcjQvtQv1giufnu7tm
jf12BljKFGyFWugfXFHbXAbD56pSe/nhJCs1rAuFrNosiVnT+dMd5Rds+VJT
+UmDKid8VbtZhjwptKYLx6OohvtKdX0oa5a/8Bp3NukAuNGeloeKAXE08iFR
BcrEqFZDcT6XEPWa+H8T+0agcbn81BdD12KYMJnUJ7/UczZSoCwRynim+PxV
DI0X8IWAuG81w7XOxsOx3q8sJH/cAASwLYqMvr8RZKj5R3xTz+MCB6LvUdby
5Bb9wsAl7uPvq+VXLp4upOOcCdcBsOiaQfEpaGIC6UD05UoEnroKz2YBCg22
3UYH5esVCM0dh9ftmqN9AWujWQT/uH7HM7Ep0P48OMN/G+gfXhxuCN1aKypy
dzV12db8L5uHfDpFKmuXMUONK9GYWkCtrEpUxp7Rlf952RNdUA5ciwm6ZU2B
+q423mt+isDcAP1HYXoMylGOYAiNNfvksnL02K+NSvJb+d10hDhF/wWmrR7K
oxoAAA== in particular, but this should still be reviewed as a best practice.
-->
 </rfc>