Subject: [httpapi] Clarification on 'Sunset' header

From: Evert Pot <[email-masked]>
Date: Sat, 19 Dec 2020 14:30:14 -0500

Hi everyone,

We are adopting the Deprecation header and link relation in our tools:

https://github.com/badgateway/ketting
https://github.com/curveball/browser

We already had some support for the 'deprecated' status from 
link-hints[1], so this addition makes a lot of sense. 'Ketting' will 
emit console warnings when hitting things that are deprecated, and the 
'Curveball hypermedia browser' renders links, but will use a special 
treatment for links with the 'deprecation' relation type.

I have a question about the 'Sunset' header though. The draft states:

 >  In addition to the deprecation related information, if the resource
 > provider wants to convey to the client application that the
 > deprecated resource is expected to become unresponsive at a specific
 > point in time, the Sunset HTTP header field [RFC8594] can be used in
 > addition to the "Deprecation" header

To me, a resource conveying when they will eventually become 
unresponsive is not *necessarily* worthy of warning. Perhaps, the intent 
of a resource is to just live a limited time.

So, I wonder if it's useful to define Sunset not as a warning (you need 
to upgrade) or additive to Deprecation. Could Sunset be used if I want 
to just convey: this resource is only available until then. Perhaps my 
API will let you download reports for exactly 30 days after creation, so 
I'd wanna inform users, but this is not a deprecation.

Question: has the structured headers[2] syntax been considered for the 
Deprecation header? ('?1' instead of 'true')

Evert

[1]: https://tools.ietf.org/html/draft-nottingham-link-hint
[2]: 
https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-19#section-4.1.9

---

From: Erik Wilde <[email-masked]>
Date: Sun, 20 Dec 2020 09:05:18 -0800

hello evert.

> of a resource is to just live a limited time.

very true. that was one of the original motivations of the sunset header 
as well (apart from the "we're shutting down this service" scenario).

> I'd wanna inform users, but this is not a deprecation.

absolutely, and i think it would be great to use it that way. it's even 
the first item in the list of scenarios:

https://tools.ietf.org/html/rfc8594#section-1.1

you just have to be clear in the scope of your headers. that's something 
to clearly document for your API:

- when a report indicates a sunset, this applies to the report only.

- when the service's home document indicates a sunset, this means we're 
shutting down the service.

> Deprecation header? ('?1' instead of 'true')

we mostly went for parity with the sunset header field on this one: they 
both should look and work in the same way.

cheers,

dret.

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