The Sunset HTTP Header Field
RFC 8594

Note: This ballot was opened for revision 08 and is now closed.

(Spencer Dawkins) Yes

Comment (2018-12-17 for -08)
Thanks for writing this. I hope it will be used (when resources do sunset). 

I'm looking at 

  Timestamps in the past SHOULD be considered to mean the present time,
   meaning that the resource is expected to become unavailable at any

and thinking (1) "what else could a date in the past possibly mean?", (2) this probably isn't a BCP14 requirement for interworking, so doesn't need to use requirements language, and could more usefully be stated as advice ("it is safest to consider timestamps in the past mean that ..."), and (3) if this is going to be BCP14 requirements language, could you provide any examples of a receiver usefully interpreting a timestime in the past as anything other than "you ought to be very nervous"?

I have worked with implementers in the past who would benefit from a more complete example (including a sunset link relation). 

In this text, 

  Clients not interpreting an existing Sunset header field can operate
   as usual and simply may experience the resource becoming unavailable
   without getting any notification about it beforehand.

it might be clearer as 

 Clients not interpreting an existing Sunset header field can operate
   as usual and simply may experience the resource becoming unavailable
   without recognizing any notification about it beforehand.

I would have found the combination of Section 1.4 and Section 5 easier to understand if this material had been combined into one section. I recognize that resulting length might not be appropriate in the Introduction.

(Alexey Melnikov) Yes

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-12-19 for -08)
Why is this informational? It seems to be defining a standard. I see that the shepherd review says it has had insufficient review for the standards track. The reasoning should be reflected somewhere in the text of the document. (I agree with Mirja's comment that "experimental" might be the appropriate choice.)

§8: Is there potential to have a sunset header inserted by a malicious intermediary? What would happen if one did?

Alissa Cooper No Objection

Comment (2018-12-18 for -08)
Please use the RFC 8174 boilerplate in Section 2 rather than the RFC 2119 boilerplate.

I am interested in the answers to Mirja's questions.

Benjamin Kaduk No Objection

Comment (2018-12-20 for -08)
Section 1.1

"pending order" may mean different things to different people.  It's
unclear whether this really matters for this context, though.  (FWIW, my
first mental binding was to an ACME "order" object.)

Section 6

Is there any guidance to give about how to determine authenticty and
accuracy?  For example, if HTTPS is used, is the normal TLS server
certificate validation procedure (e.g., of RFC 6125) sufficient?

Section 8

There seems to be two broad classes of consideration here: information
leakage from the entity adding sunset, and interpretation of provided 
sunset data by a client.  The former is reasonably well covered, but the
latter seems to be only partially covered, with text noting that the data
may be inaccurate by happenstance.  Is there anything more to say about the
potential for malicious insertion of sunset fields, e.g., by adding the 
field with the current time in an effort to DoS clients that treat the 
field as authoritative?

(Suresh Krishnan) No Objection

Comment (2018-12-19 for -08)
I agree with Mirja that this would be more appropriate as an Experimental document.

* Section 4:

The document states that HTTP caching is complementary but I think the sunset time needs to put an upper bound on the caching. i.e. I could not see why somebody would cache past a sunset time.

(Mirja Kühlewind) No Objection

Comment (2018-12-14 for -08)
No email
send info
These comments are mostly for the responsible AD:

1) From the shepherd write-up it sounds like this document should experimental and not informational ("it hasn't been widely reviewed or implemented enough to make it standards-track").

2) Why was this document not processed in the httpbis wg. It seems to be fully in scope for httpbis and if there is a suitable wg, I think it is always more appropriate to take the wg track with last call and and respective reviews than an individual submission. If the httpbis wg does not support this doc, it maybe shouldn't be processed in the IETF at all (and could e.g. also be published with the ISE to have a stable reference).

Alvaro Retana No Objection

(Adam Roach) No Objection

Comment (2018-12-18 for -08)
Thanks to everyone who worked on this document. I have a handful of minor


I-D Nits reports:

  == Unused Reference: 'RFC6982' is defined on line 405, but no explicit
     reference was found in the text

  -- Obsolete informational reference (is this intentional?): RFC 6982
     (Obsoleted by RFC 7942)


Title: "The Sunset HTTP Header"

Nit: "...Header Field"



>  returning the sunset header field.  Section Section 5 discusses how
>  the scope of the Sunset header field may change because of how a
>  resource is using it.

Nit: "Section 5..." (remove repeated "Section")



> 3.  The Sunset HTTP Response Header

Nit: "...Header Field"

>  The Sunset header contains a single timestamp which advertises the
>  point in time when the resource is expected to become unresponsive.

Nit: "...header field..."

>  The Sunset
>  header does not expose any information about which of those behaviors
>  can be expected.

Nit: "...header field..."



I'm glad to see this discussion of caching. I'm curious whether similar
considerations have been given to interaction with search engines (e.g.,
should a web search engine stop returning a resource in its results after a
Sunset date?) and with Archiving (e.g., would be expected to
remove resources from the archive, as they presently do with robots.txt files,
once the resource has sunset?) I'm guessing the answer to both questions is
"no," but it would be good to be explicit on this point.



>  The Sunset header field applies to the resource that returns it,
>  meaning that it announces the upcoming sunset of that specific
>  resources.

Nit: "...resource."



> 7.1.  The Sunset Response Header

Nit: "Header Field"

>  The Sunset response header should be added to the permanent registry

Nit: "header field"



>  In cases where a sunset policy is linked by using the sunset link
>  relation type, clients should be careful about taking any actions
>  based on this information.  It should be verified that the
>  information is authentic and accurate.  Furthermore, it should be
>  tested that this information is only applied to resources that are
>  within the scope of the policy, making sure that sunset policies
>  cannot "hijack" resources by for example providing migration
>  information for them.

These "should"s all seem pretty normative to me. Should the be all-caps?



>  Before the Sunset header even appears for the first time (it may not

Nit: "header field"

>  appear fro the very beginning), it is possible that the resource (or

Nit: "from"

Martin Vigoureux No Objection