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

[Ballot comment]
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?

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]

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"

[Ballot comment]
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.

[Ballot comment]
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
  time.

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.

[Ballot comment]
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).

[Ballot comment]
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 shoudn't be processed in the IETF at all (and could e.g. also be published with the ISE to have a stable reference).

# Shepherd Writeup for draft-wilde-sunset-header-08

## 1. Summary

Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director.

This specification defines the Sunset HTTP response header field, which
indicates that a URI is likely to become unresponsive at a specified point in
the future. It also defines a sunset link relation type that allows linking to
resources providing information about an upcoming resource or service sunset.


## 2. Review and Consensus

This document has not seen substantial discussion in IETF fora, but the HTTP Working Group is aware of it.  It has been reviewed by the various review teams across the IETF.

## 3. Intellectual Property

The author confirms that to their direct, personal knowledge, all IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.

## 4. Other Points

As Document Shepherd, I think Informational is appropriate for this document; it's not likely to cause harm, and it may do some good, but it hasn't been widely reviewed or implemented enough to make it standards-track.

# Shepherd Writeup for draft-wilde-sunset-header-07

## 1. Summary

Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director.

This specification defines the Sunset HTTP response header field, which
indicates that a URI is likely to become unresponsive at a specified point in
the future. It also defines a sunset link relation type that allows linking to
resources providing information about an upcoming resource or service sunset.


## 2. Review and Consensus

This document has not seen substantial discussion in IETF fora, but the HTTP Working Group is aware of it.  It has been reviewed by the various review teams across the IETF.

## 3. Intellectual Property

TODO - [[ Confirm that each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Explain briefly the working group discussion about any IPR disclosures regarding this document, and summarize the outcome. ]]

## 4. Other Points

As Document Shepherd, I think Informational is appropriate for this document; it's not likely to cause harm, and it may do some good, but it hasn't been widely reviewed or implemented enough to make it standards-track.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-wilde-sunset-header-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single, new message header field will be registered as follows:

Header Field Name: Sunset
Template:
Protocol: http
Status: Standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the Link Relation Types registry on the Link Relations registry page located at:

https://www.iana.org/assignments/link-relations/

a single, new link relation type is to be registered as follows:

Relation Name: sunset
Description: Linking to a resource providing information about a resource's or service's retirement policy and/or information.
Reference: [ RFC-to-be ]
Notes:

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-11-20):

From: The IESG
To: IETF-Announce
CC: alexey.melnikov@isode.com, draft-wilde-sunset-header@ietf.org, mnot@mnot.net, Mark Nottingham
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Sunset HTTP Header) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'The Sunset HTTP Header'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-11-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This specification defines the Sunset HTTP response header field,
  which indicates that a URI is likely to become unresponsive at a
  specified point in the future.  It also defines a sunset link
  relation type that allows linking to resources providing information
  about an upcoming resource or service sunset.

Note to Readers

  This draft should be discussed on the ART mailing list
  ().

  Online access to all versions and files is available on GitHub
  ().




The file can be obtained via
https://datatracker.ietf.org/doc/draft-wilde-sunset-header/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-wilde-sunset-header/ballot/


No IPR declarations have been submitted directly on this I-D.

Note added 'Checking with HTTPBIS whether there are any objections to publish.

It is not clear whether this document needs to be Proposed Standard, Informational would suffice for a header field registration.'