Subject: Opsdir last call review of draft-wilde-sunset-header-07

From: Scott Bradner <[email-masked]>
Date: Fri, 16 Nov 2018 08:19:04 -0800

Reviewer: Scott Bradner
Review result: Has Issues

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.

---

From: Erik Wilde <[email-masked]>
Date: Thu, 29 Nov 2018 11:14:47 -0700

hello scott.

thanks for the review.

> agree with the points he raises.

ok. i have made changes as suggested by jari.

> 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.

> (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 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

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:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |