Technical Summary
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 clients can best manage deprecation.
Working Group Summary
It had broad, although at times shallow, consensus. Nobody was ever really
opposed. This is typical of the HTTPAPI WG, which has a mix of people who are
interested in different aspects of HTTP API's.
Earlier in the draft history, there was a suggestion that this concept is really
part of a larger lifecycle for APIs. After a couple of months nobody stepped
forward to work on such a document, and the Chairs decided (backed by no
opposition from the WG membership) to proceed with "just" deprecation.
There was also a (relatively) large amount of discussion around one
particular issue,
https://github.com/ietf-wg-httpapi/deprecation-header/issues/11 The Chairs
determined rough consensus for the authors's proposed resolution.
Document Quality
The draft lists several implementations in Appendix A, including other IETF
work at https://tools.ietf.org/html/draft-loffredo-regext-rdap-jcard-deprecation
Implementations and questions have been discussed on many websites, including
StackOverflow, the Python library GitHub, and a blog post (at
https://imhoratiu.wordpress.com/2021/01/20/respectful-rest-apis-sunset-and-deprecation-http-headers/)
which compare header with Sunset (RFC 8594)
Personnel
The Document Shepherd for this document is Rich Salz. The Responsible
Area Director is Francesca Palombini.