<?xml 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.19 (Ruby 3.0.2) -->
<?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-httpapi-deprecation-header-latest" number="9745" updates="" obsoletes="" submissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 --> version="3" xml:lang="en">

  <front>
    <title>The Deprecation HTTP Header Field</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-deprecation-header-latest"/> name="RFC" value="9745"/>
    <author initials="S." surname="Dalal" fullname="Sanjay Dalal">
      <organization/>
      <address>
        <email>sanjay.dalal@cal.berkeley.edu</email>
        <uri>https://github.com/sdatspun2</uri>
      </address>
    </author>
    <author initials="E." surname="Wilde" fullname="Erik Wilde">
      <organization/>
      <address>
        <email>erik.wilde@dret.net</email>
        <uri>http://dret.net/netdret</uri>
      </address>
    </author>
    <date year="2024" month="October" day="09"/>
    <area>Web and Internet Transport</area>
    <workgroup>HTTPAPI</workgroup>
    <keyword>HTTP, deprecation</keyword>
    <abstract>
      <?line 44?>

<t>The year="2025" month="March"/>
    <area>WIT</area>
    <workgroup>httpapi</workgroup>
    <keyword>HTTP</keyword>
    <keyword>deprecation</keyword>

<!-- [rfced] Please clarify "(in the sense of URI)" here. Also note that we do
not see "URI" used elsewhere in the document.

Original:
   The Deprecation HTTP response header field is used to signal to
   consumers of a resource (in the sense of URI) that the resource will
   be or has been deprecated.
-->

<!-- [rfced] We suggest updating "and possibly ways" to improve readability of
the text. Also, this sentence includes both "Additionally" and
"additional". May we replace "additional" with "further" or something
similar?

Original:
   Additionally, the deprecation link
   relation can be used to link to a resource that provides additional
   information about planned or existing deprecation, and possibly ways
   in which client application developers can best manage deprecation.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status deprecation.

Perhaps:
   Additionally, the deprecation link
   relation can be used to link to a resource that provides further
   information for this document about planned or existing deprecation. It may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpapi-deprecation-header/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        HTTPAPI Working Group mailing list (<eref target="mailto:httpapi@ietf.org"/>), also provide ways
   in which client application developers can best manage deprecation.
-->

    <abstract><t>The Deprecation HTTP response header field is archived at <eref target="https://mailarchive.ietf.org/arch/browse/httpapi/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/httpapi/"/>.
        Working Group information used to signal to
    consumers of a resource (in the sense of URI) that the resource will be
    or has been deprecated. Additionally, the deprecation link relation can be found at <eref target="https://ietf-wg-httpapi.github.io/"/>.
      </t>
      <t>Source for this draft
    used to link to a resource that provides additional information about
    planned or existing deprecation and an issue tracker possibly ways in which client
    application developers can be found at
        <eref target="https://github.com/ietf-wg-httpapi/deprecation-header"/>.</t>
    </note> best manage deprecation.</t>
    </abstract>

  </front>
  <middle>
    <?line 49?>

<section anchor="introduction">
      <name>Introduction</name>

      <t>Deprecation of an HTTP resource (<xref section="3.1" sectionFormat="of" target="HTTP"/>) target="RFC9110"/>) communicates information about the lifecycle of a resource. It encourages client applications to migrate away from the resource, discourages applications from forming new dependencies on the resource, and informs applications about the risk of continued dependence upon the resource.</t>
      <t>The act of deprecation does not change any behavior of the resource. It informs client applications of the fact that a resource will be or is has been deprecated. The Deprecation HTTP response header field can be used to convey this information at runtime indicating and indicates when the deprecation will be in effect.</t>
      <t>In addition to the Deprecation header field, the resource provider can use other header fields such as the Link (<xref target="LINK"/>) header field <xref target="RFC8288"/> to convey additional information related to deprecation. This can be information such as where to find documentation related to the deprecation, what can be used as a replacement, and when a deprecated resource becomes non-operational.</t>
      <section anchor="notational-conventions"> anchor="requirements-language">
        <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?>

<t>This here.
        </t>

<!-- [rfced] Would it be helpful to update this sentence to clarify what the
document uses? Note that [STRUCTURED-FIELDS] has been published as an RFC
9651, so we updated the reference entry accordingly. We used [RFC9651] as
the citation, bet us know if you prefer to use [STRUCTURED-FIELDS].

Original:
   This document uses "Structured Field Values for HTTP" (<xref target="STRUCTURED-FIELDS"/>)
   ([STRUCTURED-FIELDS]) to specify syntax and parsing of date values.

Perhaps:
   This document uses the mechanisms defined in [RFC9651] to
   specify syntax and parsing of date values.
-->

