Diff: rfc9745.original.xml

	rfc9745.original.xml	rfc9745.xml
	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='utf-8'?>


	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.0.	-ietf-httpapi-deprecation-header-latest" number="9745" updates="" obsoletes="" s
	2) -->	ubmissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs=
	<?rfc tocindent="yes"?>	"true" symRefs="true" version="3" xml:lang="en">
	<?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" category="std" consensus="true" tocIncl
	ude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.23.2 -->
	<front>	<front>
	<title>The Deprecation HTTP Header Field</title>	<title>The Deprecation HTTP Header Field</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-deprecation-head er-latest"/>	<seriesInfo name="RFC" value="9745"/>
	<author initials="S." surname="Dalal" fullname="Sanjay Dalal">	<author initials="S." surname="Dalal" fullname="Sanjay Dalal">

	<organization/>
	<address>	<address>
	<email>sanjay.dalal@cal.berkeley.edu</email>	<email>sanjay.dalal@cal.berkeley.edu</email>
	<uri>https://github.com/sdatspun2</uri>	<uri>https://github.com/sdatspun2</uri>
	</address>	</address>
	</author>	</author>
	<author initials="E." surname="Wilde" fullname="Erik Wilde">	<author initials="E." surname="Wilde" fullname="Erik Wilde">

	<organization/>
	<address>	<address>
	<email>erik.wilde@dret.net</email>	<email>erik.wilde@dret.net</email>
	<uri>http://dret.net/netdret</uri>	<uri>http://dret.net/netdret</uri>
	</address>	</address>
	</author>	</author>

	<date year="2024" month="October" day="09"/>	<date year="2025" month="March"/>
	<area>Web and Internet Transport</area>	<area>WIT</area>
	<workgroup>HTTPAPI</workgroup>	<workgroup>httpapi</workgroup>
	<keyword>HTTP, deprecation</keyword>	<keyword>HTTP</keyword>
	<abstract>	<keyword>deprecation</keyword>
	<?line 44?>


	<t>The Deprecation HTTP response header field is used to signal to consumers of	<!-- [rfced] Please clarify "(in the sense of URI)" here. Also note that we do
	a resource (in the sense of URI) that the resource will be or has been deprecate	not see "URI" used elsewhere in the document.
	d. Additionally, the deprecation link relation can be used to link to a resource
	that provides additional information about planned or existing deprecation, and	Original:
	possibly ways in which client application developers can best manage deprecatio	The Deprecation HTTP response header field is used to signal to
	n.</t>	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.

		Perhaps:
		Additionally, the deprecation link
		relation can be used to link to a resource that provides further
		information about planned or existing deprecation. It may also provide ways
		in which client application developers can best manage deprecation.
		-->

		<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, 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>	</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.or
	g"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/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>	</front>
	<middle>	<middle>

	<?line 49?>

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

	<t>Deprecation of an HTTP resource (<xref section="3.1" sectionFormat="of"
	target="HTTP"/>) communicates information about the lifecycle of a resource. It	<t>Deprecation of an HTTP resource (<xref section="3.1" sectionFormat="of"
	encourages client applications to migrate away from the resource, discourages a	target="RFC9110"/>) communicates information about the lifecycle of a resource.
	pplications from forming new dependencies on the resource, and informs applicati	It encourages client applications to migrate away from the resource, discourage
	ons about the risk of continued dependence upon the resource.</t>	s applications from forming new dependencies on the resource, and informs applic
	<t>The act of deprecation does not change any behavior of the resource. It	ations about the risk of continued dependence upon the resource.</t>
	informs client applications of the fact that a resource will be or is deprecate	<t>The act of deprecation does not change any behavior of the resource. It
	d. The Deprecation HTTP response header field can be used to convey this informa	informs client applications of the fact that a resource will be or has been dep
	tion at runtime indicating when the deprecation will be in effect.</t>	recated. The Deprecation HTTP response header field can be used to convey this i
	<t>In addition to the Deprecation header field, the resource provider can	nformation at runtime and indicates when the deprecation will be in effect.</t>
	use other header fields such as Link (<xref target="LINK"/>) to convey additiona	<t>In addition to the Deprecation header field, the resource provider can
	l information related to deprecation. This can be information such as where to f	use other header fields such as the Link header field <xref target="RFC8288"/> t
	ind documentation related to the deprecation, what can be used as a replacement,	o convey additional information related to deprecation. This can be information
	and when a deprecated resource becomes non-operational.</t>	such as where to find documentation related to the deprecation, what can be used
	<section anchor="notational-conventions">	as a replacement, and when a deprecated resource becomes non-operational.</t>
		<section anchor="requirements-language">
	<name>Notational Conventions</name>	<name>Notational Conventions</name>

	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
	nterpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
	only when, they
	appear in all capitals, as shown here.</t>
	<?line -18?>


	<t>This document uses "Structured Field Values for HTTP" (<xref target="STRUCTUR	<t>
	ED-FIELDS"/>) to specify syntax and parsing of date values.</t>	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	<t>The term "resource" is to be interpreted as defined in <xref section=	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	"3.1" sectionFormat="of" target="HTTP"/>.</t>	",
		"<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 <xref target="RFC2119"/> <xref
		target="RFC8174"/> when, and only when, they appear in all capitals, as
		shown 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"
		([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="RFC9110"/>.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="the-deprecation-http-response-header-field">	<section anchor="the-deprecation-http-response-header-field">
	<name>The Deprecation HTTP Response Header Field</name>	<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 context of the message is or will be deprecated.</t>	<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 mess age will be or has been deprecated.</t>
	<section anchor="syntax">	<section anchor="syntax">
	<name>Syntax</name>	<name>Syntax</name>

	<t>The <tt>Deprecation</tt> response header field describes the deprecat	<t>The <tt>Deprecation</tt> response header field describes the deprecat
	ion of the resource identified with the response it occurred within (see <xref s	ion of the resource identified with the response it occurred within (see <xref s
	ection="6.4.2" sectionFormat="of" target="HTTP"/>). It conveys the deprecation d	ection="6.4.2" sectionFormat="of" target="RFC9110"/>). It conveys the deprecatio
	ate, which may be in the future (the resource context will be deprecated at that	n date, which may be in the future (the resource context will be deprecated at t
	date) or in the past (the resource context has been deprecated at that date).</	hat date) or in the past (the resource context was deprecated at that date).</t>
	t>
	<t><tt>Deprecation</tt> is an Item Structured Header Field; its value <b	<t><tt>Deprecation</tt> is an Item Structured Header Field; its value <b
	cp14>MUST</bcp14> be a Date as per <xref section="3.3.7" sectionFormat="of" targ	cp14>MUST</bcp14> be a Date as per <xref section="3.3.7" sectionFormat="of" targ
	et="STRUCTURED-FIELDS"/>.</t>	et="RFC9651"/>.</t>
	<t>The following example shows that the resource context has been deprec	<t>The following example shows that the resource context was deprecated
	ated on Friday, June 30, 2023 at 23:59:59 UTC:</t>	on Friday, June 30, 2023 at 23:59:59 UTC:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	Deprecation: @1688169599	Deprecation: @1688169599
	]]></artwork>	]]></artwork>
	</section>	</section>
	<section anchor="scope">	<section anchor="scope">
	<name>Scope</name>	<name>Scope</name>

	<t>The Deprecation header field applies to the resource identified with	<t>The Deprecation header field applies to the resource identified with
	the response it occurred within (see <xref section="6.4.2" sectionFormat="of" ta	the response it occurred within (see <xref section="6.4.2" sectionFormat="of" ta
	rget="HTTP"/>), meaning that it announces the upcoming deprecation of that speci	rget="RFC9110"/>), meaning that it announces the upcoming deprecation of that sp
	fic resource. However, there may be scenarios where the scope of the announced d	ecific resource. However, there may be scenarios where the scope of the announce
	eprecation is larger than just the single resource where it appears.</t>	d deprecation is larger than just the single resource where it appears.</t>
	<t>Resources are free to define such an increased scope, and usually thi	<t>Resources are free to define such an increased scope, and usually thi
	s scope will be documented by the resource so that consumers of the resource kno	s scope will be documented by the resource so that consumers of the resource kno
	w about the increased scope and can behave accordingly. When doing so, it is imp	w about the increased scope and can behave accordingly. When doing so, it is imp
	ortant to take into account that such increased scoping is invisible for consume	ortant to take into account that such increased scoping is invisible for consume
	rs who are unaware of the increased scoping rules. This means that these consume	rs who are unaware of the increased scoping rules. This means that these consume
	rs will not be aware of the increased scope, and they will not interpret depreca	rs will not be aware of the increased scope, and they will not interpret depreca
	tion information different from its standard meaning (i.e., it applies to the re	tion information differently from its standard meaning (i.e., it applies to the
	source only).</t>	resource only).</t>
	<t>Using such an increased scope still may make sense, as deprecation in
	formation is only a hint anyway. It is optional information that cannot be depen	<t>Using such an increased scope still may make sense, as deprecation inf
	ded on, and client applications should always be implemented in ways that allow	ormation is only a hint anyway. It is optional information that cannot be depend
	them to function without Deprecation information. Increased scope information ma	ed on, and client applications should always be implemented in ways that allow t
	y help client application developers to glean additional hints from related reso	hem to function without deprecation information. Increased scope information may
	urces and, thus, might allow them to implement behavior that allows them to make	help client application developers to glean additional hints from related resou
	educated guesses about resources becoming deprecated.</t>	rces and thus might allow them to implement behavior that enables them to make e
	<t>For example, an API might not use Deprecation header fields on all of	ducated guesses about resources becoming deprecated.</t>
	its resources, but only on designated resources such as the API's home document	<t>For example, an API might not use Deprecation header fields on all of
	. This means that deprecation information is available, but in order to get it,	its resources but only on designated resources such as the API's home document.
	client application developers have to periodically inspect the home document. In	This means that deprecation information is available, but in order to get it, c
	this example, the extended context of the Deprecation header field would be all	lient application developers have to periodically inspect the home document. In
	resources provided by the API, while the visibility of the information would on	this example, the extended context of the Deprecation header field would be all
	ly be on the home document.</t>	resources provided by the API, while the visibility of the information would onl
		y be on the home document.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="the-deprecation-link-relation-type">	<section anchor="the-deprecation-link-relation-type">
	<name>The Deprecation Link Relation Type</name>	<name>The Deprecation Link Relation Type</name>

	<t>In addition to the Deprecation HTTP header field, the server can use li
	nks with the "deprecation" link relation type to communicate to the client appli	<!-- [rfced] May we we update the text starting with "and possibly..." as
	cation developer where to find more information about deprecation of the context	follows to improve the flow of the sentence?
	. This can happen before the actual deprecation, to make a deprecation policy di
	scoverable, or after deprecation, when there may be documentation about the depr	Original:
	ecation, and possibly documentation of how to manage it.</t>	This can happen before the actual
	<t>This specification places no restrictions on the representation of the	deprecation, to make a deprecation policy discoverable, or after
	linked deprecation policy. In particular, the deprecation policy may be availabl	deprecation, when there may be documentation about the deprecation,
	e as human-readable documentation or as machine-readable description.</t>	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 wi
		th 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 to make a deprecation policy discovera
		ble or after deprecation when there may be documentation about the deprecation a
		nd 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 availabl
		e as human-readable documentation or as a machine-readable description.</t>
	<section anchor="documentation">	<section anchor="documentation">
	<name>Documentation</name>	<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>Depre cation</tt> header field, the client application developer can look up the resou rce's documentation in order to find deprecation related information. The docume ntation <bcp14>MAY</bcp14> provide a guide and timeline to migrate away from the deprecated resource to a new resource(s) replacing the deprecated resource, if applicable. The resource provider can provide a link to the resource documentati on using a <tt>Link</tt> header field with relation type <tt>deprecation</tt> as shown below:</t>	<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>Depre cation</tt> header field, the client application developer can look up the resou rce's documentation in order to find deprecation-related information. The docume ntation <bcp14>MAY</bcp14> provide a guide and timeline for migrating away from the deprecated resource to a new resource(s) that replaces the deprecated resour ce, if applicable. The resource provider can provide a link to the resource docu mentation using a <tt>Link</tt> header field with the relation type <tt>deprecat ion</tt> as shown below:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	Link: <https://developer.example.com/deprecation>;	Link: <https://developer.example.com/deprecation>;
	rel="deprecation"; type="text/html"	rel="deprecation"; type="text/html"
	]]></artwork>	]]></artwork>

	<t>In this example the linked content provides additional information ab
	out deprecation of the resource context. There is no Deprecation header field in	<!-- [rfced] Would it be helpful to update "under which circumstances and with
	the response, and thus the resource is not (yet) deprecated. However, the resou	which policies" for readability as follows?
	rce already exposes a link where information is available describing how depreca
	tion is managed for the resource. This may be the documentation explaining under	Original:
	which circumstances and with which policies deprecation might take place. For e	This may be the documentation explaining under which
	xample, a policy may indicate that deprecation of a resource(s) will always be s	circumstances and with which policies deprecation might take place.
	ignaled in the dedicated places at least N days ahead of the planned deprecation
	date and then only the resource(s) would be deprecated. Or a policy may indicat	Perhaps:
	e that resource(s) would be deprecated first and then only be signaled as deprec	This may be the documentation explaining the
	ated at dedicated places. The documentation in addition to the deprecation polic	circumstances in which deprecation might take place and the deprecation polic
	y may also provide a migration guide exaplaining to consumers of the resource ho	ies.
	w to migrate to a new resource(s) or an alternate resource(s) before the depreca	-->
	tion date. Such policy and documentation would be very useful to consumers of th
	e resource to plan ahead and migrate successfully.</t>	<t>In this example, the linked content provides additional information
	<t>The following example uses the same link header field, but also annou	about deprecation of the resource context. There is no Deprecation
	nces a deprecation date using a Deprecation header field:</t>	header field in the response; thus, the resource is not (yet)
		deprecated. However, the resource already exposes a link where
		information describing how deprecation is managed for the 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 the
		resource(s) would be deprecated on the planned date. Or a policy may ind
		icate that the
		resource(s) would be deprecated first and then be signaled as
		deprecated at dedicated places. The documentation, in addition to the
		deprecation policy, may also provide a migration guide explaining to
		consumers of the resource how to migrate to a new or 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 header field but also announ
		ces a deprecation date using a Deprecation header field:</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	Deprecation: @1688169599	Deprecation: @1688169599
	Link: <https://developer.example.com/deprecation>;	Link: <https://developer.example.com/deprecation>;
	rel="deprecation"; type="text/html"	rel="deprecation"; type="text/html"
	]]></artwork>	]]></artwork>
	<t>Given that the deprecation date is in the past, the linked informatio n resource may have been updated to include information about the deprecation, a llowing consumers to discover information about the deprecation and how to best manage it.</t>	<t>Given that the deprecation date is in the past, the linked informatio n resource may have been updated to include information about the deprecation, a llowing consumers to discover information about the deprecation and how to best manage it.</t>
	</section>	</section>
	</section>	</section>
	<section anchor="sunset">	<section anchor="sunset">
	<name>Sunset</name>	<name>Sunset</name>

	<t>In addition to the deprecation related information, if the resource pro	<t>In addition to the deprecation-related information, if the resource pro
	vider wants to convey to the client application that the deprecated resource is	vider 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 hea	expected to become unresponsive at a specific point in time, the Sunset HTTP hea
	der field <xref target="RFC8594"/> can be used in addition to the <tt>Deprecatio	der field <xref target="RFC8594"/> can be used in addition to the <tt>Deprecatio
	n</tt> header field.</t>	n</tt> header field.</t>
	<t>The timestamp given in the <tt>Sunset</tt> header field <bcp14>MUST NOT	<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.	</bcp14> be earlier than the one given in the <tt>Deprecation</tt> header field.
	If that happens for some reasons such as misconfiguration of deployment of the	If that happens (for example, due to misconfiguration of deployment of the reso
	resource or an error, the client application developer <bcp14>SHOULD</bcp14> con	urce or an error), the client application developer <bcp14>SHOULD</bcp14> consul
	sult the resource developer to get clarification.</t>	t the resource developer to get clarification.</t>
	<t>The following example shows that the resource in context has been depre	<t>The following example shows that the resource in context was deprecated
	cated since Friday, June 30, 2023 at 23:59:59 UTC and its sunset date is Sunday,	on Friday, June 30, 2023 at 23:59:59 UTC and its sunset date is Sunday, June 30
	June 30, 2024 at 23:59:59 UTC. Please note that for historical reasons the Suns	, 2024 at 23:59:59 UTC. Please note that for historical reasons the Sunset HTTP
	et HTTP header field uses a different data format for date.</t>	header field uses a different data format for date.</t>
	<artwork><![CDATA[	<artwork><![CDATA[
	Deprecation: @1688169599	Deprecation: @1688169599
	Sunset: Sun, 30 Jun 2024 23:59:59 UTC	Sunset: Sun, 30 Jun 2024 23:59:59 UTC
	]]></artwork>	]]></artwork>
	</section>	</section>
	<section anchor="resource-behavior">	<section anchor="resource-behavior">
	<name>Resource Behavior</name>	<name>Resource Behavior</name>

	<t>The act of deprecation does not change any behavior of the resource. Th
	e presence of a Deprecation header field in response is not meant to signal a ch	<!-- [rfced] How may we update "allowing consumers to still" to improve
	ange in the meaning or function of a resource in the context, allowing consumers	clarity?
	to still use the resource in the same way as they did before the resource was d
	eclared deprecated.</t>	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. Th
		e 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 consume
		rs to still use the resource in the same way as they did before the resource was
		declared deprecated.</t>
	</section>	</section>
	<section anchor="iana-considerations">	<section anchor="iana-considerations">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>
	<section anchor="the-deprecation-http-response-header-field-1">	<section anchor="the-deprecation-http-response-header-field-1">
	<name>The Deprecation HTTP Response Header Field</name>	<name>The Deprecation HTTP Response Header Field</name>

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

	<t>The <tt>deprecation</tt> link relation type should be added to the pe	<t>The <tt>deprecation</tt> link relation type has been added to the "Li
	rmanent registry of link relation types (<xref section="4.2" sectionFormat="of"	nk Relation Types" registry (<xref section="4.2" sectionFormat="of" target="RFC8
	target="LINK"/>).</t>	288"/>) as follows:</t>
	<artwork><![CDATA[
	Relation Name: deprecation


	Description: Refers to a resource that is documentation (intended for human cons	<!-- [rfced] Please review "resource that is documentation" here. Should this
	umption) about the deprecation of the link's context.	be updated to "resource documentation", "documentation", or something
		else?


	Specification document: this specification,	If any changes are made, we will ask IANA to update the "Link Relation Types"
	Section 3 "The Deprecation Link Relation Type"	accordingly prior to publication (link to registry:
	]]></artwork>	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.

		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 (in
		tended for human consumption) about the deprecation of the link's context.</dd>
		<dt>Reference:</dt><dd>RFC 9745, <xref target="the-deprecation-link-rel
		ation-type" format="default"/></dd>
		</dl>
	</section>	</section>
	</section>	</section>
	<section anchor="security-considerations">	<section anchor="security-considerations">
	<name>Security Considerations</name>	<name>Security Considerations</name>

	<t>The Deprecation header field should be treated as a hint, meaning that
	the resource is indicating (and not guaranteeing with certainty) that it will be	<!-- [rfced] How may we update the text starting with "even though one
	or is deprecated. Deprecated resources function as they would have without send	might..." to improve sentence clarity?
	ing the deprecation header field, even though one might consider non-functional
	details such as making them progressively less efficient with longer response ti	Original:
	me for example.</t>	Deprecated resources function as
	<t>Resource documentation should provide additional information about the	they would have without sending the deprecation header field, even
	deprecation, such as including recommendation(s) for replacement. Developers of	though one might consider non-functional details such as making them
	client applications consuming the resource <bcp14>SHOULD</bcp14> always check th	progressively less efficient with longer response time for example.
	e referred resource documentation to verify authenticity and accuracy. In cases
	where a <tt>Link</tt> header field is used to provide documentation, one should	Perhaps:
	assume (unless served over HTTPS) that the content of the <tt>Link</tt> header f	Deprecated resources function as
	ield may not be secure, private or integrity-guaranteed, and due caution should	they would have without sending the Deprecation header field,
	be exercised when using it, see <xref section="5" sectionFormat="of" target="LIN	even though non-functional details may be affected (e.g.,
	K"/> for more details. In cases where the Deprecation header field value is in t	they have less efficiency and longer response times).
	he past, the client application developers <bcp14>MUST</bcp14> no longer assume	-->
	that the behavior of the resource would remain the same as before the deprecatio
	n date. In cases where the Deprecation header field value is a date in the futur	<!-- [rfced] What does "it" refer to in this sentence?
	e, it can lead to information that otherwise might not be available. Therefore,
	client application developers consuming the resource <bcp14>SHOULD</bcp14>, if p	Original:
	ossible, consult the resource developer to discuss potential impact due to depre	In cases where the Deprecation header field value is a date in the
	cation and plan for possible transition to a recommended resource(s).</t>	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 otherw
		ise.
		-->

		<t>The Deprecation header field should be treated as a hint, meaning that
		the resource is indicating (but not guaranteeing with certainty) that it will be
		or has been deprecated. Deprecated resources function as they would have withou
		t sending the Deprecation header field, even though one might consider non-funct
		ional details such as making them progressively less efficient with longer respo
		nse time, for example.</t>
		<t>Resource documentation should provide additional information about the
		deprecation, such as recommendations for replacement. Developers of client appli
		cations consuming the resource <bcp14>SHOULD</bcp14> always check the referred r
		esource documentation to verify authenticity and accuracy. In cases where a <tt>
		Link</tt> header field is used to provide documentation, one should assume (unle
		ss served over HTTPS) that the content of the <tt>Link</tt> header field may not
		be secure, private, or integrity-guaranteed, so due caution should be exercised
		when using it (see <xref section="5" sectionFormat="of" target="RFC8288"/> for
		more 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 will remain the same as before the deprecation date. I
		n 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 ap
		plication developers consuming the resource <bcp14>SHOULD</bcp14>, if possible,
		consult the resource developer to discuss potential impact due to deprecation an
		d plan for possible transition to a recommended resource(s).</t>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>

	<references anchor="sec-normative-references">	<displayreference target="RFC9110" to="HTTP"/>
	<name>Normative References</name>	<displayreference target="RFC8288" to="LINK"/>
	<reference anchor="HTTP">
	<front>
	<title>HTTP Semantics</title>
	<author fullname="R. Fielding" initials="R." role="editor" surname="Fi
	elding"/>
	<author fullname="M. Nottingham" initials="M." role="editor" surname="
	Nottingham"/>
	<author fullname="J. Reschke" initials="J." role="editor" surname="Res
	chke"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless application
	-level protocol for distributed, collaborative, hypertext information systems. T
	his document describes the overall architecture of HTTP, establishes common term
	inology, 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, 723
	2, 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 relati
	on types").</t>
	<t>It also defines the serialisation of such links in HTTP headers w
	ith 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 alg
	orithms
	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>	<references anchor="sec-normative-references">
	</abstract>	<name>Normative References</name>
	</front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.911
	<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-sfbis-06"/>	0.xml"/>
	</reference>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.828
	<reference anchor="RFC2119">	8.xml"/>
	<front>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.965
	<title>Key words for use in RFCs to Indicate Requirement Levels</title	1.xml"/>
	>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>	9.xml"/>
	<date month="March" year="1997"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
	<abstract>	4.xml"/>
	<t>In many standards track documents several words are used to signi	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.859
	fy the requirements in the specification. These words are often capitalized. Thi	4.xml"/>
	s document defines these words as they should be interpreted in IETF documents.
	This document specifies an Internet Best Current Practices for the Internet Comm
	unity, 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</titl
	e>
	<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 on
	ly 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 poin
	t 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>
	</references>	</references>

	<?line 192?>


	<section anchor="implementation-status">	<section anchor="acknowledgments" numbered="false">
	<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 protoco
	l defined by this specification at the time of posting of this Internet-Draft. T
	he 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 l
	isting of any individual implementation here does not imply endorsement by the I
	ETF. Furthermore, no effort has been spent to verify the information presented h
	ere that was supplied by IETF contributors. This is not intended as, and must no
	t 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, wh
	ich may serve as evidence of valuable experimentation and feedback that have mad
	e the implemented protocols more mature. It is up to the individual working grou
	ps 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 head
	er 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 prefe
	rred 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 gen
	erated 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 Hesperid
	es, 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/hesperide
	s/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 app
	suite-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 hea
	der field for endpoints that have been deprecated because a new endpoint provide
	s 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 retur
	ned in the Registration Data Access Protocol (RDAP) notices to indicate deprecat
	ion 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>Deprec
	ated</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>Pay
	Pal-Deprecated</tt></t>
	</li>
	<li>
	<t>Reference: https://github.com/paypal/api-standards/blob/master/ap
	i-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">
	<name>Acknowledgments</name>	<name>Acknowledgments</name>

	<t>The authors would like to thank Nikhil Kolekar, Darrel Miller, Mark Not	<t>The authors would like to thank <contact fullname="Nikhil Kolekar"/>,
	tingham, and Roberto Polli for their contributions.</t>	<contact fullname="Darrel Miller"/>, <contact fullname="Mark
		Nottingham"/>, and <contact fullname="Roberto Polli"/> for their
		contributions.</t>
	<t>The authors take all responsibility for errors and omissions.</t>	<t>The authors take all responsibility for errors and omissions.</t>
	</section>	</section>
	</back>	</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=


		<!-- [rfced] Some sentences in the document mention deprecation of the
		resource while others mention deprecation of the context. Please review
		and let us know if any updates are needed.

		deprecation of "resource":
		resource will be or has been deprecated
		resource in context of the message is or will be deprecated
		resource in context has been deprecated
		deprecation of the resource
		deprecation of that specific resource
		deprecation of a resource(s)

		deprecation of "context":
		resource context will be deprecated
		resource context has been deprecated
		deprecation of the context
		deprecation of the resource context
		deprecation of the link's context

		Please also review use of "context" and let us know if any updates are needed
		for consistency and clarity.

		Examples:
		resource in context of the message
		resource context
		resource in context
		resource in the context
		link's context
		-->

		<!-- [rfced] We note inconsistencies in the terms below throughout the
		text. Should these be uniform? If so, please let us know which form is
		preferred.

		Deprecation HTTP response header field
		Deprecation HTTP header field
		Deprecation response header field
		Deprecation header field

		Sunset HTTP header field
		Sunset header field

		deprecation link relation
		"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 <tt> in this document. Please review
		the specific questions below. Note: In the html and pdf outputs, the text
		enclosed in <tt> is output in fixed-width font; in the txt output, there
		are no changes to the font.

		a) For header fields, we see use of both <tt> and no <tt>. See examples
		below. Which form do you prefer?

		<tt>Deprecation</tt> header field
		Deprecation header field

		<tt>Link</tt> header field
		Link header field

		<tt>Sunset</tt> header field
		Sunset HTTP header field

		b) For the link relation type, we see use of <tt>, quotation marks, and no
		<tt> or quotation marks. Which form do you prefer?

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

		<!-- [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>	</rfc>

End of changes. 32 change blocks.
	627 lines changed or deleted	434 lines changed or added
This html diff was produced by rfcdiff 1.48.