Skip to main content

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 revision No specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-11-20
Requested 2018-10-23
Authors Erik Wilde
I-D 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 A. Salowey (diff)
Opsdir Last Call review of -07 by Scott O. Bradner (diff)
Secdir Telechat review of -08 by Joseph A. Salowey (diff)
Assignment Reviewer Scott O. Bradner
State Completed
Request Last Call review on draft-wilde-sunset-header by Ops Directorate Assigned
Reviewed revision 07 (document currently at 11)
Result Has issues
Completed 2018-11-16
review-wilde-sunset-header-07-opsdir-lc-bradner-2018-11-16-00
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.