<t>This document uses "<xref target="RFC9651" format="title"/>" <xref
	target="RFC9651"/> to specify syntax and parsing of date values.</t>
        <t>The term "resource" is to be interpreted as defined in <xref
        section="3.1" sectionFormat="of" target="HTTP"/>.</t> target="RFC9110"/>.</t>
      </section>
    </section>
    <section anchor="the-deprecation-http-response-header-field">
      <name>The Deprecation HTTP Response Header Field</name>
      <t>The <tt>Deprecation</tt> HTTP response header field allows a server to communicate to a client application that the resource in the context of the message is or will be or has been deprecated.</t>
      <section anchor="syntax">
        <name>Syntax</name>
        <t>The <tt>Deprecation</tt> response header field describes the deprecation of the resource identified with the response it occurred within (see <xref section="6.4.2" sectionFormat="of" target="HTTP"/>). target="RFC9110"/>). It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been was deprecated at that date).</t>

        <t><tt>Deprecation</tt> is an Item Structured Header Field; its value <bcp14>MUST</bcp14> be a Date as per <xref section="3.3.7" sectionFormat="of" target="STRUCTURED-FIELDS"/>.</t> target="RFC9651"/>.</t>
        <t>The following example shows that the resource context has been was deprecated on Friday, June 30, 2023 at 23:59:59 UTC:</t>
        <artwork><![CDATA[
Deprecation: @1688169599
]]></artwork>
      </section>
      <section anchor="scope">
        <name>Scope</name>
        <t>The Deprecation header field applies to the resource identified with the response it occurred within (see <xref section="6.4.2" sectionFormat="of" target="HTTP"/>), target="RFC9110"/>), meaning that it announces the upcoming deprecation of that specific resource. However, there may be scenarios where the scope of the announced deprecation is larger than just the single resource where it appears.</t>
        <t>Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of the resource know about the increased scope and can behave accordingly. When doing so, it is important to take into account that such increased scoping is invisible for consumers who are unaware of the increased scoping rules. This means that these consumers will not be aware of the increased scope, and they will not interpret deprecation information different differently from its standard meaning (i.e., it applies to the resource only).</t>

	<t>Using such an increased scope still may make sense, as deprecation information is only a hint anyway. It is optional information that cannot be depended on, and client applications should always be implemented in ways that allow them to function without Deprecation deprecation information. Increased scope information may help client application developers to glean additional hints from related resources and, thus, and thus might allow them to implement behavior that allows enables them to make educated guesses about resources becoming deprecated.</t>
        <t>For example, an API might not use Deprecation header fields on all of its resources, resources but only on designated resources such as the API's home document. This means that deprecation information is available, but in order to get it, client application developers have to periodically inspect the home document. In this example, the extended context of the Deprecation header field would be all resources provided by the API, while the visibility of the information would only be on the home document.</t>
      </section>
    </section>
    <section anchor="the-deprecation-link-relation-type">
      <name>The Deprecation Link Relation Type</name>

<!-- [rfced] May we we update the text starting with "and possibly..." as
follows to improve the flow of the sentence?

Original:
   This can happen before the actual
   deprecation, to make a deprecation policy discoverable, or after
   deprecation, when there may be documentation about the deprecation,
   and possibly documentation of how to manage it.

Perhaps:
   This can happen before the actual
   deprecation to make a deprecation policy discoverable or after
   deprecation when there may be documentation about the deprecation and
   how to manage it.
-->

<t>In addition to the Deprecation HTTP header field, the server can use links with the "deprecation" link relation type to communicate to the client application developer where to find more information about deprecation of the context. This can happen before the actual deprecation, deprecation to make a deprecation policy discoverable, discoverable or after deprecation, deprecation when there may be documentation about the deprecation, deprecation and possibly documentation of how to manage it.</t>
      <t>This specification places no restrictions on the representation of the linked deprecation policy. In particular, the deprecation policy may be available as human-readable documentation or as a machine-readable description.</t>
      <section anchor="documentation">
        <name>Documentation</name>
        <t>The purpose of the <tt>Deprecation</tt> header field is to provide a hint about deprecation to the resource consumer. Upon reception of the <tt>Deprecation</tt> header field, the client application developer can look up the resource's documentation in order to find deprecation related deprecation-related information. The documentation <bcp14>MAY</bcp14> provide a guide and timeline to migrate for migrating away from the deprecated resource to a new resource(s) replacing that replaces the deprecated resource, if applicable. The resource provider can provide a link to the resource documentation using a <tt>Link</tt> header field with the relation type <tt>deprecation</tt> as shown below:</t>
        <artwork><![CDATA[
Link: <https://developer.example.com/deprecation>;
      rel="deprecation"; type="text/html"
]]></artwork>

<!-- [rfced] Would it be helpful to update "under which circumstances and with
which policies" for readability as follows?

Original:
   This may be the documentation explaining under which
   circumstances and with which policies deprecation might take place.

Perhaps:
   This may be the documentation explaining the
   circumstances in which deprecation might take place and the deprecation policies.
-->

<t>In this example example, the linked content provides additional information
        about deprecation of the resource context. There is no Deprecation
        header field in the response, and thus response; thus, the resource is not (yet)
        deprecated. However, the resource already exposes a link where
        information is available describing how deprecation is managed for the resource. resource is
        available. This may be the documentation explaining under which
        circumstances and with which policies deprecation might take
        place. For example, a policy may indicate that deprecation of a
        resource(s) will always be signaled in the dedicated places at least N
        days ahead of the planned deprecation date and then only the
        resource(s) would be deprecated. deprecated on the planned date. Or a policy may indicate that the
        resource(s) would be deprecated first and then only be signaled as
        deprecated at dedicated places. The documentation documentation, in addition to the
        deprecation policy policy, may also provide a migration guide exaplaining explaining to
        consumers of the resource how to migrate to a new resource(s) or an alternate
        resource(s) before the deprecation date. Such policy and documentation
        would be very useful to consumers of the resource to plan ahead and
        migrate successfully.</t>
        <t>The following example uses the same link Link header field, field but also announces a deprecation date using a Deprecation header field:</t>
        <artwork><![CDATA[
Deprecation: @1688169599
Link: <https://developer.example.com/deprecation>;
      rel="deprecation"; type="text/html"
]]></artwork>
        <t>Given that the deprecation date is in the past, the linked information resource may have been updated to include information about the deprecation, allowing consumers to discover information about the deprecation and how to best manage it.</t>
      </section>
    </section>
    <section anchor="sunset">
      <name>Sunset</name>
      <t>In addition to the deprecation related deprecation-related information, if the resource provider wants to convey to the client application that the deprecated resource is expected to become unresponsive at a specific point in time, the Sunset HTTP header field <xref target="RFC8594"/> can be used in addition to the <tt>Deprecation</tt> header field.</t>
      <t>The timestamp given in the <tt>Sunset</tt> header field <bcp14>MUST NOT</bcp14> be earlier than the one given in the <tt>Deprecation</tt> header field. If that happens for some reasons such as (for example, due to misconfiguration of deployment of the resource or an error, error), the client application developer <bcp14>SHOULD</bcp14> consult the resource developer to get clarification.</t>
      <t>The following example shows that the resource in context has been was deprecated since on Friday, June 30, 2023 at 23:59:59 UTC and its sunset date is Sunday, June 30, 2024 at 23:59:59 UTC. Please note that for historical reasons the Sunset HTTP header field uses a different data format for date.</t>
      <artwork><![CDATA[
Deprecation: @1688169599
Sunset: Sun, 30 Jun 2024 23:59:59 UTC
]]></artwork>
    </section>
    <section anchor="resource-behavior">
      <name>Resource Behavior</name>

