Internet Engineering Task Force (IETF) E. Wilde Request for Comments: 8594 May 2019 Category: Informational ISSN: 2070-1721 The Sunset HTTP Header Field 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. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8594. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Wilde Informational [Page 1]
RFC 8594 Sunset Header May 2019 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Temporary Resources . . . . . . . . . . . . . . . . . . . 3 1.2. Migration . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Retention . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Sunset HTTP Response Header Field . . . . . . . . . . . . 4 4. Sunset and Caching . . . . . . . . . . . . . . . . . . . . . 5 5. Sunset Scope . . . . . . . . . . . . . . . . . . . . . . . . 6 6. The Sunset Link Relation Type . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.1. The Sunset Response Header Field . . . . . . . . . . . . 7 7.2. The Sunset Link Relation Type . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1 . Introduction Wilde Informational [Page 2]
RFC 8594 Sunset Header May 2019 Section 5 discusses how the scope of the Sunset header field may change because of how a resource is using it. 2 . Terminology BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3 . The Sunset HTTP Response Header Field Section 7.1.1.1 of [RFC7231], and SHOULD be a timestamp in the future. It is safest to consider timestamps in the past mean the present time, meaning that the resource is expected to become unavailable at any time. Sunset = HTTP-date For example: Sunset: Sat, 31 Dec 2018 23:59:59 GMT Wilde Informational [Page 4]
RFC 8594 Sunset Header May 2019 4 . Sunset and Caching RFC7234]. HTTP caching is concerned with making resource representations (i.e., represented resource state) reusable so that they can be used more efficiently. This is achieved by using header fields that allow clients and intermediaries to better understand when a resource representation can be reused or when resource state (and, thus, the representation) may have changed. The Sunset header field is not concerned with resource state at all. It only signals that a resource is expected to become unavailable at a specific point in time. There are no assumptions about if, when, or how often a resource may change state in the meantime. For these reasons, the Sunset header field and HTTP caching should be seen as complementary and not as overlapping in scope and functionality. This also means that applications acting as intermediaries, such as search engines or archives that make resources discoverable, should treat Sunset information differently from caching information. These applications may use Sunset information for signaling to users that a resource may become unavailable. But they still have to account for the fact that resource state can change in the meantime and that Sunset information is a hint and, thus, future resource availability may differ from the advertised timestamp. Wilde Informational [Page 5]
RFC 8594 Sunset Header May 2019 5 . Sunset Scope Section 1.4, there may be scenarios where the scope of the announced Sunset information is larger than just the single resource where it appears. Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of the resource know about the increased scope and can behave accordingly. However, it is important to take into account that such increased scoping is invisible for consumers who are unaware of the increased scoping rules. This means that these consumers will not be aware of the increased scope, and they will not interpret Sunset information different from its standard meaning (i.e., it applies to the resource only). Using such an increased scope still may make sense, as Sunset information is only a hint anyway; thus, it is optional information that cannot be depended on, and clients should always be implemented in ways that allow them to function without Sunset information. Increased scope information may help clients to glean additional hints from resources (e.g., concluding that an API is being deprecated because its home/start resource announces a Sunset) and, thus, might allow them to implement behavior that allows them to make educated guesses about resources becoming unavailable. 6 . The Sunset Link Relation Type Wilde Informational [Page 6]
RFC 8594 Sunset Header May 2019 7 . IANA Considerations 7.1 . The Sunset Response Header Field RFC3864]), taking into account the guidelines given by HTTP/1.1 [RFC7231]. Header Field Name: Sunset Protocol: http Status: informational Author/Change controller: IETF Reference: RFC 8594 Wilde Informational [Page 7]
RFC 8594 Sunset Header May 2019 9 . Example Wilde Informational [Page 9]