<?xml version='1.0' 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.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 Response Header Field</title> <seriesInfoname="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> <dateyear="2024" month="October" day="09"/> <area>Web and Internet Transport</area> <workgroup>HTTPAPI</workgroup> <keyword>HTTP, deprecation</keyword> <abstract> <?line 44?> <t>Theyear="2025" month="March"/> <area>WIT</area> <workgroup>httpapi</workgroup> <keyword>HTTP</keyword> <keyword>deprecation</keyword> <abstract><t>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. Additionally, thedeprecation<tt>deprecation</tt> link relation can be used to link to a resource that providesadditionalfurther information about planned or existingdeprecation, and possiblydeprecation. It may also provide ways in which client application developers can best manage deprecation.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpapi-deprecation-header/"/>. </t> <t> Discussion of this document takes place on the HTTPAPI 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/"/>. Working Group information can be found at <eref target="https://ietf-wg-httpapi.github.io/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/ietf-wg-httpapi/deprecation-header"/>.</t> </note></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 orishas been deprecated. The Deprecation HTTP response header field can be used to convey this information at runtimeindicatingand indicate when the deprecation will be in effect.</t> <t>In addition to theDeprecation<tt>Deprecation</tt> header field, the resource provider can use other header fields such asLink (<xref target="LINK"/>)the <tt>Link</tt> 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> <sectionanchor="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 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 document uses"Structured Field Values for HTTP" (<xref target="STRUCTURED-FIELDS"/>)"<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 messageis orwill be or has been deprecated.</t> <section anchor="syntax"> <name>Syntax</name> <t>The <tt>Deprecation</tt> HTTP 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 in context will be deprecated at that date) or in the past (the resource in contexthas beenwas 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 in contexthas beenwas 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>TheDeprecation<tt>Deprecation</tt> 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 interpretdeprecationdeprecation-related informationdifferentdifferently from its standard meaning (i.e., it applies to the resource only).</t> <t>Using such an increased scope still may make sense, asdeprecationdeprecation-related 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 withoutDeprecationdeprecation-related information. Increased scope information may help client application developers to glean additional hints from related resourcesand, thus,and thus might allow them to implement behavior thatallowsenables them to make educated guesses about resources becoming deprecated.</t> <t>For example, an API might not useDeprecation<tt>Deprecation</tt> header fields on all of itsresources,resources but only on designated resources such as the API's home document. This means thatdeprecationdeprecation-related 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 theDeprecation<tt>Deprecation</tt> 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>TheDeprecation<tt>Deprecation</tt> Link Relation Type</name> <t>In addition to the Deprecation HTTP response header field, the server can use links with the"deprecation"<tt>deprecation</tt> 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 actualdeprecation,deprecation to make a deprecation policydiscoverable,discoverable or afterdeprecation,deprecation when there may be documentation about thedeprecation,deprecation andpossibly documentation ofhow 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 finddeprecation relateddeprecation-related information. The documentation <bcp14>MAY</bcp14> provide a guide and timelineto migratefor migrating away from the deprecated resource to a new resource(s)replacingthat replaces the deprecated resource, if applicable. The resource provider can provide a link to theresourceresource's 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> <t>In thisexampleexample, the linked content provides additional information about deprecation of the resource in context. There is noDeprecation<tt>Deprecation</tt> header field in theresponse, and thusresponse; thus, the resource is not (yet) deprecated. However, the resource already exposes a link where informationis availabledescribing how deprecation is managed for theresource.resource is available. This may be the documentation explainingunder whichthe circumstancesand within whichpoliciesdeprecation might takeplace.place and the deprecation policies. 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 thenonlythe resource(s) would bedeprecated.deprecated on the planned date. Or a policy may indicate that the resource(s) would be deprecated first and thenonlybe signaled as deprecated at dedicated places. Thedocumentationdocumentation, in addition to the deprecationpolicypolicy, may also provide a migration guideexaplainingexplaining to consumers of the resource how to migrate to a newresource(s)oranalternate 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 samelink<tt>Link</tt> headerfield,field but also announces a deprecation date using aDeprecation<tt>Deprecation</tt> 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 thedeprecation relateddeprecation-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, theSunset<tt>Sunset</tt> 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> HTTP header field <bcp14>MUST NOT</bcp14> be earlier than the one given in the <tt>Deprecation</tt> header field. If that happensfor some reasons such as(for example, due to misconfiguration of deployment of the resource or anerror,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 contexthas beenwas deprecatedsinceon 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 theSunset<tt>Sunset</tt> 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> <t>The act of deprecation does not change any behavior of the resource. The presence of aDeprecation<tt>Deprecation</tt> header field in a response is not meant to signal a change in the meaning or function of a resource in thecontext, allowingcontext; consumerstocan 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> HTTP response header fieldshould behas 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 "Thetarget="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 HeaderField" ]]></artwork>Field</dd> </dl> </section> <section anchor="the-deprecation-link-relation-type-1"> <name>TheDeprecation<tt>Deprecation</tt> Link Relation Type</name> <t>The <tt>deprecation</tt> link relation typeshould behas been added to thepermanent"Link Relation Types" registryof link relation types(<xref section="4.2" sectionFormat="of"target="LINK"/>).</t> <artwork><![CDATA[ Relation Name: deprecation Description: Referstarget="RFC8288"/>) as follows:</t> <dl newline="false"> <dt>Relation Name:</dt><dd>deprecation</dd> <dt>Description:</dt><dd>Refers toa resource that isdocumentation (intended for human consumption) about the deprecation of the link'scontext. Specification document: this specification, Section 3 "The Deprecation Link Relation Type" ]]></artwork>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> <t>TheDeprecation<tt>Deprecation</tt> header field should be treated as a hint, meaning that the resource is indicating(and(but not guaranteeing with certainty) that it will be orishas been deprecated. Deprecated resources function as they would have without sending thedeprecation<tt>Deprecation</tt> header field, even thoughone might considernon-functional detailssuch as making them progressivelymay be affected (e.g., they have lessefficient withefficiency and longer responsetime for example.</t> <t>Resourcetimes).</t> <t>The resource's documentation should provide additional information about the deprecation, such asincluding recommendation(s)recommendations for replacement. Developers of client applications consuming the resource <bcp14>SHOULD</bcp14> always check the referredresourceresource's 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,privateprivate, or integrity-guaranteed,andso due caution should be exercised when usingit, seeit (see <xref section="5" sectionFormat="of"target="LINK"/>target="RFC8288"/> for moredetails.details). In cases where theDeprecation<tt>Deprecation</tt> header field value is in the past, the client application developers <bcp14>MUST</bcp14> no longer assume that the behavior of the resourcewouldwill remain the same as before the deprecation date. In cases where theDeprecation<tt>Deprecation</tt> header field value is a date in the future, itcan lead to information that otherwise might not be available.informs client application developers about the effective date in the future for deprecation. 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> <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t> <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> </abstract> </front> <seriesInfo name="STD" value="97"/> <seriesInfo name="RFC" value="9110"/> <seriesInfo name="DOI" value="10.17487/RFC9110"/> </reference> <reference anchor="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 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> <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 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 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 of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage 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 is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.</t> </abstract> </front> <seriesInfo name="RFC" value="8594"/> <seriesInfo name="DOI" value="10.17487/RFC8594"/> </reference><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><?line 192?><sectionanchor="implementation-status"> <name>Implementation Status</name> <t>Note to RFC Editor: Please remove this section before publication.</t> <t>This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing 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, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.</t> <t>According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".</t> <section anchor="implementing-the-deprecation-header-field"> <name>Implementing the Deprecation Header Field</name> <t>This is a list of implementations that implement the deprecation header field:</t> <t>Organization: Apollo</t> <ul spacing="normal"> <li> <t>Description: Deprecation 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 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 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 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 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 link relation is returned in the Registration Data Access Protocol (RDAP) notices to indicate deprecation of jCard in favor of JSContact. RDAP is specified in the Internet Draft for Using JSContact 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 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 header fields named <tt>X-API-Deprecation-Date</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 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> 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 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 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 the following changes:</t> <ul spacing="normal"> <li> <t>Addresses comments from Gen-ART, ARTART, SECDIR</t> </li> </ul> </section> <section anchor="acknowledgments">anchor="acknowledgments" numbered="false"> <name>Acknowledgments</name> <t>The authors would like to thankNikhil Kolekar, Darrel Miller, Mark Nottingham,<contact fullname="Nikhil Kolekar"/>, <contact fullname="Darrel Miller"/>, <contact fullname="Mark Nottingham"/>, andRoberto Polli<contact fullname="Roberto Polli"/> for their contributions.</t> <t>The authors take all responsibility for errors and omissions.</t> </section> </back><!-- ##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= --></rfc>