<!-- [rfced] How may we update "allowing consumers to still" to improve
clarity?

Original:
   The presence of a Deprecation header field in response is not meant
   to signal a change in the meaning or function of a resource in the
   context, allowing consumers to still use the resource in the same way
   as they did before the resource was declared deprecated.

Perhaps:
   The presence of a Deprecation header field in a response is not meant
   to signal a change in the meaning or function of a resource in the
   context; consumers can still use the resource in the same way
   as they did before the resource was declared deprecated.
-->

      <t>The act of deprecation does not change any behavior of the resource. The presence of a Deprecation header field in a response is not meant to signal a change in the meaning or function of a resource in the context, allowing consumers to still use the resource in the same way as they did before the resource was declared deprecated.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="the-deprecation-http-response-header-field-1">
        <name>The Deprecation HTTP Response Header Field</name>
        <t>The <tt>Deprecation</tt> response header field should be has been added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (<xref section="16.3.1" sectionFormat="of" target="HTTP"/>)</t>
        <artwork><![CDATA[
Header Field Name: Deprecation

Structured Type: Item

Status: permanent

Specification document: this specification,
            Section 2 "The target="RFC9110"/>) as follows:</t>
        <dl newline="false">
	  <dt>Field Name:</dt><dd>Deprecation</dd>
	  <dt>Status:</dt><dd>permanent</dd>
	  <dt>Structured Type:</dt><dd>Item</dd>
	  <dt>Reference:</dt> <dd>RFC 9745, <xref target="the-deprecation-http-response-header-field" format="default"/>: The Deprecation HTTP Response Header Field"
]]></artwork> Field</dd>
	</dl>
      </section>
      <section anchor="the-deprecation-link-relation-type-1">
        <name>The Deprecation Link Relation Type</name>
        <t>The <tt>deprecation</tt> link relation type should be has been added to the permanent "Link Relation Types" registry of link relation types (<xref section="4.2" sectionFormat="of" target="LINK"/>).</t>
        <artwork><![CDATA[ target="RFC8288"/>) as follows:</t>

<!-- [rfced] Please review "resource that is documentation" here. Should this
be updated to "resource documentation", "documentation", or something
else?

If any changes are made, we will ask IANA to update the "Link Relation Name: deprecation Types"
accordingly prior to publication (link to registry:
https://www.iana.org/assignments/link-relations).

Original:
  Description: Refers to a resource that is documentation (intended for human
  consumption) about the deprecation of the link's context.

Specification document: this specification,
        Section 3 "The Deprecation Link Relation Type"
]]></artwork>

Perhaps:
  Description: Refers to resource documentation (intended for human
  consumption) about the deprecation of the link's context.

Or:
  Description: Refers to documentation (intended for human
  consumption) about the deprecation of the link's context.
-->

	<dl newline="false">
	  <dt>Relation Name:</dt><dd>deprecation</dd>
	  <dt>Description:</dt><dd>Refers to a resource that is documentation (intended for human consumption) about the deprecation of the link's context.</dd>
	  <dt>Reference:</dt><dd>RFC 9745, <xref target="the-deprecation-link-relation-type" format="default"/></dd>
      </dl>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>

<!-- [rfced] How may we update the text starting with "even though one
might..." to improve sentence clarity?

Original:
   Deprecated resources function as
   they would have without sending the deprecation header field, even
   though one might consider non-functional details such as making them
   progressively less efficient with longer response time for example.

Perhaps:
   Deprecated resources function as
   they would have without sending the Deprecation header field,
   even though non-functional details may be affected (e.g.,
   they have less efficiency and longer response times).
-->

<!-- [rfced] What does "it" refer to in this sentence?

Original:
   In cases where the Deprecation header field value is a date in the
   future, it can lead to information that otherwise might not be
   available.

Perhaps:
   In cases where the Deprecation header field value is a date in the
   future, information might become available that would not be available otherwise.
