< draft-wilde-sunset-header-10.txt   draft-wilde-sunset-header-11.txt >
Network Working Group E. Wilde Network Working Group E. Wilde
Internet-Draft January 11, 2019 Internet-Draft February 21, 2019
Intended status: Informational Intended status: Informational
Expires: July 15, 2019 Expires: August 25, 2019
The Sunset HTTP Header Field The Sunset HTTP Header Field
draft-wilde-sunset-header-10 draft-wilde-sunset-header-11
Abstract Abstract
This specification defines the Sunset HTTP response header field, This specification defines the Sunset HTTP response header field,
which indicates that a URI is likely to become unresponsive at a which indicates that a URI is likely to become unresponsive at a
specified point in the future. It also defines a sunset link specified point in the future. It also defines a sunset link
relation type that allows linking to resources providing information relation type that allows linking to resources providing information
about an upcoming resource or service sunset. about an upcoming resource or service sunset.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 15, 2019. This Internet-Draft will expire on August 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
4. Sunset and Caching . . . . . . . . . . . . . . . . . . . . . 5 4. Sunset and Caching . . . . . . . . . . . . . . . . . . . . . 5
5. Sunset Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Sunset Scope . . . . . . . . . . . . . . . . . . . . . . . . 5
6. The Sunset Link Relation Type . . . . . . . . . . . . . . . . 6 6. The Sunset Link Relation Type . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. The Sunset Response Header Field . . . . . . . . . . . . 7 7.1. The Sunset Response Header Field . . . . . . . . . . . . 7
7.2. The Sunset Link Relation Type . . . . . . . . . . . . . . 7 7.2. The Sunset Link Relation Type . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
As a general rule, URIs should be stable and persistent, so that As a general rule, URIs should be stable and persistent, so that
applications can use them as stable and persistent identifiers for applications can use them as stable and persistent identifiers for
resources. However, there are many scenarios where for a variety of resources. However, there are many scenarios where for a variety of
reasons, URIs have a limited lifetime. In some of these scenarios, reasons, URIs have a limited lifetime. In some of these scenarios,
this limited lifetime is known in advance. In this case, it can be this limited lifetime is known in advance. In this case, it can be
skipping to change at page 3, line 36 skipping to change at page 3, line 36
There are many cases where regulation or legislation require that There are many cases where regulation or legislation require that
resources are kept available for a certain amount of time. However, resources are kept available for a certain amount of time. However,
in many cases there also is a requirement for those resources to be in many cases there also is a requirement for those resources to be
permanently deleted after some period of time. Since the deletion of permanently deleted after some period of time. Since the deletion of
the resource in this scenario is governed by well-defined rules, it the resource in this scenario is governed by well-defined rules, it
could be made explicit for clients interacting with the resource. could be made explicit for clients interacting with the resource.
1.4. Deprecation 1.4. Deprecation
For Web APIs one standard scenario is that an API or specific subsets For Web APIs one standard scenario is that an API or specific subsets
of an API may get deprecated. If this is planned in advance, then of an API may get deprecated. Deprecation often happens in two
for the time before the actual deprecation is rolled out, the stages, with the first stage being that the API is not the preferred
resources that will be affected by the deprecation can make the date or recommended version anymore, and the second stage being that the
of their deprecation known. This allows consumers of the API to be API or a specific version of the API gets decommissioned.
notified of the upcoming deprecation.
In this scenario, the announced sunset date typically affects the For the first stage (the API is not the preferred or recommended
whole API or parts of it (i.e., sets of resources), and not just a version anymore), the Sunset header field is not appropriate, because
single resource. In this case, it makes sense for the API to define at this stage, the API remains operational and can still be used.
rules how an announced sunset on a specific resource (such as the Other mechanisms can be used for signaling that first stage that
API's home/start resource) implies the sunsetting of the whole API or might help with more visible deprecation management, but the Sunset
parts of it (i.e., sets of resources), and not just the resource header is not appropriate.
returning the sunset header field. Section 5 discusses how the scope
of the Sunset header field may change because of how a resource is For the second stage (the API or a specific version of the API gets
using it. decommissioned), the Sunset header field is appropriate, because that
is when the API or a version does become unresponsive. From the
Sunset header field's point of view, it does not matter that the API
may have been not the preferred or recommended version anymore. The
only thing that matters is that it will become unresponsive and that
this time can be advertised using the Sunset header field.
In this scenario, the announced sunset date typically affects all of
the deprecated API or parts of it (i.e., just deprecated sets of
resources), and not just a single resource. In this case, it makes
sense for the API to define rules how an announced sunset on a
specific resource (such as the API's home/start resource) implies the
sunsetting of the whole API or parts of it (i.e., sets of resources),
and not just the resource returning the sunset header field.
Section 5 discusses how the scope of the Sunset header field may
change because of how a resource is using it.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. The Sunset HTTP Response Header Field 3. The Sunset HTTP Response Header Field
 End of changes. 7 change blocks. 
19 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/