draft-ietf-httpbis-compression-dictionary-06.txt		draft-ietf-httpbis-compression-dictionary-latest.txt
	HTTP Working Group P. Meenan, Ed.		HTTP Working Group P. Meenan, Ed.
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Intended status: Standards Track Y. Weiss, Ed.		Intended status: Standards Track Y. Weiss, Ed.
	Expires: January 6, 2025 Shopify Inc		Expires: January 15, 2025 Shopify Inc
	July 05, 2024		July 14, 2024
	Compression Dictionary Transport		Compression Dictionary Transport
	draft-ietf-httpbis-compression-dictionary-06		draft-ietf-httpbis-compression-dictionary-latest
	Abstract		Abstract
	This specification defines a mechanism for using designated HTTP		This specification defines a mechanism for using designated HTTP
	responses as an external dictionary for future HTTP responses for		responses as an external dictionary for future HTTP responses for
	compression schemes that support using external dictionaries (e.g.,		compression schemes that support using external dictionaries (e.g.,
	Brotli (RFC 7932) and Zstandard (RFC 8878)).		Brotli (RFC 7932) and Zstandard (RFC 8878)).
	About This Document		About This Document
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 January 6, 2025.		This Internet-Draft will expire on January 15, 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 3		2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 3
	2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 3		2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 3
	2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.2. match-dest . . . . . . . . . . . . . . . . . . . . . 4		2.1.2. match-dest . . . . . . . . . . . . . . . . . . . . . 4
	2.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 5		2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 6		2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 6
	2.2.1. Dictionary freshness requirement . . . . . . . . . . 6		2.2.1. Dictionary freshness requirement . . . . . . . . . . 6
	2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 6		2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 6
	2.2.3. Multiple matching dictionaries . . . . . . . . . . . 7		2.2.3. Multiple matching dictionaries . . . . . . . . . . . 7
	2.3. Dictionary-ID . . . . . . . . . . . . . . . . . . . . . . 7		2.3. Dictionary-ID . . . . . . . . . . . . . . . . . . . . . . 7
	3. The 'compression-dictionary' Link Relation Type . . . . . . . 8		3. The 'compression-dictionary' Link Relation Type . . . . . . . 8
	4. Dictionary-Compressed Brotli . . . . . . . . . . . . . . . . 8		4. Dictionary-Compressed Brotli . . . . . . . . . . . . . . . . 8
	5. Dictionary-Compressed Zstandard . . . . . . . . . . . . . . . 9		5. Dictionary-Compressed Zstandard . . . . . . . . . . . . . . . 9
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	9.1. Changing content . . . . . . . . . . . . . . . . . . . . 12		9.1. Changing content . . . . . . . . . . . . . . . . . . . . 12
	9.2. Reading content . . . . . . . . . . . . . . . . . . . . . 13		9.2. Reading content . . . . . . . . . . . . . . . . . . . . . 13
	9.3. Security Mitigations . . . . . . . . . . . . . . . . . . 13		9.3. Security Mitigations . . . . . . . . . . . . . . . . . . 13
	9.3.1. Cross-origin protection . . . . . . . . . . . . . . . 13		9.3.1. Cross-origin protection . . . . . . . . . . . . . . . 13
	9.3.2. Response readability . . . . . . . . . . . . . . . . 13		9.3.2. Response readability . . . . . . . . . . . . . . . . 13
	9.3.3. Server Responsibility . . . . . . . . . . . . . . . . 14		9.3.3. Server Responsibility . . . . . . . . . . . . . . . . 14
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11.1. Normative References . . . . . . . . . . . . . . . . . . 15		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . 16		11.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	This specification defines a mechanism for using designated [HTTP]		This specification defines a mechanism for using designated [HTTP]
	responses as an external dictionary for future HTTP responses for		responses as an external dictionary for future HTTP responses for
	compression schemes that support using external dictionaries (e.g.,		compression schemes that support using external dictionaries (e.g.,
	Brotli [RFC7932] and Zstandard [RFC8878]).		Brotli [RFC7932] and Zstandard [RFC8878]).
	This document describes the HTTP headers used for negotiating		This document describes the HTTP headers used for negotiating
	dictionary usage and registers media types for content encoding		dictionary usage and registers media types for content encoding
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 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 document uses the following terminology from Section 3 of		This document uses the following terminology from Section 3 of
	[STRUCTURED-FIELDS] to specify syntax and parsing: Dictionary,		[STRUCTURED-FIELDS] to specify syntax and parsing: Dictionary,
	String, Inner List, Token, and Byte Sequence.		String, Inner List, Token, and Byte Sequence.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	This document uses the line folding strategies described in		This document uses the line folding strategies described in
	[FOLDING].		[FOLDING].
	This document also uses terminology from [HTTP] and [HTTP-CACHING].		This document also uses terminology from [HTTP] and [HTTP-CACHING].
	2. Dictionary Negotiation		2. Dictionary Negotiation
	2.1. Use-As-Dictionary		2.1. Use-As-Dictionary
	When responding to a HTTP Request, a server can advertise that the		When responding to a HTTP Request, a server can advertise that the
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 38 ¶
	4. If PATTERN has regexp groups then return FALSE.		4. If PATTERN has regexp groups then return FALSE.
	5. Return True.		5. Return True.
	The "match" value is required and MUST be included in the Use-As-		The "match" value is required and MUST be included in the Use-As-
	Dictionary Dictionary for the dictionary to be considered valid.		Dictionary Dictionary for the dictionary to be considered valid.
	2.1.2. match-dest		2.1.2. match-dest
	The "match-dest" value of the Use-As-Dictionary header is an Inner		The "match-dest" value of the Use-As-Dictionary header is an Inner
	List of String values that provides a list of request destinations		List of String values that provides a list of [FETCH] request
	for the dictionary to match (https://fetch.spec.whatwg.org/#concept-		destinations for the dictionary to match.
	request-destination).
	An empty list for "match-dest" MUST match all destinations.		An empty list for "match-dest" MUST match all destinations.
	For clients that do not support request destinations, the client MUST		For clients that do not support request destinations, the client MUST
	treat it as an empty list and match all destinations.		treat it as an empty list and match all destinations.
	The "match-dest" value is optional and defaults to an empty list.		The "match-dest" value is optional and defaults to an empty list.
	2.1.3. id		2.1.3. id
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 44 ¶
	2.1.5.1. Path Prefix		2.1.5.1. Path Prefix
	A response that contained a response header:		A response that contained a response header:
	NOTE: '\' line wrapping per RFC 8792		NOTE: '\' line wrapping per RFC 8792
	Use-As-Dictionary: \		Use-As-Dictionary: \
	match="/product/*", match-dest=("document")		match="/product/*", match-dest=("document")
	Would specify matching any document request for a URL with a path		Would specify matching any document request for a URL with a path
	prefix of /product/ on the same [Origin] as the original request.		prefix of /product/ on the same Origin [RFC6454] as the original
			request.
	2.1.5.2. Versioned Directories		2.1.5.2. Versioned Directories
	A response that contained a response header:		A response that contained a response header:
	Use-As-Dictionary: match="/app/*/main.js"		Use-As-Dictionary: match="/app/*/main.js"
	Would match main.js in any directory under /app/ and expiring as a		Would match main.js in any directory under /app/ and expiring as a
	dictionary in one year.		dictionary in one year.
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 46 ¶
	fresh [HTTP-CACHING] or allowed to be served stale (see eg		fresh [HTTP-CACHING] or allowed to be served stale (see eg
	[RFC5861]).		[RFC5861]).
	2.2.2. Dictionary URL matching		2.2.2. Dictionary URL matching
	When a dictionary is stored as a result of a "Use-As-Dictionary"		When a dictionary is stored as a result of a "Use-As-Dictionary"
	directive, it includes "match" and "match-dest" strings that are used		directive, it includes "match" and "match-dest" strings that are used
	to match an outgoing request from a client to the available		to match an outgoing request from a client to the available
	dictionaries.		dictionaries.
	Dictionaries MUST have been served from the same {Origin} as the		Dictionaries MUST have been served from the same Origin [RFC6454] as
	outgoing request to match.		the outgoing request to match.
	To see if an outbound request matches a given dictionary, the		To see if an outbound request matches a given dictionary, the
	following algorithm will return TRUE for a successful match and FALSE		following algorithm will return TRUE for a successful match and FALSE
	for no-match:		for no-match:
	1. If the current client supports request destinations:		1. If the current client supports request destinations:
	* Let DEST be the value of "match-dest" for the given		* Let DEST be the value of "match-dest" for the given
	dictionary.		dictionary.
	* Let REQUEST_DEST be the value of the destination for the		* Let REQUEST_DEST be the value of the destination for the
	current request.		current request.
	* If DEST is not an empty list and if REQUEST_DEST is not in the		* If DEST is not an empty list and if REQUEST_DEST is not in the
	DEST list of destinations, return FALSE		DEST list of destinations, return FALSE
	2. Let BASEURL be the URL of the dictionary request.		2. Let BASEURL be the URL of the dictionary request.
	3. Let URL represent the URL of the outbound request being checked.		3. Let URL represent the URL of the outbound request being checked.
	4. If the {Origin} of BASEURL and the {Origin} of URL are not the		4. If the Origin of BASEURL and the Origin of URL are not the same,
	same, return FALSE.		return FALSE.
	5. Let MATCH be the value of "match" for the given dictionary.		5. Let MATCH be the value of "match" for the given dictionary.
	6. Let PATTERN be a URL Pattern [URLPattern] constructed by setting		6. Let PATTERN be a URL Pattern [URLPattern] constructed by setting
	input=MATCH, and baseURL=BASEURL.		input=MATCH, and baseURL=BASEURL.
	7. Return the result of running the "test" method of PATTERN with		7. Return the result of running the "test" method of PATTERN with
	input=URL.		input=URL.
	2.2.3. Multiple matching dictionaries		2.2.3. Multiple matching dictionaries
	skipping to change at page 13, line 9 ¶		skipping to change at page 13, line 9 ¶
	explicitly needed to counter attacks since the dictionary is being		explicitly needed to counter attacks since the dictionary is being
	served from the same origin as the content. That said, if a weakness		served from the same origin as the content. That said, if a weakness
	is discovered in SHA-256 and it is determined that the dictionary		is discovered in SHA-256 and it is determined that the dictionary
	negotiation should use a different hash algorithm, the "Use-As-		negotiation should use a different hash algorithm, the "Use-As-
	Dictionary" response header can be extended to specify a different		Dictionary" response header can be extended to specify a different
	algorithm and the server would just ignore any "Available-Dictionary"		algorithm and the server would just ignore any "Available-Dictionary"
	requests that do not use the updated hash.		requests that do not use the updated hash.
	9.2. Reading content		9.2. Reading content
	The CRIME attack shows that it's a bad idea to compress data from		The compression attacks in Section 2.6 of [RFC7457] show that it's a
	mixed (e.g. public and private) sources -- the data sources include		bad idea to compress data from mixed (e.g. public and private)
	not only the compressed data but also the dictionaries. For example,		sources -- the data sources include not only the compressed data but
	if you compress secret cookies using a public-data-only dictionary,		also the dictionaries. For example, if you compress secret cookies
	you still leak information about the cookies.		using a public-data-only dictionary, you still leak information about
			the cookies.
	Not only can the dictionary reveal information about the compressed		Not only can the dictionary reveal information about the compressed
	data, but vice versa, data compressed with the dictionary can reveal		data, but vice versa, data compressed with the dictionary can reveal
	the contents of the dictionary when an adversary can control parts of		the contents of the dictionary when an adversary can control parts of
	data to compress and see the compressed size. On the other hand, if		data to compress and see the compressed size. On the other hand, if
	the adversary can control the dictionary, the adversary can learn		the adversary can control the dictionary, the adversary can learn
	information about the compressed data.		information about the compressed data.
	9.3. Security Mitigations		9.3. Security Mitigations
	skipping to change at page 13, line 48 ¶		skipping to change at page 13, line 49 ¶
	tracking, additional protections MUST be taken to make sure that the		tracking, additional protections MUST be taken to make sure that the
	use of dictionary-based compression does not reveal information that		use of dictionary-based compression does not reveal information that
	would not otherwise be available.		would not otherwise be available.
	In these cases, dictionary compression MUST only be used when both		In these cases, dictionary compression MUST only be used when both
	the dictionary and the compressed response are fully readable by the		the dictionary and the compressed response are fully readable by the
	client.		client.
	In browser terms, that means that both are either same-origin to the		In browser terms, that means that both are either same-origin to the
	context they are being fetched from or that the response is cross-		context they are being fetched from or that the response is cross-
	origin and passes the CORS check		origin and passes the CORS check as defined in [FETCH].
	(https://fetch.spec.whatwg.org/#cors-check).
	9.3.3. Server Responsibility		9.3.3. Server Responsibility
	As with any usage of compressed content in a secure context, a		As with any usage of compressed content in a secure context, a
	potential timing attack exists if the attacker can control any part		potential timing attack exists if the attacker can control any part
	of the dictionary, or if it can read the dictionary and control any		of the dictionary, or if it can read the dictionary and control any
	part of the content being compressed, while performing multiple		part of the content being compressed, while performing multiple
	requests that vary the dictionary or injected content. Under such an		requests that vary the dictionary or injected content. Under such an
	attack, the changing size or processing time of the response reveals		attack, the changing size or processing time of the response reveals
	information about the content, which might be sufficient to read the		information about the content, which might be sufficient to read the
	skipping to change at page 15, line 18 ¶		skipping to change at page 15, line 18 ¶
	6. return FALSE.		6. return FALSE.
	10. Privacy Considerations		10. Privacy Considerations
	Since dictionaries are advertised in future requests using the hash		Since dictionaries are advertised in future requests using the hash
	of the content of the dictionary, it is possible to abuse the		of the content of the dictionary, it is possible to abuse the
	dictionary to turn it into a tracking cookie.		dictionary to turn it into a tracking cookie.
	To mitigate any additional tracking concerns, clients MUST treat		To mitigate any additional tracking concerns, clients MUST treat
	dictionaries in the same way that they treat cookies. This includes		dictionaries in the same way that they treat cookies [RFC6265]. This
	partitioning the storage as cookies are partitioned as well as		includes partitioning the storage as cookies are partitioned as well
	clearing the dictionaries whenever cookies are cleared.		as clearing the dictionaries whenever cookies are cleared.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
			[FETCH] WHATWG, "Fetch - Living Standard", June 2024,
			<https://fetch.spec.whatwg.org>.
	[FOLDING] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,		[FOLDING] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
	"Handling Long Lines in Content of Internet-Drafts and		"Handling Long Lines in Content of Internet-Drafts and
	RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,		RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
	<https://www.rfc-editor.org/info/rfc8792>.		<https://www.rfc-editor.org/info/rfc8792>.
	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
	skipping to change at page 15, line 47 ¶		skipping to change at page 15, line 50 ¶
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Caching", STD 98, RFC 9111,		Ed., "HTTP Caching", STD 98, RFC 9111,
	DOI 10.17487/RFC9111, June 2022,		DOI 10.17487/RFC9111, June 2022,
	<https://www.rfc-editor.org/info/rfc9111>.		<https://www.rfc-editor.org/info/rfc9111>.
	[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>.
	[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
	Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
	<https://www.rfc-editor.org/info/rfc5861>.
	[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>.
	[SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms		[SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234,		(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,		DOI 10.17487/RFC6234, May 2011,
	<https://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
			[STRUCTURED-FIELDS]
			"Structured Field Values for HTTP", May 2024,
			<https://datatracker.ietf.org/doc/draft-ietf-httpbis-
			sfbis/>.
	[URLPattern]		[URLPattern]
	"URL Pattern Standard", March 2024,		WHATWG, "URL Pattern - Living Standard", March 2024,
	<https://urlpattern.spec.whatwg.org/>.		<https://urlpattern.spec.whatwg.org/>.
	[WEB-LINKING]		[WEB-LINKING]
	Nottingham, M., "Web Linking", RFC 8288,		Nottingham, M., "Web Linking", RFC 8288,
	DOI 10.17487/RFC8288, October 2017,		DOI 10.17487/RFC8288, October 2017,
	<https://www.rfc-editor.org/info/rfc8288>.		<https://www.rfc-editor.org/info/rfc8288>.
	11.2. Informative References		11.2. Informative References
	[Origin] Barth, A., "The Web Origin Concept", RFC 6454,		[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
			Content", RFC 5861, DOI 10.17487/RFC5861, May 2010,
			<https://www.rfc-editor.org/info/rfc5861>.
			[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
			DOI 10.17487/RFC6265, April 2011,
			<https://www.rfc-editor.org/info/rfc6265>.
			[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
	DOI 10.17487/RFC6454, December 2011,		DOI 10.17487/RFC6454, December 2011,
	<https://www.rfc-editor.org/info/rfc6454>.		<https://www.rfc-editor.org/info/rfc6454>.
			[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
			Known Attacks on Transport Layer Security (TLS) and
			Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
			February 2015, <https://www.rfc-editor.org/info/rfc7457>.
	[RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data		[RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data
	Format", RFC 7932, DOI 10.17487/RFC7932, July 2016,		Format", RFC 7932, DOI 10.17487/RFC7932, July 2016,
	<https://www.rfc-editor.org/info/rfc7932>.		<https://www.rfc-editor.org/info/rfc7932>.
			[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
			"Handling Long Lines in Content of Internet-Drafts and
			RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
			<https://www.rfc-editor.org/info/rfc8792>.
	[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression		[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
	and the 'application/zstd' Media Type", RFC 8878,		and the 'application/zstd' Media Type", RFC 8878,
	DOI 10.17487/RFC8878, February 2021,		DOI 10.17487/RFC8878, February 2021,
	<https://www.rfc-editor.org/info/rfc8878>.		<https://www.rfc-editor.org/info/rfc8878>.
	[SHARED-BROTLI]		[SHARED-BROTLI]
	"Shared Brotli Compressed Data Format", September 2022,		"Shared Brotli Compressed Data Format", September 2022,
	<https://datatracker.ietf.org/doc/draft-vandevenne-shared-		<https://datatracker.ietf.org/doc/draft-vandevenne-shared-
	brotli-format/>.		brotli-format/>.
	[STRUCTURED-FIELDS]
	Nottingham, M. and P. Kamp, "Structured Field Values for
	HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
	<https://www.rfc-editor.org/info/rfc8941>.
	Authors' Addresses		Authors' Addresses
	Patrick Meenan (editor)		Patrick Meenan (editor)
	Google LLC		Google LLC
	Email: pmeenan@google.com		Email: pmeenan@google.com
	Yoav Weiss (editor)		Yoav Weiss (editor)
	Shopify Inc		Shopify Inc
	Email: yoav.weiss@shopify.com		Email: yoav.weiss@shopify.com
End of changes. 22 change blocks.
	39 lines changed or deleted		53 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/