Code change:
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 either 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), or it simply flags the resource context as being deprecated. </del> <ins> 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). </ins> Servers MUST NOT include more than one "Deprecation" header field in the same response. <del> The date, if present, is the date when the resource was or will be deprecated.  It is in the form of an IMF-fixdate timestamp. </del> <ins> The date is the date when the resource was or will be deprecated.  It is in the form of an IMF-fixdate timestamp. </ins> The following example shows that the resource context has been deprecated on Sunday, November 11, 2018 at 23:59:59 GMT: The deprecation date can be in the future.  This means that the <del> resource will be deprecated at the given date in future. If the deprecation date is not known, the header field can carry the simple string "true", indicating that the resource context is deprecated, without indicating when that happened: </del> <ins> resource will be deprecated at the indicated date in the future. </ins> 2.2.

Related discussion:
text: Looks good to me.
... are considered a 'bad smell'. Instead of a date vs. a fixed string, could we just say that a date in the past is equal to 'true'?
i guess we could. and we already say that a date in the past means that the resource is deprecated. the motivation to allow a flag was to not force services to make up a date when they don't have one and simply want to flag something as deprecated. but we could also "force" them to make up a date by not allowing the "true" flag. i am fine either way and i do see the point that the syntax may cause some implementations to not parse the field correctly. maybe others can weigh in as well?
FWIW, I see it like Expires -- if it's already stale, you just assign a date in the past.
i could definitely live with such a design.
One use case was to align the header's usage with API contract as defined using OpenAPI. Having boolean helps align this header with OpenAPI's flag which does not require date. Forcing API developers to add a random date in the past in case if it is not available due toe various reasons would not be desirable for various other reasons (SLA?). Although, I wish that OpenAPI adds date for . >If the deprecation date is not known, the header field can carry the simple string "true", indicating that the resource context is deprecated, without indicating when that happened: On Jul 31, 2021, at 06:46, Mark Nottingham NAME wrote: FWIW, I see it like Expires -- if it's already stale, you just assign a date in the past.
For Expires, January 1 1970 (epoch 0) is widely used.
NAME I wish OpenAPI supported deprecated date also. But when we do, it won't be with a property that can be boolean or date.
Ok NAME thanks for clarification on the OpenAPI side of things. I agree. We can just use date. There are some implementations out there, I would not know if any of those use boolean but since we are not an RFC yet, such a change should not be unexpected.
it seems like we can safely remove the alternative syntax. i have created a PR asking for review by NAME
LGTM