Draft: draft-ietf-httpapi-deprecation-header

Commentary: This repo was n'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 , 
 Fixed .
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.
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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.
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of RFC5234 and includes, by reference, the IMF-fixdate rule
as defined in Section 7.1.1.1 of HTTP.
The term "resource" is to be interpreted as defined in Section 2 of
HTTP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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.
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of RFC5234 and includes, by reference, the IMF-fixdate rule
as defined in HTTP.
The term "resource" is to be interpreted as defined in HTTP.
The "Deprecation" response header field describes the deprecation of
the resource identified with the response it occurred within (see
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).
The "Deprecation" response header field describes the deprecation of
the resource identified with the response it occurred within (see
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).
The Deprecation header field applies to the resource identified with
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.
The Deprecation header field applies to the resource identified with
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.
The "deprecation" link relation type should be added to the permanent
registry of link relation types (Section 4.2 of LINK).
The "deprecation" link relation type should be added to the permanent
registry of link relation types (LINK).