hello scott. thanks for the review. On 2018-11-16 09:19, Scott Bradner wrote:
This is an OPS-DIR review of “The Sunset HTTP Header” (draft-wilde-sunset-header-07.txt) I have taken Jari’s review into account and agree with the points he raises.
ok. i have made changes as suggested by jari.
The application of this header seems narrow – for example the sunset header would not be available once the resource is no longer available thus the header is only useful between the time someone decides to publish a resource and the time that the resource is removed – but even with such a limited period of usefulness the sunset header could provide useful information to Internet users.
agreed that this is narrow in the sense that most resources will not use this. there are however scenarios where this is useful.
One minor suggestion on wording: The 3rd paragraph of section 3 reads: Timestamps in the past SHOULD be considered to mean the present time, meaning that the resource is expected to become unavailable at any point in time. Imo it would read better if instead it read: Timestamps in the past SHOULD be considered to mean the present time, meaning that the resource is expected to become unavailable at any time. (remove “point in” from the end of the sentence)
ok, thanks for the suggestion. done here: https://github.com/dret/I-D/commit/a358ff5f7680b7c8fa1a77adfbb0a9972383c3a9
Section 6 of the document would benefit from additional work – this section talks about using an additional URI to point to some extra information that might help the user understand why the resource will be going away but the section does not actually say how to do this.
true. but that's because just defining a link relation does not make any assumptions where and how those links will be used. it would be up for the service using these links to make that decision (see below).
For example, should the URI be a 2nd argument in the sunset header or placed somewhere else, if the latter how would the reader know it was linked to the sunset header. Seems to me that having an optional 2nd argument would be a reasonable way to go but in any case additional discussion would be helpful as would an example.
since this is a link relation, it can go anywhere where typed links can go. it could go in a service's "home document", it could go into every resource (probably that's too wasteful, but OpenAPI's "link objects" could help here), or it can be used in an HTTP Link header field.
as suggested by jari, i have now added an example of a sunset-typed link to the examples section (which uses the variant where the link is represented in an HTTP Link header field). does this address your concern?
thanks again for the review and kind regards, dret. -- erik wilde | mailto:erik.wilde@xxxxxxxx | | http://dret.net/netdret | | http://twitter.com/dret |