-->

      <t>The Deprecation header field should be treated as a hint, meaning that the resource is indicating (and (but not guaranteeing with certainty) that it will be or is has been deprecated. Deprecated resources function as they would have without sending the deprecation Deprecation header field, even though one might consider non-functional details such as making them progressively less efficient with longer response time time, for example.</t>
      <t>Resource documentation should provide additional information about the deprecation, such as including recommendation(s) recommendations for replacement. Developers of client applications consuming the resource <bcp14>SHOULD</bcp14> always check the referred resource documentation to verify authenticity and accuracy. In cases where a <tt>Link</tt> header field is used to provide documentation, one should assume (unless served over HTTPS) that the content of the <tt>Link</tt> header field may not be secure, private private, or integrity-guaranteed, and so due caution should be exercised when using it, see it (see <xref section="5" sectionFormat="of" target="LINK"/> target="RFC8288"/> for more details. details). In cases where the Deprecation header field value is in the past, the client application developers <bcp14>MUST</bcp14> no longer assume that the behavior of the resource would will remain the same as before the deprecation date. In cases where the Deprecation header field value is a date in the future, it can lead to information that otherwise might not be available. Therefore, client application developers consuming the resource <bcp14>SHOULD</bcp14>, if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to a recommended resource(s).</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC8288" to="LINK"/>

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

    <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <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, authors would like to thank <contact fullname="Nikhil Kolekar"/>,
      <contact fullname="Darrel Miller"/>, <contact fullname="Mark
      Nottingham"/>, and defines aspects of the protocol that are shared by <contact fullname="Roberto Polli"/> for their
      contributions.</t>
      <t>The authors take 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="LINK">
        <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 responsibility for the relationships between resources on the Web ("links") errors and the type of those relationships ("link relation types").</t>
            <t>It also defines the serialisation of such links omissions.</t>
    </section>
  </back>

<!-- [rfced] Some sentences 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="STRUCTURED-FIELDS">
        <front>
          <title>Structured Field Values for HTTP</title>
          <author fullname="Mark Nottingham" initials="M." surname="Nottingham">
            <organization>Cloudflare</organization>
          </author>
          <author fullname="Poul-Henning Kamp" initials="P." surname="Kamp">
            <organization>The Varnish Cache Project</organization>
          </author>
          <date day="21" month="April" 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 mention deprecation 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-06"/>
      </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 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
resource while others mention deprecation of the Internet Community, and requests discussion context. Please review
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 let us know if any updates are needed.

deprecation 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 "resource":
  resource will be used or has been deprecated
  resource in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage context 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>
      <reference anchor="RFC8594">
        <front>
          <title>The Sunset HTTP Header Field</title>
          <author fullname="E. Wilde" initials="E." surname="Wilde"/>
          <date month="May" year="2019"/>
          <abstract>
            <t>This specification defines the Sunset HTTP response header field, which indicates that a URI message is likely to become unresponsive at a specified point or will be deprecated
  resource in context has been deprecated
  deprecation of the future. It also defines a sunset link relation type resource
  deprecation of that allows linking to resources providing information about an upcoming specific resource or service sunset.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8594"/>
        <seriesInfo name="DOI" value="10.17487/RFC8594"/>
      </reference>
    </references>
    <?line 192?>

<section anchor="implementation-status">
      <name>Implementation Status</name>
      <t>Note to RFC Editor: Please remove this section before publication.</t>
      <t>This section records the status
  deprecation of known implementations a resource(s)

deprecation of the protocol defined by this specification at the time "context":
  resource context will be deprecated
  resource context has been deprecated
  deprecation of posting the context
  deprecation of this Internet-Draft. The description the resource context
  deprecation of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. link's context

Please note that the listing also review use of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, "context" and must not be construed to be, a catalog of available implementations or their features. Readers let us know if any updates are advised to note that
other implementations may exist.</t>
      <t>According to RFC 7942, "this will allow reviewers needed
for consistency and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence clarity.

Examples:
   resource in context of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to message
   resource context
   resource in context
   resource in the individual working groups to use this information as they see fit".</t>
      <section anchor="implementing-the-deprecation-header-field">
        <name>Implementing context
   link's context
-->

<!-- [rfced] We note inconsistencies in the Deprecation Header Field</name>
        <t>This is a list of implementations that implement terms below throughout the deprecation header field:</t>
        <t>Organization: Apollo</t>
        <ul spacing="normal">
          <li>
            <t>Description:
text. Should these be uniform? If so, please let us know which form is
preferred.

Deprecation HTTP response header field is returned when deprecated functionality (as declared in the GraphQL schema) is accessed</t>
          </li>
          <li>
            <t>Reference: https://www.npmjs.com/package/apollo-server-tools</t>
          </li>
        </ul>
        <t>Organization: Zalando</t>
        <ul spacing="normal">
          <li>
            <t>Description:
Deprecation HTTP header field is recommended as the preferred way to communicate API deprecation in Zalando API designs.</t>
          </li>
          <li>
            <t>Reference: https://opensource.zalando.com/restful-api-guidelines/#deprecation</t>
          </li>
        </ul>
        <t>Organization: Palantir Technologies</t>
        <ul spacing="normal">
          <li>
            <t>Description:
Deprecation response header field is incorporated in code generated by conjure-java, a CLI to generate Java POJOs and interfaces from Conjure API definitions</t>
          </li>
          <li>
            <t>Reference: https://github.com/palantir/conjure-java</t>
          </li>
        </ul>
        <t>Organization:  E-Voyageurs Technologies</t>
        <ul spacing="normal">
          <li>
            <t>Description:
Deprecation header field is incorporated in Hesperides, a configuration management tool providing universal text file templating and properties editing through a REST API or a webapp.</t>
          </li>
          <li>
            <t>Reference: https://github.com/voyages-sncf-technologies/hesperides/blob/master/documentation/lightweight-architecture-decision-records/deprecated_endpoints.md</t>
          </li>
        </ul>
        <t>Organization: Open-Xchange</t>
        <ul spacing="normal">
          <li>
            <t>Description: Deprecation

Sunset HTTP header field is used in Open-Xchange appsuite-middleware</t>
          </li>
          <li>
            <t>Reference: https://github.com/open-xchange/appsuite-middleware</t>
          </li>
        </ul>
        <t>Organization: MediaWiki</t>
        <ul spacing="normal">
          <li>
            <t>Description: Core REST API of MediaWiki would use Deprecation
Sunset header field for endpoints that have been deprecated because a new endpoint provides the same or better functionality.</t>
          </li>
          <li>
            <t>Reference: https://phabricator.wikimedia.org/T232485</t>
          </li>
        </ul>
        <t>In addition to the above list, the Deprecation

deprecation link relation is returned in the Registration Data Access Protocol (RDAP) notices to indicate
"deprecation" link relation type
relation type deprecation
deprecation link relation type

resource documentation
resource's documentation

deprecation information
deprecation-related information
-->

<!-- [rfced] We see inconsistent use of jCard <tt> in favor of JSContact. RDAP this document. Please review
the specific questions below. Note: In the html and pdf outputs, the text
enclosed in <tt> is specified output in the Internet Draft for Using JSContact fixed-width font; in Registration Data Access Protocol (RDAP) JSON Responses https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/.</t>
      </section>
      <section anchor="implementing-the-concept">
        <name>Implementing the Concept</name>
        <t>This is a list of implementations that implement txt output, there
are no changes to the general concept, but do so using different mechanisms:</t>
        <t>Organization: Zapier</t>
        <ul spacing="normal">
          <li>
            <t>Description: Zapier uses two custom HTTP font.

a) For header fields named <tt>X-API-Deprecation-Date</tt> fields, we see use of both <tt> and <tt>X-API-Deprecation-Info</tt></t>
          </li>
          <li>
            <t>Reference:  https://zapier.com/engineering/api-geriatrics/</t>
          </li>
        </ul>
        <t>Organization: IBM</t>
        <ul spacing="normal">
          <li>
            <t>Description: IBM uses a custom HTTP no <tt>. See examples
