< draft-ietf-httpbis-targeted-cache-control-00.txt		draft-ietf-httpbis-targeted-cache-control-01.txt >
	HTTP S. Ludin		HTTP S. Ludin
	Internet-Draft Akamai		Internet-Draft Akamai
	Intended status: Standards Track M. Nottingham		Intended status: Standards Track M. Nottingham
	Expires: 27 January 2022 Fastly		Expires: 24 March 2022 Fastly
	Y. Wu		Y. Wu
	Cloudflare		Cloudflare
	26 July 2021		20 September 2021
	Targeted HTTP Cache Control		Targeted HTTP Cache Control
	draft-ietf-httpbis-targeted-cache-control-00		draft-ietf-httpbis-targeted-cache-control-01
	Abstract		Abstract
	This specification defines a convention for HTTP response header		This specification defines a convention for HTTP response header
	fields that allow directives controlling caching to be targeted at		fields that allow directives controlling caching to be targeted at
	specific caches or classes of caches. It also defines one such		specific caches or classes of caches. It also defines one such
	header field, targeted at Content Delivery Network (CDN) caches.		header field, targeted at Content Delivery Network (CDN) caches.
	Note to Readers		Note to Readers
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 27 January 2022.		This Internet-Draft will expire on 24 March 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Targeted Cache-Control Header Fields . . . . . . . . . . . . 3		2. Targeted Cache-Control Header Fields . . . . . . . . . . . . 3
	2.1. Cache Behavior . . . . . . . . . . . . . . . . . . . . . 3		2.1. Cache Behavior . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Parsing Targeted Fields . . . . . . . . . . . . . . . . . 4		2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Defining Targeted Fields . . . . . . . . . . . . . . . . 5		2.3. Interaction with HTTP Freshness . . . . . . . . . . . . . 6
	3. The CDN-Cache-Control Targeted Field . . . . . . . . . . . . 5		2.4. Defining Targeted Fields . . . . . . . . . . . . . . . . 7
	3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6		3. The CDN-Cache-Control Targeted Field . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. Normative References . . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
			6.1. Normative References . . . . . . . . . . . . . . . . . . 8
			6.2. Informative References . . . . . . . . . . . . . . . . . 9
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Modern deployments of HTTP often use multiple layers of caching with		Modern deployments of HTTP often use multiple layers of caching with
	varying properties. For example, a Web site might use a cache on the		varying properties. For example, a Web site might use a cache on the
	origin server itself; it might deploy a caching layer in the same		origin server itself; it might deploy a caching layer in the same
	network as the origin server, it might use one or more Content		network as the origin server, it might use one or more Content
	Delivery Networks (CDNs) that are distributed throughout the		Delivery Networks (CDNs) that are distributed throughout the
	Internet, and it might utilise browser caching as well.		Internet, and it might utilise browser caching as well.
	Because it is often desirable to control these different classes of		Because it is often desirable to control these different classes of
	caches separately, some means of targeting directives at them is		caches separately, some means of targeting directives at them is
	necessary.		necessary.
	The HTTP Cache-Control response header field is widely used to direct		The HTTP Cache-Control response header field is widely used to direct
	caching behavior. However, it is relatively undifferentiated; while		caching behavior. However, it is relatively undifferentiated; while
	some directives (e.g., s-maxage) are targeted at a specific class of		some directives (e.g., s-maxage) are targeted at a specific class of
	caches (for s-maxage, shared caches), that is not consistently		caches (for s-maxage, shared caches), targeting is not consistently
	available across all existing cache directives (e.g., stale-while-		available across all existing cache directives (e.g., stale-while-
	revalidate). This is problematic, especially as the number of		revalidate). This is problematic, especially as the number of
	caching extensions grows, along with the number of potential targets.		caching extensions grows, along with the number of potential targets.
	Some caches have defined ad hoc control mechanisms to overcome this		Some implementations have defined ad hoc control mechanisms to
	issue, but interoperability is low. Section 2 defines a standard		overcome this issue, but their interoperability is low. Section 2
	framework for targeted cache control using HTTP response headers, and		defines a standard framework for targeted cache control using HTTP
	Section 3 defines one such header: the CDN-Cache-Control response		response headers, and Section 3 defines one such header: the CDN-
	header field.		Cache-Control response header field.
	1.1. Notational Conventions		1.1. Notational Conventions
	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.
	2. Targeted Cache-Control Header Fields		2. Targeted Cache-Control Header Fields
	A Targeted Cache-Control Header Field (hereafter, "targeted field")		A Targeted Cache-Control Header Field (hereafter, "targeted field")
	is a HTTP response header field that has the same syntax and		is a HTTP response header field that has the same semantics as the
	semantics as the Cache-Control response header field		Cache-Control response header field ([HTTP-CACHING], Section 5.2).
	[I-D.ietf-httpbis-cache], Section 5.2. However, it has a distinct		However, it has a distinct field name that indicates the target for
	field name that indicates the target for its directives.		its directives.
	For example:		For example:
	CDN-Cache-Control: max-age=60		CDN-Cache-Control: max-age=60
	is a targeted field that applies to Content Delivery Networks (CDNs),		is a targeted field that applies to Content Delivery Networks (CDNs),
	as defined in Section 3.		as defined in Section 3.
	2.1. Cache Behavior		2.1. Cache Behavior
	A cache that implement this specification has a _target list_ - an		A cache that implement this specification maintains a _target list_ -
	ordered list of the targeted field names that it uses for caching		an ordered list of the targeted field names that it uses for caching
	policy, with the order reflecting priority from most applicable to		policy, with the order reflecting priority from most applicable to
	least. The target list might be fixed, user-configurable, or		least. The target list might be fixed, user-configurable, or
	generated per request, depending upon the implementation.		generated per request, depending upon the implementation.
	For example, a CDN cache might support both CDN-Cache-Control and a		For example, a CDN cache might support both CDN-Cache-Control and a
	header specific to that CDN, ExampleCDN-Cache-Control, with the		header specific to that CDN, ExampleCDN-Cache-Control, with the
	latter overriding the former. Its target list would be:		latter overriding the former. Its target list would be:
	[ExampleCDN-Cache-Control, CDN-Cache-Control]		[ExampleCDN-Cache-Control, CDN-Cache-Control]
	When a cache that implements this specification receives a response		When a cache that implements this specification receives a response
	with one or more of of the header field names on its target list, the		with one or more of of the header field names on its target list, the
	cache MUST select the first (in target list order) field with a		cache MUST select the first (in target list order) field with a
	valid, non-empty value and use that to determine the caching policy		valid, non-empty value and use its value to determine the caching
	for the response, and MUST ignore the Cache-Control and Expires		policy for the response, and MUST ignore the Cache-Control and
	header fields in that response, unless no valid, non-empty value is		Expires header fields in that response, unless no valid, non-empty
	available from the listed header fields.		value is available from the listed header fields.
	Note that this is on a response-by-response basis; if no applicable		Note that this occurs on a response-by-response basis; if no member
	targeted field is present, valid and non-empty, a cache falls back to		of the cache's target list is present, valid and non-empty, a cache
	other cache control mechanisms as required by HTTP		falls back to other cache control mechanisms as required by HTTP
	[I-D.ietf-httpbis-cache].		[HTTP-CACHING].
	Targeted fields that are not on a cache's target list MUST NOT change		Targeted fields that are not on a cache's target list MUST NOT change
	that cache's behaviour, and MUST be passed through.		that cache's behaviour, and MUST be passed through.
	Caches that use a targeted field MUST implement the semantics of the		Caches that use a targeted field MUST implement the semantics of the
	following cache directives:		following cache directives:
	* max-age		* max-age
	* must-revalidate		* must-revalidate
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 46 ¶
	* no-cache		* no-cache
	* private		* private
	Furthermore, they SHOULD implement other cache directives (including		Furthermore, they SHOULD implement other cache directives (including
	extension cache directives) that they support in the Cache-Control		extension cache directives) that they support in the Cache-Control
	response header field.		response header field.
	The semantics and precedence of cache directives in a targeted field		The semantics and precedence of cache directives in a targeted field
	are the same as those in Cache-Control. In particular, no-store and		are the same as those in Cache-Control. In particular, no-store and
	no-cache make max-age inoperative.		no-cache make max-age inoperative, and unrecognised extension
			directives are ignored.
	2.2. Parsing Targeted Fields		2.2. Syntax
	Targeted fields MAY be parsed as a Dictionary Structured Field		Targeted fields are defined as Dictionary Structured Fields
	[RFC8941], and implementations are encouraged to use a parser for		(Section 3.2 of [STRUCTURED-FIELDS]). Each member of the dictionary
	that format in the interests of robustness, interoperability and		is a cache directive from the Hypertext Transfer Protocol (HTTP)
	security.		Cache Directive Registry.
	When an implementation parses a targeted field as a Structured Field,		Because cache directives are not defined in terms of structured data
	each cache directive will be assigned a value. For example, max-age		types, it is necessary to map their values into the appropriate
	has an integer value; no-store's value is boolean true, and no-		types. Typically, they are mapped into a Boolean (Section 3.3.6 of
	cache's value can either be boolean true or a list of field names.		[STRUCTURED-FIELDS]) when the member has no separate value, a Token
	Implementations SHOULD NOT accept other values (e.g. coerce a max-age		(Section 3.3.4 of [STRUCTURED-FIELDS]) for alphanumeric values, a
	with a decimal value into an integer). Likewise, implementations		String (Section 3.3.3 of [STRUCTURED-FIELDS]) for quote-delimited
	SHOULD ignore parameters on directives, unless otherwise specified.		values, or an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) for
			purely numeric values.
	However, implementers MAY reuse a Cache-Control parser for		For example, the max-age directive (Section 5.2.2.1 of
	simplicity. If they do so, they SHOULD observe the following points,		[HTTP-CACHING]) has an integer value; no-store (Section 5.2.2.5 of
	to aid in a smooth transition to a full Structured Field parser and		[HTTP-CACHING]) always has a boolean true value, and no-cache
	prevent interoperability issues:		(Section 5.2.2.4 of [HTTP-CACHING]) has a value that can either be
			boolean true or a string containing a comma-delimited list of field
			names.
			Implementations MUST NOT generate and SHOULD NOT consume values that
			violate these inferred constraints on the directive's value (e.g.
			coerce a max-age with a decimal value into an integer). Parameters
			received on directives are to be ignored, unless other handling is
			explicitly specified.
			Sending implementations MUST generate valid Structured Fields.
			Receiving implementations SHOULD use a Structured Fields parser, but
			MAY reuse an existing parser for the Cache-Control field value
			(Section 5.2 of [HTTP-CACHING]). Those that do SHOULD implement the
			following constraints, to aid in a smooth transition to a full
			Structured Field parser and prevent interoperability issues:
			* Directive names are all lowercase (e.g., "MAX-AGE=60" is
			considered an error).
	* If a directive is repeated in the field value (e.g., "max-age=30,		* If a directive is repeated in the field value (e.g., "max-age=30,
	max-age=60"), the last value 'wins' (60, in this case)		max-age=60"), the last value 'wins' (60, in this case).
	* Members of the directives can have parameters (e.g., "max-		* Members of the directives can have parameters (e.g., "max-
	age=30;a=b;c=d"), which should be ignored unless specified.		age=30;a=b;c=d"), which are ignored unless specified.
	If a targeted field in a given response is empty, or a parsing error		If a targeted field in a given response is empty, or a parsing error
	is encountered (when being parsed as a Structured Field), that field		is encountered, that field MUST be ignored by the cache (i.e., it
	SHOULD be ignored by the cache (i.e., it should behave as if the		behaves as if the field were not present, likely falling back to
	field were not present, likely falling back to other cache control		other cache control mechanisms present).
	mechanisms present).
	2.3. Defining Targeted Fields		2.3. Interaction with HTTP Freshness
			HTTP caching has a single, end-to-end freshness model defined in
			Section 4.2 of [I-D.ietf-httpbis-cache]. When additional freshness
			mechanisms are only available to some caches along a request path
			(for example, using targeted fields), their interactions need to be
			carefully considered. In particular, a targeted cache might have
			longer freshness lifetimes available to it than other caches, causing
			it to serve responses that appear to be prematurely (or even
			immediately) stale to them, negatively impacting cache efficiency.
			For example, a response stored by a CDN cache might be served with
			the following headers:
			Age: 1800
			Cache-Control: max-age=600
			CDN-Cache-Control: max-age=3600
			From the CDN's perspective, this response is still fresh after being
			cached for 30 minutes, while from other caches' standpoint, this
			response is already stale. See [AGE-PENALTY] for more discussion.
			When the targeted cache has a strong coherence mechanism (e.g., the
			origin server has the ability to proactively invalidate cached
			responses), it is often desirable to mitigate these effects. Some
			techniques seen in deployments include:
			* Removing the Age header field
			* Updating the Date header field value to the current time
			* Updating the Expires header field value to the current time, plus
			any Cache-Control: max-age value
			This specification does not place any specific requirements on
			implementations to mitigate these effects, but definitions of
			targeted fields can do so.
			2.4. Defining Targeted Fields
	A targeted field for a particular class of cache can be defined by		A targeted field for a particular class of cache can be defined by
	requesting registration in the Hypertext Transfer Protocol (HTTP)		requesting registration in the Hypertext Transfer Protocol (HTTP)
	Field Name Registry https://www.iana.org/assignments/http-fields/		Field Name Registry https://www.iana.org/assignments/http-fields/
	(https://www.iana.org/assignments/http-fields/), listing this		(https://www.iana.org/assignments/http-fields/), listing this
	specification as the specification document. The Comments field of		specification as the specification document. The Comments field of
	the registration SHOULD clearly define the class of caches that the		the registration should clearly define the class of caches that the
	targeted field applies to.		targeted field applies to.
	By convention, targeted fields SHOULD have the suffix "-Cache-		By convention, targeted fields have the suffix "-Cache-Control":
	Control": e.g., "ExampleCDN-Cache-Control". However, this suffix		e.g., "ExampleCDN-Cache-Control". However, this suffix MUST NOT be
	MUST NOT be used on its own to identify targeted fields; it is only a		used on its own to identify targeted fields; it is only a convention.
	convention.
	3. The CDN-Cache-Control Targeted Field		3. The CDN-Cache-Control Targeted Field
	The CDN-Cache-Control response header field is a targeted field		The CDN-Cache-Control response header field is a targeted field
	Section 2 that allows origin servers to control the behaviour of CDN		(Section 2) that allows origin servers to control the behaviour of
	caches interposed between them and clients, separately from other		CDN caches interposed between them and clients, separately from other
	caches that might handle the response.		caches that might handle the response.
	It applies to caches that are part of a distributed network that		It applies to caches that are part of a distributed network that
	operate on behalf of an origin server (commonly called a Content		operate on behalf of an origin server (commonly called a Content
	Delivery Network or CDN).		Delivery Network or CDN).
	CDN caches that use CDN-Cache-Control MAY forward this header so that		CDN caches that use CDN-Cache-Control will typically forward this
	downstream CDN caches can use it as well. However, doing so exposes		header so that downstream CDN caches can use it as well. However,
	its value to all downstream clients, which might be undesirable. As		they MAY remove it when this is undesirable (for example, when
	a result, CDN caches that process this header field MAY remove it		configured to do so because it is known not to be used downstream).
	(for example, when configured to do so because it is known not to be
	used downstream).
	3.1. Examples		3.1. Examples
	For example, the following header fields would instruct a CDN cache		For example, the following header fields would instruct a CDN cache
	to consider the response fresh for 600 seconds, other shared caches		to consider the response fresh for 600 seconds, other shared caches
	for 120 seconds and any remaining caches for 60 seconds:		for 120 seconds and any remaining caches for 60 seconds:
	Cache-Control: max-age=60, s-maxage=120		Cache-Control: max-age=60, s-maxage=120
	CDN-Cache-Control: max-age=600		CDN-Cache-Control: max-age=600
	These header fields would instruct a CDN cache to consider the		These header fields would instruct a CDN cache to consider the
	response fresh for 600 seconds, while all other caches would be		response fresh for 600 seconds, while all other caches would be
	prevented from storing it:		prevented from storing it:
	Cache-Control: no-store
	CDN-Cache-Control: max-age=600		CDN-Cache-Control: max-age=600
			Cache-Control: no-store
	Because CDN-Cache-Control is not present, this header field would		Because CDN-Cache-Control is not present, this header field would
	prevent all caches from storing the response:		prevent all caches from storing the response:
	Cache-Control: no-store		Cache-Control: no-store
	Whereas these would prevent all caches except for CDN caches from		Whereas these would prevent all caches except for CDN caches from
	storing the response:		storing the response:
	Cache-Control: no-store		Cache-Control: no-store
	CDN-Cache-Control: none		CDN-Cache-Control: none
	(note that 'none' is not a registered cache directive; it is here to		(note that 'none' is not a registered cache directive; it is here to
	avoid sending a header field with an empty value, because such a		avoid sending a header field with an empty value, which would be
	header might not be preserved in all cases)		ignored)
	4. IANA Considerations		4. IANA Considerations
	Please register the following entry in the Hypertext Transfer		Please register the following entry in the Hypertext Transfer
	Protocol (HTTP) Field Name Registry defined by		Protocol (HTTP) Field Name Registry defined by [HTTP]:
	[I-D.ietf-httpbis-semantics]:
	* Field Name: CDN-Cache-Control		* Field Name: CDN-Cache-Control
	* Status: permanent		* Status: permanent
	* Specification Document: [this document]		* Specification Document: [this document]
	* Comments: Cache-Control directives targeted at Content Delivery		* Comments: Cache-Control directives targeted at Content Delivery
	Networks		Networks
	5. Security Considerations		5. Security Considerations
	The security considerations of HTTP caching [I-D.ietf-httpbis-cache]		The security considerations of HTTP caching [HTTP-CACHING] apply.
	apply.
	The ability to carry multiple caching policies on a response can		The ability to carry multiple caching policies on a response can
	result in confusion about how a response will be cached in different		result in confusion about how a response will be cached in different
	systems, if not used carefully. This might result in unintentional		systems, if not used carefully. This might result in unintentional
	reuse of responses with sensitive information.		reuse of responses with sensitive information.
	6. Normative References		6. References
	[I-D.ietf-httpbis-cache]		6.1. Normative References
			[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
			Semantics", Work in Progress, Internet-Draft, draft-ietf-
			httpbis-semantics-19, 12 September 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
			semantics-19>.
			[HTTP-CACHING]
	Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Caching", Work in Progress, Internet-Draft, draft-ietf-		Caching", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-cache-17, 25 July 2021,		httpbis-cache-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	cache-17>.		cache-19>.
	[I-D.ietf-httpbis-semantics]		[I-D.ietf-httpbis-cache]
	Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Caching", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-semantics-17, 25 July 2021,		httpbis-cache-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	semantics-17>.		cache-19>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	[RFC8941] Nottingham, M. and P-H. Kamp, "Structured Field Values for		[STRUCTURED-FIELDS]
			Nottingham, M. and P-H. Kamp, "Structured Field Values for
	HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,		HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
	<https://www.rfc-editor.org/rfc/rfc8941>.		<https://www.rfc-editor.org/rfc/rfc8941>.
			6.2. Informative References
			[AGE-PENALTY]
			Cohen, E. and H. Kaplan, "The age penalty and its effect
			on cache performance", March 2001,
			<https://dl.acm.org/doi/10.5555/1251440.1251447>.
	Authors' Addresses		Authors' Addresses
	Stephen Ludin		Stephen Ludin
	Akamai		Akamai
	Email: sludin@ludin.org		Email: sludin@ludin.org
	Mark Nottingham		Mark Nottingham
	Fastly		Fastly
	Prahran		Prahran
	VIC
	Australia		Australia
	Email: mnot@mnot.net		Email: mnot@mnot.net
	URI: https://www.mnot.net/		URI: https://www.mnot.net/
	Yuchen Wu		Yuchen Wu
	Cloudflare		Cloudflare
	Email: me@yuchenwu.net		Email: me@yuchenwu.net
End of changes. 40 change blocks.
	87 lines changed or deleted		156 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/