The Sunset HTTP Header Field
draft-wilde-sunset-header-11

Thanks to everyone who worked on this document. I have a handful of minor
comments.

---------------------------------------------------------------------------

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"

---------------------------------------------------------------------------

§1:

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

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

---------------------------------------------------------------------------

§4:

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

---------------------------------------------------------------------------

§5:

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

> 7.1.  The Sunset Response Header

Nit: "Header Field"

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

Nit: "header field"

---------------------------------------------------------------------------

§8:

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

---------------------------------------------------------------------------

§9:

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

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.

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?

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?

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

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.