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 "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.0. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-httpapi-deprecation-header-latest" number="9745" updates="" obsoletes="" s
<?rfc tocindent="yes"?> ubmissionType="IETF" category="std" consensus="true" tocInclude="true" sortRefs=
<?rfc strict="yes"?> "true" symRefs="true" version="3" xml:lang="en">
<?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 Response Header Field</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpapi-deprecation-head <seriesInfo name="RFC" value="9745"/>
er-latest"/>
<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 <abstract><t>The Deprecation HTTP response header field is used to signal
a resource (in the sense of URI) that the resource will be or has been deprecate to consumers of a resource (identified by a URI) that the resource will be
d. Additionally, the deprecation link relation can be used to link to a resource or has been deprecated. Additionally, the <tt>deprecation</tt> link relation
that provides additional information about planned or existing deprecation, and can be
possibly ways in which client application developers can best manage deprecatio used to link to a resource that provides further information about planned
n.</t> or existing deprecation. It may also provide 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 indicate 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 <tt>Deprecation</tt> header field, the resource prov
l information related to deprecation. This can be information such as where to f ider can use other header fields such as the <tt>Link</tt> header field <xref ta
ind documentation related to the deprecation, what can be used as a replacement, rget="RFC8288"/> to convey additional information related to deprecation. This c
and when a deprecated resource becomes non-operational.</t> an be information such as where to find documentation related to the deprecation
<section anchor="notational-conventions"> , what can be used 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&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
<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> HTTP response header field describes the dep
ion of the resource identified with the response it occurred within (see <xref s recation of the resource identified with the response it occurred within (see <x
ection="6.4.2" sectionFormat="of" target="HTTP"/>). It conveys the deprecation d ref section="6.4.2" sectionFormat="of" target="RFC9110"/>). It conveys the depre
ate, which may be in the future (the resource context will be deprecated at that cation date, which may be in the future (the resource in context will be depreca
date) or in the past (the resource context has been deprecated at that date).</ ted at that date) or in the past (the resource in context was deprecated at that
t> date).</t>
<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 <t><tt>Deprecation</tt> is an Item Structured Header Field; its value <b
et="STRUCTURED-FIELDS"/>.</t> cp14>MUST</bcp14> be a Date as per <xref section="3.3.7" sectionFormat="of" targ
<t>The following example shows that the resource context has been deprec et="RFC9651"/>.</t>
ated on Friday, June 30, 2023 at 23:59:59 UTC:</t> <t>The following example shows that the resource in context was deprecat
ed 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 <tt>Deprecation</tt> header field applies to the resource identif
the response it occurred within (see <xref section="6.4.2" sectionFormat="of" ta ied with the response it occurred within (see <xref section="6.4.2" sectionForma
rget="HTTP"/>), meaning that it announces the upcoming deprecation of that speci t="of" target="RFC9110"/>), meaning that it announces the upcoming deprecation o
fic resource. However, there may be scenarios where the scope of the announced d f that specific resource. However, there may be scenarios where the scope of the
eprecation is larger than just the single resource where it appears.</t> announced deprecation is larger than just the single resource where it appears.
<t>Resources are free to define such an increased scope, and usually thi </t>
s scope will be documented by the resource so that consumers of the resource kno <t>Resources are free to define such an increased scope, and usually thi
w about the increased scope and can behave accordingly. When doing so, it is imp s scope will be documented by the resource so that consumers of the resource kno
ortant to take into account that such increased scoping is invisible for consume w about the increased scope and can behave accordingly. When doing so, it is imp
rs who are unaware of the increased scoping rules. This means that these consume ortant to take into account that such increased scoping is invisible for consume
rs will not be aware of the increased scope, and they will not interpret depreca rs who are unaware of the increased scoping rules. This means that these consume
tion information different from its standard meaning (i.e., it applies to the re rs will not be aware of the increased scope, and they will not interpret depreca
source only).</t> tion-related information differently from its standard meaning (i.e., it applies
<t>Using such an increased scope still may make sense, as deprecation in to the resource only).</t>
formation is only a hint anyway. It is optional information that cannot be depen
ded on, and client applications should always be implemented in ways that allow <t>Using such an increased scope still may make sense, as deprecation-rel
them to function without Deprecation information. Increased scope information ma ated information is only a hint anyway. It is optional information that cannot b
y help client application developers to glean additional hints from related reso e depended on, and client applications should always be implemented in ways that
urces and, thus, might allow them to implement behavior that allows them to make allow them to function without deprecation-related information. Increased scope
educated guesses about resources becoming deprecated.</t> information may help client application developers to glean additional hints fr
<t>For example, an API might not use Deprecation header fields on all of om related resources and thus might allow them to implement behavior that enable
its resources, but only on designated resources such as the API's home document s them to make educated guesses about resources becoming deprecated.</t>
. This means that deprecation information is available, but in order to get it, <t>For example, an API might not use <tt>Deprecation</tt> header fields
client application developers have to periodically inspect the home document. In on all of its resources but only on designated resources such as the API's home
this example, the extended context of the Deprecation header field would be all document. This means that deprecation-related information is available, but in o
resources provided by the API, while the visibility of the information would on rder to get it, client application developers have to periodically inspect the h
ly be on the home document.</t> ome document. In this example, the extended context of the <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> </section>
<section anchor="the-deprecation-link-relation-type"> <section anchor="the-deprecation-link-relation-type">
<name>The Deprecation Link Relation Type</name> <name>The <tt>Deprecation</tt> Link Relation Type</name>
<t>In addition to the Deprecation HTTP header field, the server can use li <t>In addition to the Deprecation HTTP response header field, the server c
nks with the "deprecation" link relation type to communicate to the client appli an use links with the <tt>deprecation</tt> link relation type to communicate to
cation developer where to find more information about deprecation of the context the client application developer where to find more information about deprecatio
. This can happen before the actual deprecation, to make a deprecation policy di n of the context. This can happen before the actual deprecation to make a deprec
scoverable, or after deprecation, when there may be documentation about the depr ation policy discoverable or after deprecation when there may be documentation a
ecation, and possibly documentation of how to manage it.</t> bout the deprecation and how to manage it.</t>
<t>This specification places no restrictions on the representation of the <t>This specification places no restrictions on the representation of the
linked deprecation policy. In particular, the deprecation policy may be availabl linked deprecation policy. In particular, the deprecation policy may be availabl
e as human-readable documentation or as machine-readable description.</t> 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's do cumentation using a <tt>Link</tt> header field with the relation type <tt>deprec ation</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 <t>In this example, the linked content provides additional information about
the response, and thus the resource is not (yet) deprecated. However, the resou deprecation of the resource in context. There is no <tt>Deprecation</tt> header
rce already exposes a link where information is available describing how depreca field in
tion is managed for the resource. This may be the documentation explaining under the response; thus, the resource is not (yet) deprecated. However, the
which circumstances and with which policies deprecation might take place. For e resource already exposes a link where information describing how deprecation
xample, a policy may indicate that deprecation of a resource(s) will always be s is managed for the resource is available. This may be the documentation
ignaled in the dedicated places at least N days ahead of the planned deprecation explaining the circumstances in which deprecation might take place and the
date and then only the resource(s) would be deprecated. Or a policy may indicat deprecation policies. For example, a policy may indicate that deprecation of
e that resource(s) would be deprecated first and then only be signaled as deprec a resource(s) will always be signaled in the dedicated places at least N days
ated at dedicated places. The documentation in addition to the deprecation polic ahead of the planned deprecation date and then the resource(s) would be
y may also provide a migration guide exaplaining to consumers of the resource ho deprecated on the planned date. Or a policy may indicate that the resource(s)
w to migrate to a new resource(s) or an alternate resource(s) before the depreca would be deprecated first and then be signaled as deprecated at dedicated
tion date. Such policy and documentation would be very useful to consumers of th places. The documentation, in addition to the deprecation policy, may also
e resource to plan ahead and migrate successfully.</t> provide a migration guide explaining to consumers of the resource how to
<t>The following example uses the same link header field, but also annou migrate to a new or alternate resource(s) before the deprecation date. Such
nces a deprecation date using a Deprecation header field:</t> 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 <tt>Link</tt> header field but al
so announces a deprecation date using a <tt>Deprecation</tt> 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 <tt>Sunset</tt>
der field <xref target="RFC8594"/> can be used in addition to the <tt>Deprecatio HTTP header field <xref target="RFC8594"/> can be used in addition to the <tt>D
n</tt> header field.</t> eprecation</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> HTTP header field <bcp14>MUS
</bcp14> be earlier than the one given in the <tt>Deprecation</tt> header field. T NOT</bcp14> be earlier than the one given in the <tt>Deprecation</tt> header f
If that happens for some reasons such as misconfiguration of deployment of the ield. If that happens (for example, due to misconfiguration of deployment of the
resource or an error, the client application developer <bcp14>SHOULD</bcp14> con resource or an error), the client application developer <bcp14>SHOULD</bcp14> c
sult the resource developer to get clarification.</t> onsult 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 <tt>Sunset</
et HTTP header field uses a different data format for date.</t> tt> HTTP 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 <t>The act of deprecation does not change any behavior of the resource.
e presence of a Deprecation header field in response is not meant to signal a ch The presence of a <tt>Deprecation</tt> header field in a response is not m
ange in the meaning or function of a resource in the context, allowing consumers eant to
to still use the resource in the same way as they did before the resource was d signal a change in the meaning or function of a resource in the context;
eclared deprecated.</t> consumers can 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> HTTP response header field has been added to
"Hypertext Transfer Protocol (HTTP) Field Name Registry" registry (<xref sectio the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (<xref section="16
n="16.3.1" sectionFormat="of" target="HTTP"/>)</t> .3.1" 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 Response Header Fi
eld</dd>
Specification document: this specification, </dl>
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 <tt>Deprecation</tt> 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[ <dl newline="false">
Relation Name: deprecation <dt>Relation Name:</dt><dd>deprecation</dd>
<dt>Description:</dt><dd>Refers to documentation (intended for human co
Description: Refers to a resource that is documentation (intended for human cons nsumption) about the deprecation of the link's context.</dd>
umption) about the deprecation of the link's context. <dt>Reference:</dt><dd>RFC 9745, <xref target="the-deprecation-link-rel
ation-type" format="default"/></dd>
Specification document: this specification, </dl>
Section 3 "The Deprecation Link Relation Type"
]]></artwork>
</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 <t>The <tt>Deprecation</tt> header field should be treated as a hint, mean
the resource is indicating (and not guaranteeing with certainty) that it will be ing that the resource is indicating (but not guaranteeing with certainty) that i
or is deprecated. Deprecated resources function as they would have without send t will be or has been deprecated. Deprecated resources function as they would ha
ing the deprecation header field, even though one might consider non-functional ve without sending the <tt>Deprecation</tt> header field, even though non-functi
details such as making them progressively less efficient with longer response ti onal details may be affected (e.g., they have less efficiency and longer respons
me for example.</t> e times).</t>
<t>Resource documentation should provide additional information about the <t>The resource's documentation should provide additional information abou
deprecation, such as including recommendation(s) for replacement. Developers of t the deprecation, such as recommendations for replacement. Developers of client
client applications consuming the resource <bcp14>SHOULD</bcp14> always check th applications consuming the resource <bcp14>SHOULD</bcp14> always check the refe
e referred resource documentation to verify authenticity and accuracy. In cases rred resource's documentation to verify authenticity and accuracy. In cases wher
where a <tt>Link</tt> header field is used to provide documentation, one should e a <tt>Link</tt> header field is used to provide documentation, one should assu
assume (unless served over HTTPS) that the content of the <tt>Link</tt> header f me (unless served over HTTPS) that the content of the <tt>Link</tt> header field
ield may not be secure, private or integrity-guaranteed, and due caution should may not be secure, private, or integrity-guaranteed, so due caution should be e
be exercised when using it, see <xref section="5" sectionFormat="of" target="LIN xercised when using it (see <xref section="5" sectionFormat="of" target="RFC8288
K"/> for more details. In cases where the Deprecation header field value is in t "/> for more details). In cases where the <tt>Deprecation</tt> header field valu
he past, the client application developers <bcp14>MUST</bcp14> no longer assume e is in the past, the client application developers <bcp14>MUST</bcp14> no longe
that the behavior of the resource would remain the same as before the deprecatio r assume that the behavior of the resource will remain the same as before the de
n date. In cases where the Deprecation header field value is a date in the futur precation date. In cases where the <tt>Deprecation</tt> header field value is a
e, it can lead to information that otherwise might not be available. Therefore, date in the future, it informs client application developers about the effective
client application developers consuming the resource <bcp14>SHOULD</bcp14>, if p date in the future for deprecation. Therefore, client application developers co
ossible, consult the resource developer to discuss potential impact due to depre nsuming the resource <bcp14>SHOULD</bcp14>, if possible, consult the resource de
cation and plan for possible transition to a recommended resource(s).</t> veloper to discuss potential impact due to deprecation and plan for possible tra
nsition 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=
</rfc> </rfc>
 End of changes. 29 change blocks. 
635 lines changed or deleted 214 lines changed or added

This html diff was produced by rfcdiff 1.48.