The Sunset HTTP Header Field
RFC 8594
| Document | Type |
RFC - Informational
(May 2019; No errata)
Was draft-wilde-sunset-header (individual in art area)
|
|
|---|---|---|---|
| Last updated | 2019-05-15 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | Mark Nottingham | ||
| Shepherd write-up | Show (last changed 2018-11-29) | ||
| IESG | IESG state | RFC 8594 (Informational) | |
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Alexey Melnikov | ||
| IESG note |
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. |
||
| Send notices to | Mark Nottingham <mnot@mnot.net> | ||
| IANA | IANA review state | IANA OK - Actions Needed | |
| IANA action state | RFC-Ed-Ack | ||
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
Table of Contents
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
As a general rule, URIs should be stable and persistent so that
applications can use them as stable and persistent identifiers for
resources. However, there are many scenarios where, for a variety of
reasons, URIs have a limited lifetime. In some of these scenarios,
this limited lifetime is known in advance. In this case, it can be
useful for clients if resources make this information about their
limited lifetime known. 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.
This specification also defines a sunset link relation type that
allows information to be provided about 1) the sunset policy of a
resource or a service, and/or 2) upcoming sunsets, and/or 3) possible
mitigation scenarios for resource/service users. This specification
does not place any constraints on the nature of the linked resource,
which can be targeted to humans, machines, or both.
Possible scenarios for known lifetimes of resources include, but are
not limited to, the following scenarios.
Wilde Informational [Page 2]
RFC 8594 Sunset Header May 2019
1.1. Temporary Resources
Some resources may have a limited lifetime by definition. For
Show full document text