< draft-wilde-sunset-header-07.txt   draft-wilde-sunset-header-11.txt >
Network Working Group E. Wilde Network Working Group E. Wilde
Internet-Draft CA Technologies Internet-Draft February 21, 2019
Intended status: Informational October 16, 2018 Intended status: Informational
Expires: April 19, 2019 Expires: August 25, 2019
The Sunset HTTP Header The Sunset HTTP Header Field
draft-wilde-sunset-header-07 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.
Note to Readers
This draft should be discussed on the ART mailing list
(<https://www.ietf.org/mailman/listinfo/art>).
Online access to all versions and files is available on GitHub
(<https://github.com/dret/I-D/tree/master/sunset-header>).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 19, 2019. This Internet-Draft will expire on August 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Temporary Resources . . . . . . . . . . . . . . . . . . . 3 1.1. Temporary Resources . . . . . . . . . . . . . . . . . . . 3
1.2. Migration . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Migration . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Retention . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Retention . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Sunset HTTP Response Header . . . . . . . . . . . . . . . 4 3. The Sunset HTTP Response Header Field . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. The Sunset Response Header . . . . . . . . . . . . . . . 6 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. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 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 18 skipping to change at page 3, line 8
scenarios for resource/service users. This specification does not scenarios for resource/service users. This specification does not
place any constraints on the nature of the linked resource, which can place any constraints on the nature of the linked resource, which can
be targeted at humans, at machines, or a combination of both. be targeted at humans, at machines, or a combination of both.
Possible scenarios for known lifetimes of resources include, but are Possible scenarios for known lifetimes of resources include, but are
not limited to the following scenarios. not limited to the following scenarios.
1.1. Temporary Resources 1.1. Temporary Resources
Some resources may have a limited lifetime by definition. For Some resources may have a limited lifetime by definition. For
example, a pending order represented by a resource may already list example, a pending shopping order represented by a resource may
all the details of the order, but may only exist for a limited time already list all order details, but may only exist for a limited time
unless it is confirmed and only then becomes permanent. In such a unless it is confirmed and only then becomes an acknowledged shopping
case, the service managing the pending order can make this limited order. In such a case, the service managing the pending shopping
lifetime explicit, allowing clients to understand that the pending order can make this limited lifetime explicit, allowing clients to
order, unless confirmed, will disappear at some point in time. understand that the pending order, unless confirmed, will disappear
at some point in time.
1.2. Migration 1.2. Migration
If resources are changing identity because a service migrates them, If resources are changing identity because a service migrates them,
then this may be known in advance. While it may not yet be then this may be known in advance. While it may not yet be
appropriate to use HTTP redirect status codes (3xx), it may be appropriate to use HTTP redirect status codes (3xx), it may be
interesting for clients to learn about the service's plan to take interesting for clients to learn about the service's plan to take
down the original resource. down the original resource.
1.3. Retention 1.3. Retention
skipping to change at page 3, line 45 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 Section 5 discusses how
the scope of the Sunset header field may change because of how a For the second stage (the API or a specific version of the API gets
resource is 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The Sunset HTTP Response Header 3. The Sunset HTTP Response Header Field
The Sunset HTTP response header field allows a server to communicate The Sunset HTTP response header field allows a server to communicate
the fact that a resource is expected to become unresponsive at a the fact that a resource is expected to become unresponsive at a
specific point in time. It provides information for clients which specific point in time. It provides information for clients which
they can use to control their usage of the resource. they can use to control their usage of the resource.
The Sunset header contains a single timestamp which advertises the The Sunset header field contains a single timestamp which advertises
point in time when the resource is expected to become unresponsive. the point in time when the resource is expected to become
The Sunset value is an HTTP-date timestamp, as defined in unresponsive. The Sunset value is an HTTP-date timestamp, as defined
Section 7.1.1.1 of [RFC7231], and SHOULD be a timestamp in the in Section 7.1.1.1 of [RFC7231], and SHOULD be a timestamp in the
future. future.
Timestamps in the past SHOULD be considered to mean the present time, It is safest to consider timestamps in the past mean the present
meaning that the resource is expected to become unavailable at any time, meaning that the resource is expected to become unavailable at
point in time. any time.
Sunset = HTTP-date Sunset = HTTP-date
For example For example
Sunset: Sat, 31 Dec 2018 23:59:59 GMT Sunset: Sat, 31 Dec 2018 23:59:59 GMT
Clients SHOULD treat Sunset timestamps as hints: It is not guaranteed Clients SHOULD treat Sunset timestamps as hints: It is not guaranteed
that the resource will in fact be available until that time, and will that the resource will in fact be available until that time, and will
not be available after that time. However, since this information is not be available after that time. However, since this information is
provided by the resource itself, it does have some credibility. provided by the resource itself, it does have some credibility.
After the Sunset time has arrived, it is likely that interactions After the Sunset time has arrived, it is likely that interactions
with the resource will result in client-side errors (HTTP 4xx status with the resource will result in client-side errors (HTTP 4xx status
codes), redirect responses (HTTP 3xx status codes), or the client codes), redirect responses (HTTP 3xx status codes), or the client
might not be able to interact with the resource at all. The Sunset might not be able to interact with the resource at all. The Sunset
header does not expose any information about which of those behaviors header field does not expose any information about which of those
can be expected. behaviors can be expected.
Clients not interpreting an existing Sunset header field can operate Clients not interpreting an existing Sunset header field can operate
as usual and simply may experience the resource becoming unavailable as usual and simply may experience the resource becoming unavailable
without getting any notification about it beforehand. without recognizing any notification about it beforehand.
4. Sunset and Caching 4. Sunset and Caching
It should be noted that the Sunset HTTP response header field serves It should be noted that the Sunset HTTP response header field serves
a different purpose than HTTP caching [RFC7234]. HTTP caching is a different purpose than HTTP caching [RFC7234]. HTTP caching is
concerned with making resource representations (i.e., represented concerned with making resource representations (i.e., represented
resource state) reusable, so that they can be more efficiently used. resource state) reusable, so that they can be used more efficiently.
This is achieved by using header fields that allow clients and This is achieved by using header fields that allow clients and
intermediaries to better understand when a resource representation intermediaries to better understand when a resource representation
can be reused, or when resource state (and thus the representation) can be reused, or when resource state (and thus the representation)
may have changed. may have changed.
The Sunset header field is not concerned with resource state at all. The Sunset header field is not concerned with resource state at all.
It only signals that a resource is expected to become unavailable at It only signals that a resource is expected to become unavailable at
a specific point in time. There are no assumptions about if, when, a specific point in time. There are no assumptions about if, when,
or how often a resource may change state in the meantime. or how often a resource may change state in the meantime.
For these reasons, the Sunset header field and HTTP caching should be For these reasons, the Sunset header field and HTTP caching should be
seen as complementary, and not as overlapping in scope and seen as complementary, and not as overlapping in scope and
functionality. 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 signalling 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.
5. Sunset Scope 5. Sunset Scope
The Sunset header field applies to the resource that returns it, The Sunset header field applies to the resource that returns it,
meaning that it announces the upcoming sunset of that specific meaning that it announces the upcoming sunset of that specific
resources. However, as discussed in Section Section 1.4, there may resource. However, as discussed in Section Section 1.4, there may be
be scenarios where the scope of the announced Sunset information it scenarios where the scope of the announced Sunset information it
larger than just the single resource where it appears. larger than just the single resource where it appears.
Resources are free to define such an increased scope, and usually Resources are free to define such an increased scope, and usually
this scope will be documented by the resource, so that consumers of this scope will be documented by the resource, so that consumers of
the resource know about the increased scope and can behave the resource know about the increased scope and can behave
accordingly. However, it is important to take into account that such accordingly. However, it is important to take into account that such
increased scoping is invisible for consumers who are unaware of the increased scoping is invisible for consumers who are unaware of the
increased scoping rules. This means that these consumers will not be increased scoping rules. This means that these consumers will not be
aware of the increased scope, and will not interpret Sunset aware of the increased scope, and will not interpret Sunset
information different from its standard meaning (i.e., it applies to information different from its standard meaning (i.e., it applies to
skipping to change at page 6, line 38 skipping to change at page 7, line 7
resource users can switch to alternative resources/services. resource users can switch to alternative resources/services.
Any information regarding the above issues (and possibly additional Any information regarding the above issues (and possibly additional
ones) can be made available through a URI that then can be linked to ones) can be made available through a URI that then can be linked to
using the sunset link relation type. This specification places no using the sunset link relation type. This specification places no
constraints on the scope or the type of the linked resource. The constraints on the scope or the type of the linked resource. The
scope can be for a resource or for a service. The type is determined scope can be for a resource or for a service. The type is determined
by the media type of the linked resource, and can be targeted at by the media type of the linked resource, and can be targeted at
humans, at machines, or a combination of both. humans, at machines, or a combination of both.
If the linked resource does provide machine-readable information,
consumers should be careful before acting on this information. Such
information may, for example, instruct consumers to use a migration
rule so that sunset resources can be accessed at new URIs. However,
this kind of information amounts to a possibly large-scale identity
migration of resources, so it is crucial that the migration
information is authentic and accurate.
7. IANA Considerations 7. IANA Considerations
7.1. The Sunset Response Header 7.1. The Sunset Response Header Field
The Sunset response header should be added to the permanent registry The Sunset response header field should be added to the permanent
of message header fields (see [RFC3864]), taking into account the registry of message header fields (see [RFC3864]), taking into
guidelines given by HTTP/1.1 [RFC7231]. account the guidelines given by HTTP/1.1 [RFC7231].
Header Field Name: Sunset Header Field Name: Sunset
Applicable Protocol: Hypertext Transfer Protocol (HTTP) Applicable Protocol: Hypertext Transfer Protocol (HTTP)
Status: Standard Status: Informational
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): RFC XXXX Specification document(s): RFC XXXX
7.2. The Sunset Link Relation Type 7.2. The Sunset Link Relation Type
The sunset link relation type should be added to the permanent The sunset link relation type should be added to the permanent
registry of link relation types according to Section 4.2 of RFC 8288 registry of link relation types according to Section 4.2 of RFC 8288
[RFC8288]: [RFC8288]:
Relation Name: sunset Relation Name: sunset
Description: Linking to a resource providing information about a Description: Identifies a resource that provides information about
resource's or service's retirement policy and/or information. the context's retirement policy.
Reference: RFC XXXX Reference: RFC XXXX
8. Implementation Status 8. Security Considerations
Note to RFC Editor: Please remove this section before publication.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 6982
[RFC6982]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.
According to RFC 6982, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Name: https://github.com/hskrasek/guzzle-sunset
Licensing: MIT
Organization: WeWork
Name: https://github.com/wework/faraday-sunset
Licensing: MIT
Description: A Ruby gem adding HTTP client middleware for
Sunset to Faraday
Organization: WeWork
Name: https://github.com/wework/rails-sunset
Licensing: MIT
Description: Create shortcuts for backend developers to use
Sunset (The Rails Way).
Organization: Tyk Technologies
Name: https://github.com/TykTechnologies/tyk
Licensing: Mozilla Public License Version 2.0
Description: Configurable HTTP header for API version expiry.
(GitHub issue [1])
9. Security Considerations Generally speaking, information about upcoming sunsets can leak
information that otherwise might not be available. For example, a
resource representing a registration can leak information about the
expiration date when it exposes sunset information. For this reason,
any use of sunset information where the sunset represents an
expiration or allows the calculation of another date (such as
calculating a creation date because it is known that resources expire
after one year) should be treated in the same way as if this
information would be made available directly in the resource's
representation.
The Sunset header field should be treated as a resource hint, meaning The Sunset header field SHOULD be treated as a resource hint, meaning
that the resource is indicating its potential retirement. The that the resource is indicating (and not guaranteeing with certainty)
definitive test whether or not the resource in fact is available or its potential retirement. The definitive test whether or not the
not will be to attempt to interact with it. Applications should resource in fact is available or not will be to attempt to interact
never treat an advertised Sunset date as a definitive prediction that with it. Applications should never treat an advertised Sunset date
is going to happen at the specified point in time. The Sunset as a definitive prediction that is going to happen at the specified
indication may have been inserted by an intermediary, or the point in time. The Sunset indication may have been inserted by an
advertised date may get changed or withdrawn by the resource owner. intermediary, or the advertised date may get changed or withdrawn by
the resource owner.
The main purpose of the Sunset header field is to signal intent, so The main purpose of the Sunset header field is to signal intent, so
that applications using resources may get a warning ahead of time and that applications using resources may get a warning ahead of time and
can react accordingly. What an appropriate reaction is (such as can react accordingly. What an appropriate reaction is (such as
switching to a different resource or service), what it will be based switching to a different resource or service), what it will be based
on (such as machine-readable formats that allow the switching to be on (such as machine-readable formats that allow the switching to be
done automatically), and when it will happen (such as ahead of the done automatically), and when it will happen (such as ahead of the
advertised date or only when the resource in fact becomes advertised date or only when the resource in fact becomes
unavailable) is outside the scope of this specification. unavailable) is outside the scope of this specification.
10. Example 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.
9. Example
Assuming that a resource has been created in an archive that for Assuming that a resource has been created in an archive that for
management or compliance reasons only stores resources for two years, management or compliance reasons stores resources for ten years, and
and permanently deletes them afterwards, then the Sunset header field permanently deletes them afterwards, then the Sunset header field can
can be used to expose this information. If such a resource has been be used to expose this information. If such a resource has been
created on November 11, 2016, then the following header field can be created on November 11, 2016, then the following header field can be
included in responses: included in responses:
Sunset: Fri, 11 Nov 2018 11:11:11 GMT Sunset: Fri, 11 Nov 2026 11:11:11 GMT
This allows clients that are aware of the Sunset header field to This allows clients that are aware of the Sunset header field to
understand that the resource likely will become unavailable at the understand that the resource likely will become unavailable at the
specified point in time. Clients can decide to ignore this specified point in time. Clients can decide to ignore this
information, adjust their own behavior accordingly, or alert information, adjust their own behavior accordingly, or alert
applications or users about this timestamp. applications or users about this timestamp.
Even though the Sunset header information is made available by the Even though the Sunset header field is made available by the resource
resource itself, there is no guarantee that the resource indeed will itself, there is no guarantee that the resource indeed will become
become unavailable, and if so, how the response will look like for unavailable, and if so, how the response will look like for requests
requests made after that timestamp. In case of the archive used as made after that timestamp. In case of the archive used as an example
an example here, the resource indeed may be permanently deleted, and here, the resource indeed may be permanently deleted, and requests
requests for the URI after the Sunset timestamp may receive a "410 for the URI after the Sunset timestamp may receive a "410 Gone" HTTP
Gone" HTTP response. (This is assuming that the archive keeps track response. (This is assuming that the archive keeps track of the URIs
of the URIs that it had previously assigned; if not, the response may that it had previously assigned; if not, the response may be a more
be a more generic "404 Not Found".) generic "404 Not Found".)
11. References Before the Sunset header field even appears for the first time (it
may not appear from the very beginning), it is possible that the
resource (or possibly just the "home" resource of the service
context) communicates its sunset policy by using the sunset link
relation. If communicated as an HTTP header field, it might look as
following:
11.1. Normative References Link: <http://example.net/sunset>;rel="sunset";type="text/html"
In this case, the linked resource provides sunset policy information
about the service context. It may be documentation aimed at
developers, for example informing them that the lifetime of a certain
class of resources is ten years after creation, and that Sunset
header fields will be served as soon as the sunset date is less than
some given period of time. It may also inform developers whether the
service will respond with 410 or 404 after the sunset time, as
discussed above.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
11.2. Informative References 10.2. Informative References
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, July
2013.
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June
2014. 2014.
11.3. URIs
[1] https://github.com/TykTechnologies/tyk/issues/1626
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks for comments and suggestions provided by Phil Sturgeon and Thanks for comments and suggestions provided by Ben Campbell, Alissa
Asbjoern Ulsberg. Cooper, Benjamin Kaduk, Mirja Kuhlewind, Adam Roach, Phil Sturgeon,
and Asbjorn Ulsberg.
Author's Address Author's Address
Erik Wilde Erik Wilde
CA Technologies
Email: erik.wilde@dret.net Email: erik.wilde@dret.net
URI: http://dret.net/netdret/ URI: http://dret.net/netdret/
 End of changes. 39 change blocks. 
158 lines changed or deleted 164 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/