draft-ietf-httpbis-variants-06.txt		draft-ietf-httpbis-variants-latest.txt
	HTTP Working Group M. Nottingham		HTTP Working Group M. Nottingham
	Internet-Draft Fastly		Internet-Draft Fastly
	Updates: 7234 (if approved) November 2, 2019		Updates: 7234 (if approved) November 6, 2023
	Intended status: Standards Track		Intended status: Standards Track
	Expires: May 5, 2020		Expires: May 9, 2024
	HTTP Representation Variants		HTTP Representation Variants
	draft-ietf-httpbis-variants-06		draft-ietf-httpbis-variants-latest
	Abstract		Abstract
	This specification introduces an alternative way to select a HTTP		This specification introduces an alternative way to select a HTTP
	response from a cache based upon its request headers, using the HTTP		response from a cache based upon its request headers, using the HTTP
	"Variants" and "Variant-Key" response header fields. Its aim is to		"Variants" and "Variant-Key" response header fields. Its aim is to
	make HTTP proactive content negotiation more cache-friendly.		make HTTP proactive content negotiation more cache-friendly.
	Note to Readers		About This Document
	_RFC EDITOR: please remove this section before publication_		This note is to be removed before publishing as an RFC.
	Discussion of this draft takes place on the HTTP working group		Status information for this document may be found at
	mailing list (ietf-http-wg@w3.org), which is archived at		<https://datatracker.ietf.org/doc/draft-ietf-httpbis-variants/>.
	https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].
	Working Group information can be found at https://httpwg.github.io/		Discussion of this document takes place on the HTTP Working Group
	[2]; source code and issues list for this draft can be found at		mailing list (<mailto:ietf-http-wg@w3.org>), which is archived at
	https://github.com/httpwg/http-extensions/labels/variants [3].		<https://lists.w3.org/Archives/Public/ietf-http-wg/>. Working Group
			information can be found at <https://httpwg.org/>.
	There is a prototype implementation of the algorithms herein at		Source for this draft and an issue tracker can be found at
	https://github.com/mnot/variants-toy [4].		<https://github.com/httpwg/http-extensions/labels/variants>.
	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 May 5, 2020.		This Internet-Draft will expire on May 9, 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2023 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
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	4.2. Check Vary . . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Check Vary . . . . . . . . . . . . . . . . . . . . . . . 11
	4.3. Example of Cache Behaviour . . . . . . . . . . . . . . . 11		4.3. Example of Cache Behaviour . . . . . . . . . . . . . . . 11
	4.3.1. A Variant Missing From the Cache . . . . . . . . . . 12		4.3.1. A Variant Missing From the Cache . . . . . . . . . . 12
	4.3.2. Variants That Don't Overlap the Client's Request . . 13		4.3.2. Variants That Don't Overlap the Client's Request . . 13
	5. Origin Server Behaviour . . . . . . . . . . . . . . . . . . . 13		5. Origin Server Behaviour . . . . . . . . . . . . . . . . . . . 13
	5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14		5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1.1. Single Variant . . . . . . . . . . . . . . . . . . . 14		5.1.1. Single Variant . . . . . . . . . . . . . . . . . . . 14
	5.1.2. Multiple Variants . . . . . . . . . . . . . . . . . . 15		5.1.2. Multiple Variants . . . . . . . . . . . . . . . . . . 15
	5.1.3. Partial Coverage . . . . . . . . . . . . . . . . . . 15		5.1.3. Partial Coverage . . . . . . . . . . . . . . . . . . 15
	6. Defining Content Negotiation Using Variants . . . . . . . . . 16		6. Defining Content Negotiation Using Variants . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		7. Implementations . . . . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . 18		10.1. Normative References . . . . . . . . . . . . . . . . . . 18
	9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18		10.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Variants for Existing Content Negotiation Mechanisms 19		Appendix A. Variants for Existing Content Negotiation Mechanisms 19
	A.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 19		A.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 19
	A.2. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20		A.2. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 20
	A.3. Accept-Language . . . . . . . . . . . . . . . . . . . . . 20		A.3. Accept-Language . . . . . . . . . . . . . . . . . . . . . 21
	A.4. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 21		A.4. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	HTTP proactive content negotiation ([RFC7231], Section 3.4.1) is		HTTP proactive content negotiation ([RFC7231], Section 3.4.1) is
	seeing renewed interest, both for existing request headers like		seeing renewed interest, both for existing request headers like
	Accept-Language and for newer ones (for example, see		Accept-Language and for newer ones (for example, see
	[I-D.ietf-httpbis-client-hints]).		[I-D.ietf-httpbis-client-hints]).
	Successfully reusing negotiated responses that have been stored in a		Successfully reusing negotiated responses that have been stored in a
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	Provided that the cache has full knowledge of the semantics of		Provided that the cache has full knowledge of the semantics of
	Accept-Language and Content-Language, it will know that an English		Accept-Language and Content-Language, it will know that an English
	representation is available and might be able to infer that a French		representation is available and might be able to infer that a French
	representation is not available. But, it does not know (for example)		representation is not available. But, it does not know (for example)
	whether a Japanese representation is available without making another		whether a Japanese representation is available without making another
	request, incurring possibly unnecessary latency.		request, incurring possibly unnecessary latency.
	This specification introduces the HTTP Variants response header field		This specification introduces the HTTP Variants response header field
	(Section 2) to enumerate the available variant representations on the		(Section 2) to enumerate the available variant representations on the
	origin server, to provide clients and caches with enough information		origin server, to provide clients and caches with enough information
	to properly satisfy requests - either by selecting a response from		to properly satisfy requests -- either by selecting a response from
	cache or by forwarding the request towards the origin - by following		cache or by forwarding the request towards the origin -- by following
	the algorithm defined in Section 4.		the algorithm defined in Section 4.
	Its companion Variant-Key response header field (Section 3) indicates		Its companion Variant-Key response header field (Section 3) indicates
	the applicable key(s) that the response is associated with, so that		the applicable key(s) that the response is associated with, so that
	it can be reliably reused in the future. Effectively, it allows the		it can be reliably reused in the future. Effectively, it allows the
	specification of a request header field to define how it affects the		specification of a request header field to define how it affects the
	secondary cache key.		secondary cache key.
	When this specification is in use, the example above might become:		When this specification is in use, the example above might become:
	GET /foo HTTP/1.1		GET /foo HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Accept-Language: en;q=0.5, fr;q=1.0		Accept-Language: en;q=0.5, fr;q=1.0
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: text/html		Content-Type: text/html
	Content-Language: en		Content-Language: en
	Vary: Accept-Language		Vary: Accept-Language
	Variants: Accept-Language;de;en;jp		Variants: accept-language;de;en;jp
	Variant-Key: en		Variant-Key: en
	Transfer-Encoding: chunked		Transfer-Encoding: chunked
	[English content]		[English content]
	Proactive content negotiation mechanisms that wish to be used with		Proactive content negotiation mechanisms that wish to be used with
	Variants need to define how to do so explicitly; see Section 6. As a		Variants need to define how to do so explicitly; see Section 6. As a
	result, it is best suited for negotiation over request headers that		result, it is best suited for negotiation over request headers that
	are well-understood.		are well-understood.
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 9 ¶
	Variants can be seen as a simpler version of the Alternates header		Variants can be seen as a simpler version of the Alternates header
	field introduced by [RFC2295]; unlike that mechanism, Variants does		field introduced by [RFC2295]; unlike that mechanism, Variants does
	not require specification of each combination of attributes, and does		not require specification of each combination of attributes, and does
	not assume that each combination has a unique URL.		not assume that each combination has a unique URL.
	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
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] but relies on Structured Headers from		notation of [RFC5234] but relies on Structured Headers from
	[I-D.ietf-httpbis-header-structure] for parsing.		[I-D.ietf-httpbis-header-structure] for parsing.
	Additionally, it uses the "field-name" rule from [RFC7230], "type",		Additionally, it uses the "field-name" rule from [RFC7230], "type",
	"subtype", "content-coding" and "language-range" from [RFC7231], and		"subtype", "content-coding" and "language-range" from [RFC7231], and
	"cookie-name" from [RFC6265].		"cookie-name" from [RFC6265].
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 40 ¶
	[I-D.ietf-httpbis-header-structure]). Its ABNF is:		[I-D.ietf-httpbis-header-structure]). Its ABNF is:
	Variants = sh-dict		Variants = sh-dict
	Each member-name represents the field-name of a request header that		Each member-name represents the field-name of a request header that
	is part of the secondary cache key; each member-value is an inner-		is part of the secondary cache key; each member-value is an inner-
	list of strings or tokens that convey representations of potential		list of strings or tokens that convey representations of potential
	values for that header field, hereafter referred to as "available-		values for that header field, hereafter referred to as "available-
	values".		values".
	If Structured Header parsing fails or a member's value does have the		If Structured Header parsing fails or a member's value does not have
	structure outlined above, the client MUST treat the representation as		the structure outlined above, the client MUST treat the
	having no Variants header field.		representation as having no Variants header field.
	Note that an available-value that is a token is interpreted as a		Note that an available-value that is a token is interpreted as a
	string containing the same characters, and vice versa.		string containing the same characters, and vice versa.
	So, given this example header field:		So, given this example header field:
	Variants: Accept-Encoding=(gzip)		Variants: accept-encoding=(gzip)
	a recipient can infer that the only content-coding available for that		a recipient can infer that the only content-coding available for that
	resource is "gzip" (along with the "identity" non-encoding; see		resource is "gzip" (along with the "identity" non-encoding; see
	Appendix A.2).		Appendix A.2).
	Given:		Given:
	Variants: accept-encoding=()		Variants: accept-encoding=()
	a recipient can infer that no content-codings (beyond identity) are		a recipient can infer that no content-codings (beyond identity) are
	supported. Note that as always, field-name is case-insensitive.		supported. Note that as always, field-name is case-insensitive.
	A more complex example:		A more complex example:
	Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)		Variants: accept-encoding=(gzip br), accept-language=(en fr)
	Here, recipients can infer that two content-codings in addition to		Here, recipients can infer that two content-codings in addition to
	"identity" are available, as well as two content languages. Note		"identity" are available, as well as two content languages. Note
	that, as with all Structured Header dictionaries, they might occur in		that, as with all Structured Header dictionaries, they might occur in
	the same header field or separately, like this:		the same header field or separately, like this:
	Variants: Accept-Encoding=(gzip brotli)		Variants: accept-encoding=(gzip brotli)
	Variants: Accept-Language=(en fr)		Variants: accept-language=(en fr)
	The ordering of available-values is significant, as it might be used		The ordering of available-values is significant, as it might be used
	by the header's algorithm for selecting a response (in this example,		by the header's algorithm for selecting a response (in this example,
	the first language is the default; see Appendix A.3).		the first language is the default; see Appendix A.3).
	The ordering of the request header fields themselves indicates		The ordering of the request header fields themselves indicates
	descending application of preferences; in the example above, a cache		descending application of preferences; in the example above, a cache
	that has all of the possible permutations stored will honour the		that has all of the possible permutations stored will honour the
	client's preferences for Accept-Encoding before honouring Accept-		client's preferences for Accept-Encoding before honouring Accept-
	Language.		Language.
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 11 ¶
	the Variants header field; they can be interpreted by the algorithm		the Variants header field; they can be interpreted by the algorithm
	specific to processing that field. For example, Accept-Encoding		specific to processing that field. For example, Accept-Encoding
	defines an implicit "identity" available-value (Appendix A.2).		defines an implicit "identity" available-value (Appendix A.2).
	Each inner-list member is treated as identifying an available-value		Each inner-list member is treated as identifying an available-value
	for the corresponding variant-axis' field-name. Any list-member that		for the corresponding variant-axis' field-name. Any list-member that
	is a token is interpreted as a string containing the same characters.		is a token is interpreted as a string containing the same characters.
	For example:		For example:
	Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)		Variants: accept-encoding=(gzip br), accept-language=(en fr)
	Variant-Key: (gzip fr)		Variant-Key: (gzip fr)
	This header pair indicates that the representation has a "gzip"		This header pair indicates that the representation has a "gzip"
	content-coding and "fr" content-language.		content-coding and "fr" content-language.
	If the response can be used to satisfy more than one request, they		If the response can be used to satisfy more than one request, they
	can be listed in additional members. For example:		can be listed in additional members. For example:
	Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)		Variants: accept-encoding=(gzip br), accept-language=(en fr)
	Variant-Key: (gzip fr), ("identity" fr)		Variant-Key: (gzip fr), ("identity" fr)
	indicates that this response can be used for requests whose Accept-		indicates that this response can be used for requests whose Accept-
	Encoding algorithm selects "gzip" or "identity", as long as the		Encoding algorithm selects "gzip" or "identity", as long as the
	Accept-Language algorithm selects "fr" - perhaps because there is no		Accept-Language algorithm selects "fr" -- perhaps because there is no
	gzip-compressed French representation.		gzip-compressed French representation.
	When more than one Variant-Key value is in a response, the first one		When more than one Variant-Key value is in a response, the first one
	present MUST correspond to the request that caused that response to		present MUST correspond to the request that caused that response to
	be generated. For example:		be generated. For example:
	Variants: Accept-Encoding=(gzip br), Accept-Language=(en fr)		Variants: accept-encoding=(gzip br), accept-language=(en fr)
	Variant-Key: (gzip fr), (identity fr), (br fr oops)		Variant-Key: (gzip fr), (identity fr), (br fr oops)
	is treated as if the Variant-Key header were completely absent, which		is treated as if the Variant-Key header were completely absent, which
	will tend to disable caching for the representation that contains it.		will tend to disable caching for the representation that contains it.
	Note that in		Note that in
	Variant-Key: (gzip fr)		Variant-Key: (gzip fr)
	Variant-Key: ("gzip " fr)		Variant-Key: ("gzip " fr)
	skipping to change at page 16, line 14 ¶		skipping to change at page 16, line 14 ¶
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: image/gif		Content-Type: image/gif
	Content-Language: en		Content-Language: en
	Content-Encoding: br		Content-Encoding: br
	Variants: Accept-Encoding=(br gzip)		Variants: Accept-Encoding=(br gzip)
	Variant-Key: (br)		Variant-Key: (br)
	Vary: Accept-Language, Accept-Encoding		Vary: Accept-Language, Accept-Encoding
	Transfer-Encoding: chunked		Transfer-Encoding: chunked
	Here, the cache will need to calculate a secondary cache key as per		Here, the cache will need to calculate a secondary cache key as per
	[RFC7234], Section 4.1 - but considering only Accept-Language to be		[RFC7234], Section 4.1 -- but considering only Accept-Language to be
	in its field-value - and then continue processing Variants for the		in its field-value -- and then continue processing Variants for the
	set of stored responses that the algorithm described there selects.		set of stored responses that the algorithm described there selects.
	6. Defining Content Negotiation Using Variants		6. Defining Content Negotiation Using Variants
	To be usable with Variants, proactive content negotiation mechanisms		To be usable with Variants, proactive content negotiation mechanisms
	need to be specified to take advantage of it. Specifically, they:		need to be specified to take advantage of it. Specifically, they:
	o MUST define a request header field that advertises the clients		o MUST define a request header field that advertises the clients
	preferences or capabilities, whose field-name SHOULD begin with		preferences or capabilities. Often, its field-name will begin
	"Accept-".		with "Accept-", but this is not required.
	o MUST define the syntax of an available-value that will occur in		o MUST define the syntax of an available-value that will occur in
	Variants and Variant-Key.		Variants and Variant-Key.
	o MUST define an algorithm for selecting a result. It MUST return a		o MUST define an algorithm for selecting a result. It MUST return a
	list of available-values that are suitable for the request, in		list of available-values that are suitable for the request, in
	order of preference, given the value of the request header		order of preference, given the value of the request header
	nominated above (or null if the request header is absent) and an		nominated above (or null if the request header is absent) and an
	available-values list from the Variants header. If the result is		available-values list from the Variants header. If the result is
	an empty list, it implies that the cache cannot satisfy the		an empty list, it implies that the cache cannot satisfy the
	request.		request.
	Appendix A fulfils these requirements for some existing proactive		Appendix A fulfils these requirements for some existing proactive
	content negotiation mechanisms in HTTP.		content negotiation mechanisms in HTTP.
	7. IANA Considerations		7. Implementations
			This section is to be removed before publishing as an RFC.
			There is a prototype implementation of the algorithms in this
			document at <https://github.com/mnot/variants-toy>.
			8. IANA Considerations
	This specification registers the following entry in the Permanent		This specification registers the following entry in the Permanent
	Message Header Field Names registry established by [RFC3864]:		Message Header Field Names registry established by [RFC3864]:
	o Header field name: Variants		o Header field name: Variants
	o Applicable protocol: http		o Applicable protocol: http
	o Status: standard		o Status: standard
	o Author/Change Controller: IETF		o Author/Change Controller: IETF
	o Specification document(s): [this document]		o Specification document(s): [this document]
	o Related information:		o Related information:
	This specification registers the following entry in the Permanent		This specification registers the following entry in the Permanent
	Message Header Field Names registry established by [RFC3864]:		Message Header Field Names registry established by [RFC3864]:
	o Header field name: Variant-Key		o Header field name: Variant-Key
	skipping to change at page 17, line 25 ¶		skipping to change at page 17, line 37 ¶
	o Applicable protocol: http		o Applicable protocol: http
	o Status: standard		o Status: standard
	o Author/Change Controller: IETF		o Author/Change Controller: IETF
	o Specification document(s): [this document]		o Specification document(s): [this document]
	o Related information:		o Related information:
	8. Security Considerations		9. Security Considerations
	If the number or advertised characteristics of the representations		If the number or advertised characteristics of the representations
	available for a resource are considered sensitive, the Variants		available for a resource are considered sensitive, the Variants
	header by its nature will leak them.		header by its nature will leak them.
	Note that the Variants header is not a commitment to make		Note that the Variants header is not a commitment to make
	representations of a certain nature available; the runtime behaviour		representations of a certain nature available; the runtime behaviour
	of the server always overrides hints like Variants.		of the server always overrides hints like Variants.
	9. References		10. References
			10.1. Normative References
	9.1. Normative References
	[I-D.ietf-httpbis-header-structure]		[I-D.ietf-httpbis-header-structure]
	Nottingham, M. and P. Kamp, "Structured Headers for HTTP",		Nottingham, M. and P. Kamp, "Structured Field Values for
	draft-ietf-httpbis-header-structure-13 (work in progress),		HTTP", draft-ietf-httpbis-header-structure-19 (work in
	August 2019.		progress), June 2020.
	[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/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags",		[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
	BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006,		Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
	<https://www.rfc-editor.org/info/rfc4647>.		2006, <https://www.rfc-editor.org/info/rfc4647>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	skipping to change at page 18, line 33 ¶		skipping to change at page 19, line 5 ¶
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<https://www.rfc-editor.org/info/rfc7234>.		<https://www.rfc-editor.org/info/rfc7234>.
	[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/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		10.2. Informative References
	[I-D.ietf-httpbis-client-hints]		[I-D.ietf-httpbis-client-hints]
	Grigorik, I., "HTTP Client Hints", draft-ietf-httpbis-		Grigorik, I. and Y. Weiss, "HTTP Client Hints", draft-
	client-hints-07 (work in progress), March 2019.		ietf-httpbis-client-hints-15 (work in progress), July
			2020.
	[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation		[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
	in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,		in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
	<https://www.rfc-editor.org/info/rfc2295>.		<https://www.rfc-editor.org/info/rfc2295>.
	[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,
	DOI 10.17487/RFC3864, September 2004,		DOI 10.17487/RFC3864, September 2004,
	<https://www.rfc-editor.org/info/rfc3864>.		<https://www.rfc-editor.org/info/rfc3864>.
	9.3. URIs
	[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
	[2] https://httpwg.github.io/
	[3] https://github.com/httpwg/http-extensions/labels/variants
	[4] https://github.com/mnot/variants-toy
	Appendix A. Variants for Existing Content Negotiation Mechanisms		Appendix A. Variants for Existing Content Negotiation Mechanisms
	This appendix defines the required information to use existing		This appendix defines the required information to use existing
	proactive content negotiation mechanisms (as defined in [RFC7231],		proactive content negotiation mechanisms (as defined in [RFC7231],
	Section 5.3) with the Variants header field.		Section 5.3) with the Variants header field.
	A.1. Accept		A.1. Accept
	This section defines variant handling for the Accept request header		This section defines variant handling for the Accept request header
	(section 5.3.2 of [RFC7231]).		(section 5.3.2 of [RFC7231]).
	skipping to change at page 23, line 9 ¶		skipping to change at page 23, line 25 ¶
	It is also a generalisation of a Fastly VCL feature designed by		It is also a generalisation of a Fastly VCL feature designed by
	Rogier 'DocWilco' Mulhuijzen.		Rogier 'DocWilco' Mulhuijzen.
	Thanks to Hooman Beheshti, Ilya Grigorik, Leif Hedstrom, and Jeffrey		Thanks to Hooman Beheshti, Ilya Grigorik, Leif Hedstrom, and Jeffrey
	Yasskin for their review and input.		Yasskin for their review and input.
	Author's Address		Author's Address
	Mark Nottingham		Mark Nottingham
	Fastly		Fastly
			Prahran
			Australia
	Email: mnot@mnot.net		Email: mnot@mnot.net
	URI: https://www.mnot.net/		URI: https://www.mnot.net/
End of changes. 36 change blocks.
	67 lines changed or deleted		67 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/