below. Which form do you prefer?

<tt>Deprecation</tt> header field named <tt>Deprecated</tt></t>
          </li>
          <li>
            <t>Reference: https://www.ibm.com/support/knowledgecenter/en/SS42VS_7.3.1/com.ibm.qradar.doc/c_rest_api_getting_started.html</t>
          </li>
        </ul>
        <t>Organization: Ultipro</t>
        <ul spacing="normal">
          <li>
            <t>Description: Ultipro uses the HTTP <tt>Warning</tt>
Deprecation header field as described in Section 5.5 of RFC 9111 with code <tt>299</tt></t>
          </li>
          <li>
            <t>Reference:  https://connect.ultipro.com/api-deprecation</t>
          </li>
        </ul>
        <t>Organization: Clearbit</t>
        <ul spacing="normal">
          <li>
            <t>Description: Clearbit uses a custom HTTP

<tt>Link</tt> header field named <tt>X-API-Warn</tt></t>
          </li>
          <li>
            <t>Reference: https://blog.clearbit.com/dealing-with-deprecation/</t>
          </li>
        </ul>
        <t>Organization: PayPal</t>
        <ul spacing="normal">
          <li>
            <t>Description: PayPal uses a custom
Link header field

<tt>Sunset</tt> header field
Sunset HTTP header field named <tt>PayPal-Deprecated</tt></t>
          </li>
          <li>
            <t>Reference: https://github.com/paypal/api-standards/blob/master/api-style-guide.md#runtime</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="changes">
      <name>Changes from Draft-08</name>
      <t>This revision has made

b) For the following changes:</t>
      <ul spacing="normal">
        <li>
          <t>Addresses comments from Gen-ART, ARTART, SECDIR</t>
        </li>
      </ul>
    </section>
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Nikhil Kolekar, Darrel Miller, Mark Nottingham, and Roberto Polli for their contributions.</t>
      <t>The authors take all responsibility for errors link relation type, we see use of <tt>, quotation marks, and omissions.</t>
    </section>
  </back> no
<tt> or quotation marks.  Which form do you prefer?

<tt>deprecation</tt> link relation type
"deprecation" link relation
deprecation link relation
-->

