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 pdf html 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