< draft-wilde-sunset-header-08.txt		draft-wilde-sunset-header-11.txt >
	Network Working Group E. Wilde		Network Working Group E. Wilde
	Internet-Draft November 29, 2018		Internet-Draft February 21, 2019
	Intended status: Informational		Intended status: Informational
	Expires: June 2, 2019		Expires: August 25, 2019
	The Sunset HTTP Header		The Sunset HTTP Header Field
	draft-wilde-sunset-header-08		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 June 2, 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. 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 . . . . . . . . . . . . . . . . . . 9		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		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
	useful for clients if resources make this information about their		useful for clients if resources make this information about their
	limited lifetime known. This specification defines the Sunset HTTP		limited lifetime known. This specification defines the Sunset HTTP
	skipping to change at page 3, line 8 ¶		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 35 ¶		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
	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 45 ¶		skipping to change at page 7, line 17 ¶
	If the linked resource does provide machine-readable information,		If the linked resource does provide machine-readable information,
	consumers should be careful before acting on this information. Such		consumers should be careful before acting on this information. Such
	information may, for example, instruct consumers to use a migration		information may, for example, instruct consumers to use a migration
	rule so that sunset resources can be accessed at new URIs. However,		rule so that sunset resources can be accessed at new URIs. However,
	this kind of information amounts to a possibly large-scale identity		this kind of information amounts to a possibly large-scale identity
	migration of resources, so it is crucial that the migration		migration of resources, so it is crucial that the migration
	information is authentic and accurate.		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: Informational		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
	skipping to change at page 7, line 33 ¶		skipping to change at page 8, line 6 ¶
	Reference: RFC XXXX		Reference: RFC XXXX
	8. Security Considerations		8. Security Considerations
	Generally speaking, information about upcoming sunsets can leak		Generally speaking, information about upcoming sunsets can leak
	information that otherwise might not be available. For example, a		information that otherwise might not be available. For example, a
	resource representing a registration can leak information about the		resource representing a registration can leak information about the
	expiration date when it exposes sunset information. For this reason,		expiration date when it exposes sunset information. For this reason,
	any use of sunset information where the sunset represents an		any use of sunset information where the sunset represents an
	expiration or allows the calculation of another date (such as		expiration or allows the calculation of another date (such as
	calculating a creation date because it is known that resource expire		calculating a creation date because it is known that resources expire
	after one year) should be treated in the same way as if this		after one year) should be treated in the same way as if this
	information would be made available directly in the resource's		information would be made available directly in the resource's
	representation.		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.
	In cases where a sunset policy is linked by using the sunset link		In cases where a sunset policy is linked by using the sunset link
	relation type, clients should be careful about taking any actions		relation type, clients SHOULD be careful about taking any actions
	based on this information. It should be verified that the		based on this information. It SHOULD be verified that the
	information is authentic and accurate. Furthermore, it should be		information is authentic and accurate. Furthermore, it SHOULD be
	tested that this information is only applied to resources that are		tested that this information is only applied to resources that are
	within the scope of the policy, making sure that sunset policies		within the scope of the policy, making sure that sunset policies
	cannot "hijack" resources by for example providing migration		cannot "hijack" resources by for example providing migration
	information for them.		information for them.
	9. Example		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 stores resources for ten years, and		management or compliance reasons stores resources for ten years, and
	permanently deletes them afterwards, then the Sunset header field can		permanently deletes them afterwards, then the Sunset header field can
	skipping to change at page 8, line 34 ¶		skipping to change at page 9, line 8 ¶
	included in responses:		included in responses:
	Sunset: Fri, 11 Nov 2026 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".)
	Before the Sunset header even appears for the first time (it may not		Before the Sunset header field even appears for the first time (it
	appear fro the very beginning), it is possible that the resource (or		may not appear from the very beginning), it is possible that the
	possibly just the "home" resource of the service context)		resource (or possibly just the "home" resource of the service
	communicates its sunset policy by using the sunset link relation. If		context) communicates its sunset policy by using the sunset link
	communicated as an HTTP header field, it might look as following:		relation. If communicated as an HTTP header field, it might look as
			following:
	Link: <http://example.net/sunset>;rel="sunset";type="text/html"		Link: <http://example.net/sunset>;rel="sunset";type="text/html"
	In this case, the linked resource provides sunset policy information		In this case, the linked resource provides sunset policy information
	about the service context. It may be documentation aimed at		about the service context. It may be documentation aimed at
	developers, for example informing them that the lifetime of a certain		developers, for example informing them that the lifetime of a certain
	class of resources is ten years after creation, and that Sunset		class of resources is ten years after creation, and that Sunset
	headers will be served as soon as the sunset date is less than some		header fields will be served as soon as the sunset date is less than
	given period of time. It may also inform developers whether the		some given period of time. It may also inform developers whether the
	service will respond with 410 or 404 after the sunset time, as		service will respond with 410 or 404 after the sunset time, as
	discussed above.		discussed above.
	10. References		10. References
	10.1. Normative 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>.
	10.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.
	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
	Email: erik.wilde@dret.net		Email: erik.wilde@dret.net
	URI: http://dret.net/netdret/		URI: http://dret.net/netdret/
End of changes. 33 change blocks.
	86 lines changed or deleted		117 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/