<!-- ##markdown-source:
H4sIAAAAAAAAA71c63bbtpb+r6fAOD/qnCXJsZO2sdrTU9dOGvfk4mM77bms
rgQiIQkxRWoA0ora1XeZZ5knm29vACRIUXbaMzNZiS2RILCxr9/eG8xoNBok
Rarz+URU5Wz0dCCnU6NuJ4NSl5maiOuFEmdqZVQiS13k4sX19YV4oWSqjHiu
VZYO0iLJ5RJDUyNn5UgrTLMoy5Vc6VHaPDla8EOjTJbKlgNcVPPCbCbClulg
oFdmIkpT2fLo0aPjR0cDaZSciJ/UVMg8Fed5qUyuSnFtZG5XhSkH68LczE1R
rSZM08nF+eBGbXA1dReGIlp8MLAl5nknsyIHpRtlBys9Ef8qi2Qo8EPnqcrL
obCY2aiZxafN0n8ojU5wKymWK+k/LDEYt3Se6Vz9PBjcqrxSk4EQHYKEKDcr
rPcTaAWLxfd0G1cXBfGLmGQnBwfMsfU8MG081+Wimo51cYChS6kzNxS3vqWh
48LMccOoVdHM4Z8Bbd3pDrZlMBjIqlwUhige4Z/ATuxEXI3FmcxkxlecSK9k
/kFuosvK0WP5+jil698mMhtPlblRmdqMVVrxwMroXupsKku7qvKj9trPxuIn
naUqWvuZ0TfRRb+ywtXxmq5+mxpVjqEU7fWwXLhxgH/0eTDIC7MEB25ZSCSd
ibh8fnp8ePgI31+ev/4rf3969PQpvl9dX749vX57+exs9Pz82cuzq4k4H52N
a8WeajuyM/wcQG/zWTP1YDAajYScQmWgKYNBr+0YBf3NrRJOFmJGRiS0FZVV
KXRRWD3PZUafEoyrlspYUcyEpCeLyiRK7OtclJjbKpoH995enj/EFVny5Xoc
2JSJKUYYsZAWn1ReG4VKx+IkTTURJrNsM+RHI10R0O0bzJW5b4nMaapAJN/E
74gqXn9liludKitkPbeoeYRp5LSoMCqTeY6JQJj6qG1JthEtPWSbXxXW6mm2
EWu5sZhErBc6WYgk07A+IVerTHtKU3WrsmJFjHJk2hJ2k8t5a0NjL5+lTtNM
4cvgAfkVU6RV4nxELCvieCMxz/dff71SPFY8Hh/SELr/228P2SdUOdGjbM9+
ibWZnqlkk2SqLcyxOC+FyhN8Ab22Z3uW+LzUc4PJhQQzxMwUy5ak4eu0rado
PctjiR7ica7WxBFF3i7RGFrknXmI8Y7+zjzNRoy2N7QHaCcEV0GM9ZTQj1Vn
yrEzA9gDPRPrV1qAgLwoRbKQOUQl8w1Et5C3GmqBsa1ZiEuBrj4W+fEzWocV
UfaaAcwsNoDfYaAd/cfmb9UGS+mOvEthKvBlqXA5ZfLA9/VC5Vv2FciCZqsZ
dKMEq87z2nBolbJDX0zRsG3r3vAME1qRW8Bt03rCClvBgOAJXpL17v+LHN/P
D6Pt7DBadgJu37E9gX06WFxrfFgG2zaKnpqBF5B3UlHg3Jqzw5ghngMbY4Zj
LpIn3EailhyoSU+ZqzISaMONqYJFsnrlI3IM0u2KXMCDB0K8Lkp/RZzSznNW
IqepABGCUIQVe6/eXl3vDd1v8foNf7589re35wgN9PnqxcnLl/WHgR9x9eLN
25dnzafmydM3r149e33mHsZV0bo02Ht18o89t7W9NxfX529en7zcE+zrSW89
+4R0PGWeAxVh8yWzaAC3mxg9VWTB4rvTi//+r8Mn4tdf/wOR7ejw8Pi33/yX
p4dfPsEXYp9brcjJy/JXyGIzgGUpaWgWRAYIYqVLmQHvQAx2UaxJDw0Z9p/+
RZz5eSK+niarwyff+Au04dbFwLPWRebZ9pWthx0Tey71LFNzs3W9w+k2vSf/
aH0PfI8ufv0XQnlidPj0L98MSEdiYUA9oShXQK5JWRmwnjGx+FFmFW7AJNin
7MHYtlCFszy7UomebYA3YRkfXeCTxpLXIH9JPv+WJ/OOFBJfir2g6Hvk0fqU
AVYBo3OqsCNqjSkA9nrAy+ABWzifl38fDX5/l7+E5hRrMlurzC2uspOpg6SD
Dj2hfBvEYAMUadTHMjh5GLal2I6tg7/BjUZ+nY38ihnaR3U/wcF67Jaj7sQi
oSlX0HgKLgjANtx0c2qQmSSVMf4uyN+3SkVC+GL8ZHwUgQeObc4Bb69NCjD0
yGcpNz5ecKirSOHEfou0wKltpgjpAyPN+JBjoZtnJYGW+mfpAY3tacDpNmsh
Erjt81ItRWQTsRp9BQ5Zp9KCnQWolEgwCNtYAVfdUtfH4y+JU1u2w9rLop0V
pGhkLuqjXK4Ar8hF2R5FumtXWOy50akEDP6hgrE/fjQUR4+OHtN2jx5PPj/G
X/H2+hQYn5KNaM8T8e3hF0+fHn5x/Pnx8cDFl6sEMWcb/rftg5Re2RD//q+U
awhrkTmxhxmCCYC8iwpQzelatYJVduC3U3iMdr5JJxEMe1GsAbYNBwpon1dJ
m6hcGl3UIZ+SE2JCsJ2waNpaB9qSSTMn7wAIKD4g+3ePgqAszmN4Us2eAoGJ
XOGlv2c5HM6MUg6dkNPz+APz54lRkgAEE+OCXWUryndcUHVE1tbivToemG7a
YrGFY0krJWuNuMmLdYSSO2vz0g7SAOESHk6AMWifG2S+BGTSgsRgiyFtlFDl
ksocEv6RVETesIcv+MEq90bIG22vRJMwJr3VlD0pjkEN1etFwRyrcmQSppbP
9hymyhBzHMQjFWosyqp4PmIdgfgp5ya7ZvS8J3TRPFJHrLZSREAy1QDGhmIE
pzHkObiOI01a6/W+Hqvx0GtHr0kRvCFX9Zaj6g7lwMREFyn0kpjNufXQRdJ+
4ij8EHCSAnZIdrVBbuYSFdxZ9eDo0uNazy+fNpH3cezpS2zgzSoOp5wFk/sn
J+e1lJJiufGi4YhLO18y5Ia5+TSjXJBSnvVvAwR3GBFTTOxYqGx1T9aN9WCw
Mo8TCGKKTz8D1jeN0eacv1QAlchsF13i6z02CWGzRVsPY0EppO88+xwgidCY
s8FmLc4FYhfHCOE51x44YhDzxcnFuSeFpEMJ1C7XzVkzAWNoOmlkvdJQTLEw
6wSzhws57X2HzIj0Eyt+ZrkUWDuebXu7Q/nkrdSZnBL9tC50AR7FIa25Ilc/
vEdq7IgwGl90QbkquUWdk9d3PqxD27nPRGq20RhEVKfEHZC2M/CtWZ/JXYCF
DWd8/lp7XnCHcU/mogl7M53pctM4mIYbbk7mPOX5eQ/1gz60y3nwZShxXW8o
at+TgjPk3c7DPcoNyTeVx2wTwPciMe51CmtUIe5Bx/TYXeLrJNfLwrRZ4qyg
B8Z6OUXZ+4LCKkWmWeFjtwRwgwm3kvJgb7I16aoAaRtXfgIDnDrCtOQMvr2b
1bsiSAMb2hWBJnbuLgW2n8COFuQ1ilDt0+XYJ2gBungqqXBA1QBSOK7nu6JR
KFVhORvP6up1+U0Hr7jNsiEgRyt1UgG+bBdOPU/8JmszJbtfVKB0BHeb8pXO
dgwNWcoErlNFgzgxWYUSJvDlWfyYw5mryoBJdfRto/JupZls3plbHby2tKUb
REPIH4u3Ky7fJGoVs2v3isP7dZm0MCuKG8DR1qqf2Q6LYifnikoRySHMtKIb
Mac9B1L+aPvzin8TONFLxZn+znJrX6WJE1mqq4Yr+/ahL1U51N37GPDKLPAC
MnZk9tfyGlJDzb0ll/beKoY4Urwnz9YRPHujttt5n8ZCq8s7U4hl7VMdmmgi
vg6dnFpmYx8FuKkTTfPNV/yY+4PV/tzyfV/xun/eIw90sCiX2R473DisxMbH
vir/1K7CXTl75PU4l2BnsDNG6bqGzXlXAK+V7eRqrn69v1Hlw1ZdOc6SmuEy
I5veYKNkqjZI1Gc3O4J7qEuQXMnZdfIn5/hSRvntgrlDEs4HlVtGABoyqRlA
V3nK4YSbK9pgFGFsj9Kc1rib7NcIYMc0OMzE+Ql72bFoI6vYG/qKuNqGNq2W
CFkQJwkN6HU9MVVLBkBBO4vyrh3zAYAif3wtUnpGkjyDFoR2U7ewEnKS3EGH
mH9MQ0AqsWjfmLv2dM/jUC9jy86y8fZk3J8QzKT2Rvscmt5GLDvCkcxs7Pqd
l6MxzgtCarVWdNuPLU0OUdd7yV4fSNGMcDI17mlQfC+CGl2ZjMVVFXRtw5xq
b7bmKuxrQ1hrVm33SlvEUrTLiBRWCZox0A00DpZazIAsfFc5iSu8DPHk0jmm
TnQj8M2MbSorclvVgmfe5XPuqyz9//ji7/WtioqwW7vgykJdNhzGvrrdMPK8
5/yR0gwuuFWrNPR8kH1nVdoHWbcBYJBII2Iq9XjEef8MLHKvsXFrWPuk4KqC
iy97gf896IKjeH8Xbi0p+40ahTsR/RazY3TBYZHyMcc119aCx/aRSVMliXqd
daVuVRCcIxkBzTj5uP1tJy6hG/T5MXWD4nZbj0PZDe9CXwLrIW4sV2LOOuTV
5L1bvQNFQpeIVlTSgCm+BEiPFIBg7Tl2ry3OfanS5TCu42KJR1TS4PqJz7iX
pC/5TM8rU4cccDwrNlxn6DoN572UMYX5BPzqG1KsoFmn7NyM8ol5gqShTk12
up1dVeyoHdJXyIaXwaBPqmW7Xj+V1JyCBAOHxLYeftJ9eCwuKN4qAkA+9hHr
gTnKwlApoRbAnSpYORzU1PlAhBTOwHhCDgmf4BrdChP6PQTRRLyjOyaarD0U
jsV3vrL0v3Q+gZMwTiMTf8LjLnTZVPTdElTxKaPDPzIs6k0gFDuxcl3Ya58J
8gO9buzymq7ISRWKrlLVEY4yHlehorQ+jWN1U5BnnEKKHKEq13gT5yevT6ir
bskPSt9Yf/Dvdhr7e3a+OEpZdpo2hwn2XiCwGbYRPi8I3RIXpiiLpMjEPi38
0PdpX9OOL9Ucams2e1jFfYpP+hx+MW4f9nHaGBPM00zi3bkxUQvsms8BUmMs
3JJlZSdUe0M4gub7y62yRUA+E9+siG8Oo9Du/gSCj8Tep/N6z7esPqUyxlJp
ZYw9lawdIqn32fAYHN1+3sas960sOqZCfVLHopoox/S0y/SzplwyweCZ1/zu
QTXdLS3sUzuCK5nsyKhQ422H53q4A1xE1aLPbJ1m/nvSrPuf25LclsueAzEq
qQxVR7uWd2cTshFWCXddhpM2VBLqNA67eW90uGmf4gg5sXklYW2lUnzkifLG
BFaIfKLcPKzbj7sPY51t4x/beLvgkhz+Z0wZOhvwuWm31tLd6lAoh2yLar5g
iOES18Szi08KhcW49AnCswg+yBu/xJJA3hwUEvpC+pbhEx3gotQ4L92+syKn
rmbttPg82KzJi6MGZkcLvUTqHO2uescWUg7EOnDNXTzlTiunPIJSL6IiOklF
bK8bAnSor6cF5awgcLjWAg96fJKeLFRy4wfA5kyMYttbhDECt9OZFzqFTN3u
hBSXtEhSc1v6EmsiCRy46kh/RSs6NBsY1lpqyIIOHTRLYVDsVzlLjAv2qeAU
gtzjVXSANpSdQmmzZ2lKbHwbz5LpAWuvjL4lCMVHK0o1J3Mc1TaRuiJSWmF6
7DuSNWHgj8okmrbCRXKXK1IDp93c/7zxhixHLvp7Td1i2Z1NGHf+oi+bu7tl
xMA9L4KCe57WjNsFj7zVGjrDHUENxq93VAL+0I6kB7LxKRluD3ORmUoAnH52
urJ8WnINEURNwLh47wuHROx9bbU7zYVTRt/OoJnuzRgoz62gr6uCVFKTI+D3
EFiT2gcyXauESh2kHGERuHZAoDqZk41PiEwUniEcj57K5MadjQ5NWDe5QyyD
wevCVXyQOopn8E6FmYRcAPItqKXI4c3rrBfwqppmccoTjSB66LglqwUvQupD
xynyphHsXVEo6AUwF065TTc9QVV4rWTvWzDbS3+ujgeHl0pGZ/Tiiq+sNeiB
+7ud9cNhzEA7W5CHDcRcsNyfYTl/dv2chlOCBaisLZfiTJG4JrXOmzBCrWmi
wHq22p7kymGMmn7KRSgEw+dVTiViUbG11OkL3dwI0FgY65vqm5rEsXheGdL9
JWs2TBuhrDBRcgmWutTEO+1u79X3zsAAb6SglvIDW/FxDJYNM4O8qtHTChoT
Dpb47KdmobTOSy7pJJA3QTIR4OhQAKGSMsQrs8Ixoq6Tb6kKF8Q1/AOQDXwA
1rxkh+GODMn0VvvYUXN54M5Md2ciX8+vKUBzT8K5nWACXx4/ORqKPdYKX7Sm
kwxG3Wq15sWoiO7f/+HXg2zQlHnuwkGM2NikfQyzobRxq7x3zaHuHJZMlecu
uUtbxwM5qpFfVRQNfSpKrpFZRKUko6OOK0ibITSRyUdrLcElJ+boqEkwOeui
zpJ5Gk67UNuu8JpRK+X2pl3e2T0x74EdhTrsbs+d3qydT/CjrXSmkyw6TZJs
IH1W67BnfabkLpw4GQzemDmA7y++0HCyotIMXGM7sdid3NOBEPAmD8E8rv7X
+JIAz36cRPtw9b2Rq8XfXgoLOLWUD3lbXKNWKSjgbIak2rxZtV6vx/lq+cFy
7ReB4UbO1YFkokfuUMKoLCC27r7+KREo0t+7sSZy+EMsqxrtUd2gc4yBztS0
D7CEZf0tsgE77t9ZQfU8V1z5xT3EW6QG/qzKRvR2IXctqGVrDx608sD2Vi/o
8RKe4Foli7yA59DK/q6NA1AXZlUYXwBmsxNzmKO7Ag8HI/4Agxh9gEMiF3X6
8tzV+9wY8QOui4s3P7yx/hUbhJ4Zd664u3zqHvdsQUzTLn3r5Uz0Nt3Kb+0g
Xr+7f/Fs9GOxgV5UcEdtHvzpj/PgBZIbeJOUzj1J0a6tugq7MzYon0fnrtmI
rMlYer+NyjMzPt+jYJoul2QEYwj7lNRoVJT9sAMwnLdJcfkMAJS4RAVasVZT
gLAxtnE3m255+3Zk82Q2KiMOHCzqXRxMs2J6sAQQVuaglUYcZAQJ14p+jqRJ
FhpTkPsbhcA+8hjmoDH2dzATLsbb8TLtSuQNdHv0d1fi+11CCOX5eALCobYC
TSP3ZhudwryXI2Rdo49ugoO+CToUv4Io5E/6Rm+Re0rhoBHLrBnqUf9dZ+lc
Uhw4FcWgbl17it80keszhieagwF1ToH5pqqkw0ctb7tDR1YLOaVyNTDJeA2S
l0Q7vWB7cH30+OjJ089720JIv28dHBtuxaZ2SSuOBt7F+2qju39G5e4T9vBR
hfLy7OTiIcESnbjjrHWTuVN5+nBKJ2Ex8Uzeuqzrhyu4khL5AdAOZhENJm4o
qF+mZtzLInBHY+uHaeQn0/nD1ZvXdXHR1qylSj69B3ujzDi8tkx2dRC9Jm7U
HF5gZFK5Gn2g/gwtfuBPOW1BABBHh47+YMR3rjgjT0WzuL4tIpEtfL7dNCGW
igxD26XdggP/RNyhF6g7wcNd9r3iNaIgACzc+lbDw/K7zal4//cRrGUUKc6I
XoF4zw6w5+Y5ANP7djSoGf0Lr81WrfI5oiH8WT4/4ACJj5LOu9mD7kbOv3u1
tQtcCx2ZXRsI9DfFuve7gYmeLt0730gFkFMcUE6XqXSuEsKUBuQeXF09Ofrx
6t2XVGNHEFvyM/9pZCrNmJQleUcB/x02824Os8bG3iFHNFQwpJZ1d1dvs1LD
J2ztzF9vmvm8sfc/SUMwulPbYVwWvUpXl1/GXIAh1H98eHjoS5wEBd4fHR/v
Eg/0LaeXOytHAjOk818jdHdxiuzPTHW5tY1w41Ol5BSJdrlDSoh583HiZ/XH
B+Av8/mINhfTuKVAF3IDYLVForv8qQS60aN7takFeTZAPczC8C5AO3a7O5tM
OXyI8PvAv5LLZY1Tjnked7EHHD16Kn594GKh/c27F0rgOGdfcPXXZ0RNn9YP
n1A8PElT49L68H9DuNm/R4w9ubweCvzg31fPTs/OL5mMkyRYAz/g32Zy/y+D
9ZEz0zf+LLBEUHmtbxY6E38tMnVDx07PJHB3Jl4h6aSjZq+kuaEXW8lGFnLp
EunLYgooVYgL0K3DITFtmlycvOW4vTaf5fKHs/mQgT93zaGaGuIOwhZLba17
/H8A6nojkkVEAAA= [rfced] Please review each artwork element in the xml file. Specifically,
should any artwork element be tagged as sourcecode or another element?
-->

<!-- [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 this nature typically
result in more precise language, which is helpful for readers.

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

</rfc>