idnits 2.17.1 draft-wilde-sunset-header-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 3, 2016) is 3004 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7231 (ref. '3') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7234 (ref. '4') (Obsoleted by RFC 9111) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Wilde 3 Internet-Draft February 3, 2016 4 Intended status: Standards Track 5 Expires: August 6, 2016 7 The Sunset HTTP Header 8 draft-wilde-sunset-header-01 10 Abstract 12 This specification defines the Sunset HTTP response header field, 13 which indicates that a URI is likely to become unresponsive at a 14 specified point in the future. 16 Note to Readers 18 This draft should be discussed on the apps-discuss mailing list [1]. 20 Online access to all versions and files is available on GitHub [2]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 6, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. The Sunset HTTP Response Header . . . . . . . . . . . . . . . 3 59 4. Sunset and Caching . . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. The Sunset Response Header . . . . . . . . . . . . . . . 4 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 6 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 10.2. Non-Normative References . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 As a general rule, URIs should be stable and persistent, so that 75 applications can use them as stable and persistent identifiers for 76 resources. However, there are many scenarios where for a variety of 77 reasons, URIs have a limited lifetime. In some of these scenarios, 78 this limited lifetime is known in advance. In this case, it can be 79 useful for clients if resources make this information about their 80 limited lifetime known. This specification defines the Sunset HTTP 81 response header field, which indicates that a URI is likely to become 82 unresponsive at some point in the future. 84 Possible scenarios for known lifetimes of resources include, but are 85 not limited to the following: 87 Temporary Resources: Some resources may have a limited lifetime by 88 definition. For example, a pending order represented by a 89 resource may already list all the details of the order, but may 90 only exist for a limited time unless it is confirmed and only then 91 becomes permanent. In such a case, the service managing the 92 pending order can make this limited lifetime explicit, allowing 93 clients to understand that the pending order, unless confirmed, 94 will disappear at some point in time. 96 Migration: If resources are changing identity because a service 97 migrates them, then this may be known in advance. While it may 98 not yet be appropriate to use HTTP redirect status codes (3xx), it 99 may be interesting for clients to learn about the service's plan 100 to take down the original resource. 102 Retention: There are many cases where regulation or legislation 103 require that resources are kept available for a certain amount of 104 time. However, in many cases there also is a requirement for 105 those resources to be permanently deleted after some period of 106 time. Since the deletion of the resource in this scenario is 107 governed by well-defined rules, it could be made explicit for 108 clients interacting with the resource. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [1]. 116 3. The Sunset HTTP Response Header 118 The Sunset HTTP response header field allows a server to communicate 119 the fact that a resource is expected to become unresponsive at a 120 specific point in time. It provides information for clients which 121 they can use to control their usage of the resource. 123 The Sunset header contains a single timestamp which advertises the 124 point in time when the resource is expected to become unresponsive. 125 The Sunset value is an HTTP-date timestamp, as defined in 126 Section 7.1.1.1 of [3]. 128 Sunset = HTTP-date 130 For example 132 Sunset: Sat, 31 Dec 2016 23:59:59 GMT 134 Clients SHOULD treat Sunset timestamps as hints: It is not guaranteed 135 that the resource will in fact be available until that time, and will 136 not be available after that time. However, since this information is 137 provided by the resource itself, it does have some credibility. 139 After the Sunset time has arrived, it is likely that interactions 140 with the resource will either results in client-side errors (HTTP 4xx 141 status codes), or redirect responses (HTTP 3xx status codes). The 142 Sunset header does not expose any information about which of those 143 two behaviors can be expected. 145 Clients not interpreting an existing Sunset header field can operate 146 as usual and simply may experience the resource becoming unavailable 147 without getting any notification about it beforehand. 149 4. Sunset and Caching 151 It should be noted that the Sunset HTTP response header field serves 152 a different purpose than HTTP caching [4]. HTTP caching is concerned 153 with making resource representations (i.e., represented resource 154 state) reusable, so that they can be more efficiently used. This is 155 achieved by using header fields that allow clients and intermediaries 156 to better understand when a resource representation can be reused, or 157 when resource state (and thus the representation) may have changed. 159 The Sunset header field is not concerned with resource state at all. 160 It only signals that a resource is expected to become unavailable at 161 a specific point in time. There are no assumptions about if, when, 162 or how often a resource may change state in the meantime. 164 For these reasons, the Sunset header field and HTTP caching should be 165 seen as complementary, and not as overlapping in scope and 166 functionality. 168 5. IANA Considerations 170 5.1. The Sunset Response Header 172 The Sunset response header should be added to the permanent registry 173 of message header fields (see [2]), taking into account the 174 guidelines given by HTTP/1.1 [3]. 176 Header Field Name: Sunset 178 Applicable Protocol: Hypertext Transfer Protocol (HTTP) 180 Status: Standard 182 Author/Change controller: IETF 184 Specification document(s): RFC XXXX 186 6. Security Considerations 188 ... 190 7. Example 192 Assuming that a resource has been created in an archive that for 193 management or compliance reason only stores resources for two years, 194 and permanently deletes them afterwards, then the Sunset header field 195 can be used to expose this information. If such a resource has been 196 created on November 11, 2014, then the following header field can be 197 included in responses: 199 Sunset: Fri, 11 Nov 2016 11:11:11 GMT 201 This allows clients that are aware of the Sunset header field to 202 understand that the resource likely will become unavailable at this 203 point in time. Clients can decide to ignore this information, adjust 204 their own behavior accordingly, or even alert users about this 205 timestamp. 207 Even though the Sunset header information is made available by the 208 resource itself, there is no guarantee that the resource indeed will 209 become unavailable, and if so, how the response will look like for 210 requests made after that timestamp. In case of the archive used as 211 an example here, the resource indeed may be permanently deleted, and 212 requests for the URI after the Sunset timestamp may receive a "410 213 Gone" HTTP response. (This is assuming that the archive keeps track 214 of the URIs it has assigned; if not, the response may be a more 215 generic "404 Not Found".) 217 8. Open Issues 219 Note to RFC Editor: Please remove this section before publication. 221 o Human readable explanation: It would be possible to include human- 222 readable information about the reason for the URI's disappearance. 223 This could either be done inline (probably just a simple string), 224 and/or by reference to a URI that will dereference to human- 225 readable information. 227 o Machine-readable explanation: It would be possible to include 228 machine-readable information about the reason for the URI's 229 disappearance. This could either be done inline (maybe name/value 230 pairs), and/or by reference to a URI that will dereference to 231 machine-readable information. 233 o New URI: If the resource's new URI is known (for example when a 234 service is migrating in a way that invalidates existing URIs, but 235 has a plan of how these will map to new URIs), then that URI could 236 be advertised in advance (i.e., it's not yet a 3xx, but clients 237 might want to start working with the new URI anyway). 239 o Timestamp in the past: Should it be allowed to have timestamps in 240 the past? Maybe either disallow them, or specifically allow them 241 and explain what they mean, for example the fact that a resource 242 that now is redirecting can expose information about when it 243 changed from being the primary resource to being the redirection. 245 9. Change Log 247 Note to RFC Editor: Please remove this section before publication. 249 9.1. From -00 to -01 251 o Fixing Typos. 253 10. References 255 10.1. Normative References 257 [1] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", RFC 2119, March 1997. 260 [2] Klyne, G., Nottingham, M., and J. Mogul, "Registration 261 Procedures for Message Header Fields", BCP 90, RFC 3864, 262 September 2004. 264 [3] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 265 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 267 10.2. Non-Normative References 269 [4] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 270 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 271 2014. 273 Author's Address 275 Erik Wilde 277 Email: erik.wilde@dret.net 278 URI: http://dret.net/netdret/