Last Call Review of draft-wilde-sunset-header-07
review-wilde-sunset-header-07-opsdir-lc-bradner-2018-11-16-00
| Request | Review of | draft-wilde-sunset-header |
|---|---|---|
| Requested rev. | no specific revision (document currently at 11) | |
| Type | Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2018-11-20 | |
| Requested | 2018-10-23 | |
| Draft last updated | 2018-11-16 | |
| Completed reviews |
Genart Last Call review of -07 by Jari Arkko
(diff)
Secdir Last Call review of -07 by Joseph Salowey (diff) Opsdir Last Call review of -07 by Scott Bradner (diff) Secdir Telechat review of -08 by Joseph Salowey (diff) |
|
| Assignment | Reviewer | Scott Bradner |
| State | Completed | |
| Review | review-wilde-sunset-header-07-opsdir-lc-bradner-2018-11-16 | |
| Reviewed rev. | 07 (document currently at 11) | |
| Review result | Has Issues | |
| Review completed: | 2018-11-16 |
Review
review-wilde-sunset-header-07-opsdir-lc-bradner-2018-11-16
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. This document describes a new HTTP hearer which is to be used to warn a reader that at some defined time in the future the web resource he or she just retrieved will not be accessible using the URI that was used to retrieve the resource. 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. 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) 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. 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.