<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?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> <seriesInfoname="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 tworesources,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><xreftarget="URI-TEMPLATE"/>target="RFC6570"/> defines a syntax for templates that, when expanded using a set of variables, results in a URI <xreftarget="URI"/>.</t>target="RFC3986"/>.</t> <t>This specification defines a HTTP header field <xreftarget="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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</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 <xreftarget="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 <xreftarget="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; seebelow.</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 notserialiseserialize 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 <xreftarget="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 URItemplate.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 <xreftarget="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 <xreftarget="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 securityconsiderationconsiderations for the Link header field in <xreftarget="WEB-LINKING"/>target="RFC8288"/> and those for URI Templates <xreftarget="URI-TEMPLATE"/> bothtarget="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 thisspecification,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 theHypertext"Hypertext Transfer Protocol (HTTP) Field NameRegistry.</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 RFC3864 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 be9651 inrelative 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 implementationAUTH48, toparse 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 --> <referenceanchor="STRUCTURED-FIELDS">anchor="STRUCTURED-FIELDS" target="https://www.rfc-editor.org/info/rfc9651"> <front> <title>Structured Field Values for HTTP</title> <authorfullname="Mark Nottingham"initials="M."surname="Nottingham">surname="Nottingham" fullname="Mark Nottingham"> <organization>Cloudflare</organization> </author> <author initials="P.-H." surname="Kamp" fullname="Poul-HenningKamp" initials="P." surname="Kamp">Kamp"> <organization>The Varnish Cache Project</organization> </author> <dateday="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> <seriesInfoname="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 thespecification. These words are often capitalized. This document defines these words as they shouldParameters var-base, anchor, and rel beinterpretedplaced inIETF documents. This document specifies an Internet Best Current Practices fordouble quotes, single quotes, or left bare? We see instances of all three formats (e.g., "rel", 'var-base', anchor) within theInternet 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>Ambiguitytext. --> <!-- [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 ofUppercase 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 usedthis nature typically result inprotocol specifications. This document aims to reduce the ambiguity by clarifyingmore precise language, which is helpful for readers. Note thatonly UPPERCASE usage of the keyour script did not flag any wordshave 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>