< draft-ietf-httpbis-priority-09.txt		draft-ietf-httpbis-priority-10.txt >
	HTTP K. Oku		HTTP K. Oku
	Internet-Draft Fastly		Internet-Draft Fastly
	Intended status: Standards Track L. Pardue		Intended status: Standards Track L. Pardue
	Expires: 14 May 2022 Cloudflare		Expires: 23 May 2022 Cloudflare
	10 November 2021		19 November 2021
	Extensible Prioritization Scheme for HTTP		Extensible Prioritization Scheme for HTTP
	draft-ietf-httpbis-priority-09		draft-ietf-httpbis-priority-10
	Abstract		Abstract
	This document describes a scheme that allows an HTTP client to		This document describes a scheme that allows an HTTP client to
	communicate its preferences for how the upstream server prioritizes		communicate its preferences for how the upstream server prioritizes
	responses to its requests, and also allows a server to hint to a		responses to its requests, and also allows a server to hint to a
	downstream intermediary how its responses should be prioritized when		downstream intermediary how its responses should be prioritized when
	they are forwarded. This document defines the Priority header field		they are forwarded. This document defines the Priority header field
	for communicating the initial priority in an HTTP version-independent		for communicating the initial priority in an HTTP version-independent
	manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing		manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing
	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 14 May 2022.		This Internet-Draft will expire on 23 May 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Revised BSD License text as
	as described in Section 4.e of the Trust Legal Provisions and are		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 Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 5
	2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 5		2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 5
	2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6		2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6
	2.1.1. Advice when Using Extensible Priorities as the		2.1.1. Advice when Using Extensible Priorities as the
	Alternative . . . . . . . . . . . . . . . . . . . . . 7		Alternative . . . . . . . . . . . . . . . . . . . . . 7
	3. Applicability of the Extensible Priority Scheme . . . . . . . 8		3. Applicability of the Extensible Priority Scheme . . . . . . . 7
	4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 8		4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10		4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10
	4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 11		4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 10
	5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 12		5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 11
	6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 12		6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 12
	7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 12		7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 12
	7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13		7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 13
	7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 15		7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 14
	8. Merging Client- and Server-Driven Parameters . . . . . . . . 16		8. Merging Client- and Server-Driven Parameters . . . . . . . . 15
	9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 17		9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 16
	10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17		10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Intermediaries with Multiple Backend Connections . . . . 19		10.1. Intermediaries with Multiple Backend Connections . . . . 18
	11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19		11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19
	12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 20		12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 19
	13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 20		13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 20		13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 20
	13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 21		13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 21
	13.3. Intentional Introduction of Unfairness . . . . . . . . . 21		13.3. Intentional Introduction of Unfairness . . . . . . . . . 21
	14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 22		14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 21
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 22		15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	17.1. Normative References . . . . . . . . . . . . . . . . . . 24		17.1. Normative References . . . . . . . . . . . . . . . . . . 23
	17.2. Informative References . . . . . . . . . . . . . . . . . 24		17.2. Informative References . . . . . . . . . . . . . . . . . 24
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25
	B.1. Since draft-ietf-httpbis-priority-08 . . . . . . . . . . 26		B.1. Since draft-ietf-httpbis-priority-09 . . . . . . . . . . 25
	B.2. Since draft-ietf-httpbis-priority-07 . . . . . . . . . . 26		B.2. Since draft-ietf-httpbis-priority-08 . . . . . . . . . . 25
	B.3. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26		B.3. Since draft-ietf-httpbis-priority-07 . . . . . . . . . . 26
	B.4. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26		B.4. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
	B.5. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 27		B.5. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26
	B.6. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27		B.6. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26
	B.7. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27		B.7. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 26
	B.8. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27		B.8. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27
	B.9. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27		B.9. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27
	B.10. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 28		B.10. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27
	B.11. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28		B.11. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27
	B.12. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28		B.12. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28
	B.13. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28		B.13. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28
	B.14. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28		B.14. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29		B.15. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	It is common for representations of an HTTP [HTTP] resource to have		It is common for representations of an HTTP [HTTP] resource to have
	relationships to one or more other resources. Clients will often		relationships to one or more other resources. Clients will often
	discover these relationships while processing a retrieved		discover these relationships while processing a retrieved
	representation, which may lead to further retrieval requests.		representation, which may lead to further retrieval requests.
	Meanwhile, the nature of the relationship determines whether the		Meanwhile, the nature of the relationship determines whether the
	client is blocked from continuing to process locally available		client is blocked from continuing to process locally available
	resources. An example of this is visual rendering of an HTML		resources. An example of this is visual rendering of an HTML
	skipping to change at page 4, line 49 ¶		skipping to change at page 5, line 11 ¶
	response relative to any other response. Section 10 and Section 12		response relative to any other response. Section 10 and Section 12
	provide consideration and guidance about how servers might act upon		provide consideration and guidance about how servers might act upon
	signals.		signals.
	The prioritization scheme and priority signals defined herein can act		The prioritization scheme and priority signals defined herein can act
	as a substitute for RFC 7540 stream priority.		as a substitute for RFC 7540 stream priority.
	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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [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.
	The terms Dictionary, sf-boolean, sf-dictionary, and sf-integer are		The terms Dictionary, sf-boolean, sf-dictionary, and sf-integer are
	imported from [STRUCTURED-FIELDS].		imported from [STRUCTURED-FIELDS].
	Example HTTP requests and responses use the HTTP/2-style formatting		Example HTTP requests and responses use the HTTP/2-style formatting
	from [HTTP2].		from [HTTP2].
	This document uses the variable-length integer encoding from [QUIC].		This document uses the variable-length integer encoding from [QUIC].
	The term control stream is used to describe the HTTP/2 stream with		The term control stream is used to describe the HTTP/2 stream with
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 38 ¶
	The term HTTP/2 priority signal is used to describe the priority		The term HTTP/2 priority signal is used to describe the priority
	information sent from clients to servers in HTTP/2 frames; see		information sent from clients to servers in HTTP/2 frames; see
	Section 5.3.2 of [HTTP2].		Section 5.3.2 of [HTTP2].
	2. Motivation for Replacing RFC 7540 Priorities		2. Motivation for Replacing RFC 7540 Priorities
	RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex		RFC 7540 stream priority (see Section 5.3 of [RFC7540]) is a complex
	system where clients signal stream dependencies and weights to		system where clients signal stream dependencies and weights to
	describe an unbalanced tree. It suffered from limited deployment and		describe an unbalanced tree. It suffered from limited deployment and
	interoperability and was deprecated in a revision of HTTP/2 [HTTP2].		interoperability and was deprecated in a revision of HTTP/2 [HTTP2].
	However, in order to maintain wire compatibility, HTTP/2 priority		HTTP/2 retains these protocol elements in order to maintain wire
	signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]).		compatibility (see Section 5.3.2 of [HTTP2]), which means that they
			might still be used in the absence of alternative signaling, such as
	Clients can build RFC 7540 trees with rich flexibility but experience		the scheme this document describes.
	has shown this is rarely exercised. Instead they tend to choose a
	single model optimized for a single use case and experiment within
	the model constraints, or do nothing at all. Furthermore, many
	clients build their prioritization tree in a unique way, which makes
	it difficult for servers to understand their intent and act or
	intervene accordingly.
	Many RFC 7540 server implementations do not act on HTTP/2 priority		Many RFC 7540 server implementations do not act on HTTP/2 priority
	signals. Some instead favor custom server-driven schemes based on		signals.
	heuristics or other hints, such as resource content type or request
	generation order. For example, a server, with knowledge of an HTML
	document structure, might want to prioritize the delivery of images
	that are critical to user experience above other images, but below
	the CSS files. Since client trees vary, it is impossible for the
	server to determine how such images should be prioritized against
	other responses.
	RFC 7540 allows intermediaries to coalesce multiple client trees into
	a single tree that is used for a single upstream HTTP/2 connection.
	However, most intermediaries do not support this. Additionally, RFC
	7540 does not define a method that can be used by a server to express
	the priority of a response. Without such a method, intermediaries
	cannot coordinate client-driven and server-driven priorities.
	RFC 7540 describes denial-of-service considerations for		Prioritization can use information that servers have about resources
	implementations. On 2019-08-13 Netflix issued an advisory notice		or the order in which requests are generated. For example, a server,
	about the discovery of several resource exhaustion vectors affecting		with knowledge of an HTML document structure, might want to
	multiple RFC 7540 implementations. One attack, [CVE-2019-9513] aka		prioritize the delivery of images that are critical to user
	"Resource Loop", is based on using priority signals to manipulate the		experience above other images. With RFC 7540 it is difficult for
	server's stored prioritization state.		servers to interpret signals from clients for prioritization as the
			same conditions could result in very different signaling from
			different clients. This document describes signaling that is simpler
			and more constrained, requiring less interpretation and allowing less
			variation.
	HTTP/2 priority associated with an HTTP request is signalled as a		RFC 7540 does not define a method that can be used by a server to
	value relative to those of other requests sharing the same HTTP/2		provide a priority signal for intermediaries.
	connection. Therefore, in order to prioritize requests, endpoints
	are compelled to have the knowledge of the underlying HTTP version
	and how the requests are coalesced. This has been a burden to HTTP
	endpoints that generate or forward requests in a version-agnostic
	manner.
	HTTP/2 priority signals are required to be delivered and processed in		RFC 7540 priority is expressed relative to other requests on the same
	the order they are sent so that the receiver handling is		connection. Many requests are generated without knowledge of how
	deterministic. Porting HTTP/2 priority signals to protocols that do		other requests might share a connection, which makes this difficult
	not provide ordering guarantees presents challenges. For example,		to use reliably, especially in protocols that do not have strong
	HTTP/3 [HTTP3] lacks global ordering across streams that would carry		ordering guarantees, like HTTP/3 [HTTP3].
	priority signals. Early attempts to port HTTP/2 priority signals to
	HTTP/3 required adding additional information to the signals, leading
	to more complicated processing. Problems found with this approach
	could not be resolved and definition of a HTTP/3 priority signalling
	feature was removed before publication.
	Considering the deployment problems and the design restrictions of		Multiple experiments from independent research have shown that
	RFC 7540 stream priority, as well as the difficulties in adapting it		simpler schemes can reach at least equivalent performance
	to HTTP/3, continuing to base prioritization on this mechanism risks		characteristics compared to the more complex RFC 7540 setups seen in
	increasing the complexity of systems. Multiple experiments from		practice, at least for the web use case.
	independent research have shown that simpler schemes can reach at
	least equivalent performance characteristics compared to the more
	complex RFC 7540 setups seen in practice, at least for the web use
	case.
	2.1. Disabling RFC 7540 Priorities		2.1. Disabling RFC 7540 Priorities
	The problems and insights set out above provided the motivation for		The problems and insights set out above provided the motivation for
	deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]).		an alternative to RFC 7540 stream priority (see Section 5.3 of
			[HTTP2]).
	The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this		The SETTINGS_NO_RFC7540_PRIORITIES HTTP/2 setting is defined by this
	document in order to allow endpoints to omit or ignore HTTP/2		document in order to allow endpoints to omit or ignore HTTP/2
	priority signals (see Section 5.3.2 of [HTTP2]), as described below.		priority signals (see Section 5.3.2 of [HTTP2]), as described below.
	The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1. Any		The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1. Any
	value other than 0 or 1 MUST be treated as a connection error (see		value other than 0 or 1 MUST be treated as a connection error (see
	Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. The initial value		Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR. The initial value
	is 0.		is 0.
	If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they MUST send it in		If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they MUST send it in
	skipping to change at page 7, line 38 ¶		skipping to change at page 7, line 16 ¶
	indicate that they will ignore HTTP/2 priority signals sent by		indicate that they will ignore HTTP/2 priority signals sent by
	clients.		clients.
	Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to		Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to
	use alternative priority signals (for example, Section 5 or		use alternative priority signals (for example, Section 5 or
	Section 7.1) but there is no requirement to use a specific signal		Section 7.1) but there is no requirement to use a specific signal
	type.		type.
	2.1.1. Advice when Using Extensible Priorities as the Alternative		2.1.1. Advice when Using Extensible Priorities as the Alternative
	Until the client receives the SETTINGS frame from the server, the		Before receiving a SETTINGS frame from a server, a client does not
			know if the server is ignoring HTTP/2 priority signals. Therefore,
			until the client receives the SETTINGS frame from the server, the
	client SHOULD send both the HTTP/2 priority signals and the signals		client SHOULD send both the HTTP/2 priority signals and the signals
	of this prioritization scheme (see Section 5 and Section 7.1). When		of this prioritization scheme (see Section 5 and Section 7.1).
	the client receives the first SETTINGS frame that contains the
			Once the client receives the first SETTINGS frame that contains the
	SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD		SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD
	stop sending the HTTP/2 priority signals. If the value was 0 or if		stop sending the HTTP/2 priority signals. This avoids sending
	the settings parameter was absent, it SHOULD stop sending		redundant signals that are known to be ignored.
	PRIORITY_UPDATE frames (Section 7.1), but MAY continue sending the
			Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES with
			value of 0 or if the settings parameter was absent, it SHOULD stop
			sending PRIORITY_UPDATE frames (Section 7.1), since those frames are
			likely to be ignored. However, the client MAY continue sending the
	Priority header field (Section 5), as it is an end-to-end signal that		Priority header field (Section 5), as it is an end-to-end signal that
	might be useful to nodes behind the server that the client is		might be useful to nodes behind the server that the client is
	directly connected to.		directly connected to.
	3. Applicability of the Extensible Priority Scheme		3. Applicability of the Extensible Priority Scheme
	The priority scheme defined by this document considers only the		The priority scheme defined by this document considers only the
	prioritization of HTTP messages and tunnels, see Section 9,		prioritization of HTTP messages and tunnels, see Section 9,
	Section 10, and Section 11.		Section 10, and Section 11.
	skipping to change at page 24, line 39 ¶		skipping to change at page 24, line 15 ¶
	[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>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/rfc/rfc8126>.		<https://www.rfc-editor.org/rfc/rfc8126>.
			[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/rfc/rfc8174>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P-H. Kamp, "Structured Field Values for		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>.
	17.2. Informative References		17.2. Informative References
	[CACHING] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		[CACHING] 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-19, 12 September 2021,		httpbis-cache-19, 12 September 2021,
	skipping to change at page 26, line 22 ¶		skipping to change at page 25, line 45 ¶
	Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku,		Alan Frindell, Andrew Galloni, Craig Taylor, Ian Swett, Kazuho Oku,
	Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy		Lucas Pardue, Matthew Cox, Mike Bishop, Roberto Peon, Robin Marx, Roy
	Fielding.		Fielding.
	Yang Chi contributed the section on retransmission scheduling.		Yang Chi contributed the section on retransmission scheduling.
	Appendix B. Change Log		Appendix B. Change Log
	_RFC EDITOR: please remove this section before publication_		_RFC EDITOR: please remove this section before publication_
	B.1. Since draft-ietf-httpbis-priority-08		B.1. Since draft-ietf-httpbis-priority-09
			* Editorial changes
			B.2. Since draft-ietf-httpbis-priority-08
	* Changelog fixups		* Changelog fixups
	B.2. Since draft-ietf-httpbis-priority-07		B.3. Since draft-ietf-httpbis-priority-07
	* Relax requirements of receiving SETTINGS_NO_RFC7540_PRIORITIES		* Relax requirements of receiving SETTINGS_NO_RFC7540_PRIORITIES
	that changes value (#1714, #1725)		that changes value (#1714, #1725)
	* Clarify how intermediaries might use frames vs. headers (#1715,		* Clarify how intermediaries might use frames vs. headers (#1715,
	#1735)		#1735)
	* Relax requirement when receiving a PRIORITY_UPDATE with an invalid		* Relax requirement when receiving a PRIORITY_UPDATE with an invalid
	structured field value (#1741, #1756)		structured field value (#1741, #1756)
	B.3. Since draft-ietf-httpbis-priority-06		B.4. Since draft-ietf-httpbis-priority-06
	* Focus on editorial changes		* Focus on editorial changes
	* Clarify rules about Sf-Dictionary handling in headers		* Clarify rules about Sf-Dictionary handling in headers
	* Split policy for parameter IANA registry into two sections based		* Split policy for parameter IANA registry into two sections based
	on key length		on key length
	B.4. Since draft-ietf-httpbis-priority-05		B.5. Since draft-ietf-httpbis-priority-05
	* Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to		* Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to
	SETTINGS_NO_RFC7540_PRIORITIES		SETTINGS_NO_RFC7540_PRIORITIES
	* Clarify that senders of the HTTP/2 setting can use any alternative		* Clarify that senders of the HTTP/2 setting can use any alternative
	(#1679, #1705)		(#1679, #1705)
	B.5. Since draft-ietf-httpbis-priority-04		B.6. Since draft-ietf-httpbis-priority-04
	* Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to		* Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to
	SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601)		SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601)
	* Reoriented text towards RFC7540bis (#1561, #1601)		* Reoriented text towards RFC7540bis (#1561, #1601)
	* Clarify intermediary behavior (#1562)		* Clarify intermediary behavior (#1562)
	B.6. Since draft-ietf-httpbis-priority-03		B.7. Since draft-ietf-httpbis-priority-03
	* Add statement about what this scheme applies to. Clarify		* Add statement about what this scheme applies to. Clarify
	extensions can use it but must define how themselves (#1550,		extensions can use it but must define how themselves (#1550,
	#1559)		#1559)
	* Describe scheduling considerations for the CONNECT method (#1495,		* Describe scheduling considerations for the CONNECT method (#1495,
	#1544)		#1544)
	* Describe scheduling considerations for retransmitted data (#1429,		* Describe scheduling considerations for retransmitted data (#1429,
	#1504)		#1504)
	* Suggest intermediaries might avoid strict prioritization (#1562)		* Suggest intermediaries might avoid strict prioritization (#1562)
	B.7. Since draft-ietf-httpbis-priority-02		B.8. Since draft-ietf-httpbis-priority-02
	* Describe considerations for server push prioritization (#1056,		* Describe considerations for server push prioritization (#1056,
	#1345)		#1345)
	* Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261,		* Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261,
	#1344)		#1344)
	* Add a Parameters registry (#1371)		* Add a Parameters registry (#1371)
	B.8. Since draft-ietf-httpbis-priority-01		B.9. Since draft-ietf-httpbis-priority-01
	* PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,		* PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,
	#1271)		#1271)
	* Add section to describe server scheduling considerations (#1215,		* Add section to describe server scheduling considerations (#1215,
	#1232, #1266)		#1232, #1266)
	* Remove specific instructions related to intermediary fairness		* Remove specific instructions related to intermediary fairness
	(#1022, #1264)		(#1022, #1264)
	B.9. Since draft-ietf-httpbis-priority-00		B.10. Since draft-ietf-httpbis-priority-00
	* Move text around (#1217, #1218)		* Move text around (#1217, #1218)
	* Editorial change to the default urgency. The value is 3, which		* Editorial change to the default urgency. The value is 3, which
	was always the intent of previous changes.		was always the intent of previous changes.
	B.10. Since draft-kazuho-httpbis-priority-04		B.11. Since draft-kazuho-httpbis-priority-04
	* Minimize semantics of Urgency levels (#1023, #1026)		* Minimize semantics of Urgency levels (#1023, #1026)
	* Reduce guidance about how intermediary implements merging priority		* Reduce guidance about how intermediary implements merging priority
	signals (#1026)		signals (#1026)
	* Remove mention of CDN-Loop (#1062)		* Remove mention of CDN-Loop (#1062)
	* Editorial changes		* Editorial changes
	* Make changes due to WG adoption		* Make changes due to WG adoption
	* Removed outdated Consideration (#118)		* Removed outdated Consideration (#118)
	B.11. Since draft-kazuho-httpbis-priority-03		B.12. Since draft-kazuho-httpbis-priority-03
	* Changed numbering from [-1,6] to [0,7] (#78)		* Changed numbering from [-1,6] to [0,7] (#78)
	* Replaced priority scheme negotiation with HTTP/2 priority		* Replaced priority scheme negotiation with HTTP/2 priority
	deprecation (#100)		deprecation (#100)
	* Shorten parameter names (#108)		* Shorten parameter names (#108)
	* Expand on considerations (#105, #107, #109, #110, #111, #113)		* Expand on considerations (#105, #107, #109, #110, #111, #113)
	B.12. Since draft-kazuho-httpbis-priority-02		B.13. Since draft-kazuho-httpbis-priority-02
	* Consolidation of the problem statement (#61, #73)		* Consolidation of the problem statement (#61, #73)
	* Define SETTINGS_PRIORITIES for negotiation (#58, #69)		* Define SETTINGS_PRIORITIES for negotiation (#58, #69)
	* Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)		* Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)
	* Explain fairness issue and mitigations (#56)		* Explain fairness issue and mitigations (#56)
	B.13. Since draft-kazuho-httpbis-priority-01		B.14. Since draft-kazuho-httpbis-priority-01
	* Explain how reprioritization might be supported.		* Explain how reprioritization might be supported.
	B.14. Since draft-kazuho-httpbis-priority-00		B.15. Since draft-kazuho-httpbis-priority-00
	* Expand urgency levels from 3 to 8.		* Expand urgency levels from 3 to 8.
	Authors' Addresses		Authors' Addresses
	Kazuho Oku		Kazuho Oku
	Fastly		Fastly
	Email: kazuhooku@gmail.com		Email: kazuhooku@gmail.com
End of changes. 41 change blocks.
	116 lines changed or deleted		106 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/