Re: [httpapi] Scope of deprecation header

[Erik Wilde <[e-mail]>]

hello darrel.

thanks for your feedback, and apologies for the delay.

i discussed this with sanjay, and we agree that currently, there is a 
bit of an implicit mismatch between some statements.

On 2020-12-02 18:07, Darrel Miller wrote:
> In the introduction of the document, the following statement is made.
> 
>   * It just informs client of the fact that a resource is deprecated. 
> 
> In the documentation, there is further qualification,
> 
> ØFor a resource, deprecation could involve one or more parts of
> 
>   * request, response or both.
> 
> https://tools.ietf.org/html/draft-dalal-deprecation-header-00#section-3.1 <https://tools.ietf.org/html/draft-dalal-deprecation-header-00#section-3.1> 
> 
> There is then a list of potential partial deprecations, including 
> methods, headers and request or response body elements.
> 
> By introducing the possibility of signalling the deprecation of some 
> element of the overall HTTP interaction, it seems to be in conflict with 
> the original statement that says a “resource is deprecated”.  It also 
> introduces other conflicts such as not allowing multiple deprecation 
> headers.  If deprecation can be partial, wouldn’t it be likely there 
> would be multiple deprecations for a single resource?

you're absolutely right that being able to deprecate "aspects" of an API 
complicates the picture a fair bit.

sanjay went through the APIs that we are aware of that use deprecation 
(in some shape or form, not necessarily using our draft), and with one 
exception, they all deprecate at the resource-level.

> The Sunset header is more explicit about the granularity of impact.  RFC 
> 8594 describes the impact of the sunset header,
> 
> Øindicates that a URI is likely to become unresponsive at a
> 
> Ø   specified point in the future

in my mind, aligning with the sunset spec (which also works at the 
resource level) would make sense. if we did choose the route of being 
able to deprecate specific aspects, then we would need to have a 
well-defined model of how to identify them, and we don't have that in 
the current draft.

> Is it intended that there be different granularity for the deprecated 
> header vs sunset header?

our proposal is to stay with the model that we currently support and 
describe in the intro, and to fix the language so that it does not 
create the impression that individual aspects can be deprecated using 
this spec.

we could then see whether over time momentum is building up for a more 
refined model. if that's the case, this might then be best addressed 
with a different header field.

thanks and cheers and happy new year everybody,

dret.


-- 
erik wilde | mailto:[e-mail] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |