Original text:
The Deprecation HTTP Header Field <del> draft-ietf-httpapi-deprecation-header-02 </del>  Abstract 1. <del> Deprecation of an HTTP resource (Section 2 of HTTP) communicates information about the lifecycle of a resource.  It encourages applications to migrate away from the resource, discourages applications from forming new dependencies on the resource, and informs applications about the risk of continuing dependence upon the resource. </del>  The act of deprecation does not change any behavior of the resource. It informs clients of the fact that a resource is deprecated.  The The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del>  This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule <del> as defined in Section 7.1.1.1 of HTTP. </del>  <del> The term "resource" is to be interpreted as defined in Section 2 of HTTP. </del>  2. The "Deprecation" response header field describes the deprecation of the resource identified with the response it occurred within (see <del> Section 3.1.4.1 of HTTP).  It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date). </del>  Servers MUST NOT include more than one "Deprecation" header field in the same response. 2.2. The Deprecation header field applies to the resource identified with <del> the response it occurred within (see Section 3.1.4.1 of HTTP), meaning that it announces the upcoming deprecation of that specific resource.  However, there may be scenarios where the scope of the announced deprecation is larger than just the single resource where it appears. </del>  Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of 7.2. The "deprecation" link relation type should be added to the permanent <del> registry of link relation types (Section 4.2 of LINK). </del>  8.

Reviewer comments:
This repo wasn't set up with the automated tooling; this PR corrects that, and fixes up a few other small things.
it seems like there's some problem with this update, NAME URL
Fixed.

Revised text:
The Deprecation HTTP Header Field  <ins> draft-ietf-httpapi-deprecation-header-latest </ins> Abstract 1.  <ins> Deprecation of an HTTP resource (HTTP) communicates information about the lifecycle of a resource.  It encourages applications to migrate away from the resource, discourages applications from forming new dependencies on the resource, and informs applications about the risk of continuing dependence upon the resource. </ins> The act of deprecation does not change any behavior of the resource. It informs clients of the fact that a resource is deprecated.  The The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule  <ins> as defined in HTTP. </ins>  <ins> The term "resource" is to be interpreted as defined in HTTP. </ins> 2. The "Deprecation" response header field describes the deprecation of the resource identified with the response it occurred within (see  <ins> HTTP).  It conveys the deprecation date, which may be in the future (the resource context will be deprecated at that date) or in the past (the resource context has been deprecated at that date). </ins> Servers MUST NOT include more than one "Deprecation" header field in the same response. 2.2. The Deprecation header field applies to the resource identified with  <ins> the response it occurred within (see HTTP), meaning that it announces the upcoming deprecation of that specific resource.  However, there may be scenarios where the scope of the announced deprecation is larger than just the single resource where it appears. </ins> Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of 7.2. The "deprecation" link relation type should be added to the permanent  <ins> registry of link relation types (LINK). </ins> 8.