Draft: draft-ietf-httpapi-deprecation-header

Commentary: 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 do n'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  -- 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 ,    , I see it like  -- if it 's already stale , you just assign a date in the past . 
 For  , January 1 1970 ( epoch 0 ) is widely used . 
 I wish OpenAPI supported deprecated date also . But when we do , it wo n't be with a property that can be boolean or date . 
 Ok 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 
 LGTM
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 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.
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.
The deprecation date can be in the future.  This means that the
resource will be deprecated at the given date in future.
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 date is the date when the resource was or will be deprecated.  It
is in the form of an IMF-fixdate timestamp.
The deprecation date can be in the future.  This means that the
resource will be deprecated at the indicated date in the future.