draft-ietf-httpbis-priority-05.txt		draft-ietf-httpbis-priority-06.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: 28 March 2022 Cloudflare		Expires: 4 April 2022 Cloudflare
	24 September 2021		1 October 2021
	Extensible Prioritization Scheme for HTTP		Extensible Prioritization Scheme for HTTP
	draft-ietf-httpbis-priority-05		draft-ietf-httpbis-priority-06
	Abstract		Abstract
	This document describes a scheme for prioritizing HTTP responses.		This document describes a scheme for prioritizing HTTP responses.
	This scheme expresses the priority of each HTTP response using		This scheme expresses the priority of each HTTP response using
	absolute values, rather than as a relative relationship between a		absolute values, rather than as a relative relationship between a
	group of HTTP responses.		group of HTTP responses.
	This document defines the Priority header field for communicating the		This document defines the Priority header field for communicating the
	initial priority in an HTTP version-independent manner, as well as		initial priority in an HTTP version-independent manner, as well as
	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 28 March 2022.		This Internet-Draft will expire on 4 April 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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
	2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 4		2. Motivation for Replacing RFC 7540 Priorities . . . . . . . . 4
	2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6		2.1. Disabling RFC 7540 Priorities . . . . . . . . . . . . . . 6
			2.1.1. Advice when Using Extensible Priorities as the
			Alternative . . . . . . . . . . . . . . . . . . . . . 7
	3. Applicability of the Extensible Priority Scheme . . . . . . . 7		3. Applicability of the Extensible Priority Scheme . . . . . . . 7
	4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 7		4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 9		4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 9
	4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 9		4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 9
	5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 10		5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 10
	6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 11		6. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 11
	7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 11		7. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 11
	7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 12		7.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 12
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 6 ¶
	8. Merging Client- and Server-Driven Parameters . . . . . . . . 14		8. Merging Client- and Server-Driven Parameters . . . . . . . . 14
	9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 15		9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 15
	10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 15		10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Intermediaries with Multiple Backend Connections . . . . 17		10.1. Intermediaries with Multiple Backend Connections . . . . 17
	11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 17		11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 17
	12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 18		12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 18
	13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 18		13. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 18		13.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 18
	13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 19		13.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 19
	13.3. Intentional Introduction of Unfairness . . . . . . . . . 19		13.3. Intentional Introduction of Unfairness . . . . . . . . . 19
	14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 20		14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 20
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 20		15. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 22		17. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	17.1. Normative References . . . . . . . . . . . . . . . . . . 22		17.1. Normative References . . . . . . . . . . . . . . . . . . 22
	17.2. Informative References . . . . . . . . . . . . . . . . . 23		17.2. Informative References . . . . . . . . . . . . . . . . . 23
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24
	B.1. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 24		B.1. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 24
	B.2. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 25		B.2. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 25
	B.3. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 25		B.3. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 25
	B.4. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 25		B.4. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 25
	B.5. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 25		B.5. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 25
	B.6. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 26		B.6. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 25
	B.7. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 26		B.7. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 26
	B.8. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 26		B.8. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 26
	B.9. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 26		B.9. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		B.10. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 26
			B.11. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	It is common for an HTTP [HTTP] resource representation to have		It is common for an HTTP [HTTP] resource representation 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, leading to further retrieval requests. Meanwhile,		representation, leading to further retrieval requests. Meanwhile,
	the nature of the relationship determines whether the client is		the nature of the relationship determines whether the client is
	blocked from continuing to process locally available resources. For		blocked from continuing to process locally available resources. For
	example, visual rendering of an HTML document could be blocked by the		example, visual rendering of an HTML document could be blocked by the
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 50 ¶
	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
	An important feature of any implementation of a protocol that		An important feature of any implementation of a protocol that
	provides multiplexing is the ability to prioritize the sending of		provides multiplexing is the ability to prioritize the sending of
	information. Prioritization is a difficult problem, so it will		information. Prioritization is a difficult problem, so it will
	always be suboptimal, particularly if one endpoint operates in		always be suboptimal, particularly if one endpoint operates in
	ignorance of the needs of its peer. Priority signalling allows		ignorance of the needs of its peer. Priority signalling allows
	endpoints to communicate their own view of priority needs, which can		endpoints to communicate their own view of priority, which can be
	be combined with other factors that are considered during the peer's		combined with information the peer has to inform scheduling.
	prioritization decision making.
	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 poor 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		However, in order to maintain wire compatibility, HTTP/2 priority
	signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]).		signals are still mandatory to handle (see Section 5.3.2 of [HTTP2]).
	Clients can build RFC 7540 trees with rich flexibility but experience		Clients can build RFC 7540 trees with rich flexibility but experience
	has shown this is rarely exercised. Instead they tend to choose a		has shown this is rarely exercised. Instead they tend to choose a
	single model optimized for a single use case and experiment within		single model optimized for a single use case and experiment within
	the model constraints, or do nothing at all. Furthermore, many		the model constraints, or do nothing at all. Furthermore, many
	clients build their prioritization tree in a unique way, which makes		clients build their prioritization tree in a unique way, which makes
	it difficult for servers to understand their intent and act or		it difficult for servers to understand their intent and act or
	skipping to change at page 6, line 5 ¶		skipping to change at page 5, line 44 ¶
	the priority of a response. Without such a method, intermediaries		the priority of a response. Without such a method, intermediaries
	cannot coordinate client-driven and server-driven priorities.		cannot coordinate client-driven and server-driven priorities.
	RFC 7540 describes denial-of-service considerations for		RFC 7540 describes denial-of-service considerations for
	implementations. On 2019-08-13 Netflix issued an advisory notice		implementations. On 2019-08-13 Netflix issued an advisory notice
	about the discovery of several resource exhaustion vectors affecting		about the discovery of several resource exhaustion vectors affecting
	multiple RFC 7540 implementations. One attack, [CVE-2019-9513] aka		multiple RFC 7540 implementations. One attack, [CVE-2019-9513] aka
	"Resource Loop", is based on using priority signals to manipulate the		"Resource Loop", is based on using priority signals to manipulate the
	server's stored prioritization state.		server's stored prioritization state.
			HTTP/2 priority associated with an HTTP request is signalled as a
			value relative to those of other requests sharing the same HTTP/2
			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		HTTP/2 priority signals are required to be delivered and processed in
	the order they are sent so that the receiver handling is		the order they are sent so that the receiver handling is
	deterministic. Porting HTTP/2 priority signals to protocols that do		deterministic. Porting HTTP/2 priority signals to protocols that do
	not provide ordering guarantees presents challenges. For example,		not provide ordering guarantees presents challenges. For example,
	HTTP/3 [HTTP3] lacks global ordering across streams that would carry		HTTP/3 [HTTP3] lacks global ordering across streams that would carry
	priority signals. Early attempts to port HTTP/2 priority signals to		priority signals. Early attempts to port HTTP/2 priority signals to
	HTTP/3 required adding additional information to the signals, leading		HTTP/3 required adding additional information to the signals, leading
	to more complicated processing. Problems found with this approach		to more complicated processing. Problems found with this approach
	could not be resolved and definition of a HTTP/3 priority signalling		could not be resolved and definition of a HTTP/3 priority signalling
	feature was removed before publication.		feature was removed before publication.
	Considering the problems with the deployment of RFC 7540 stream		Considering the deployment problems and the design restrictions of
	priority, and the difficulties in adapting it to HTTP/3, continuing		RFC 7540 stream priority, as well as the difficulties in adapting it
	to base prioritization on this mechanism risks increasing the		to HTTP/3, continuing to base prioritization on this mechanism risks
	complexity of systems. Multiple experiments from independent		increasing the complexity of systems. Multiple experiments from
	research have shown that simpler schemes can reach at least		independent research have shown that simpler schemes can reach at
	equivalent performance characteristics compared to the more complex		least equivalent performance characteristics compared to the more
	RFC 7540 setups seen in practice, at least for the web use case.		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]).		deprecating RFC 7540 stream priority (see Section 5.3 of [RFC7540]).
	The SETTINGS_DEPRECATE_RFC7540_PRIORITIES setting is defined by this		The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this
	document in order to allow endpoints to explicitly opt out of using		document in order to allow endpoints to explicitly opt out of using
	HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints		HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints
	are expected to use an alternative, such as the scheme defined in		are encouraged to use alternative priority signals (for example,
	this specification.		Section 5 or Section 7.1) but there is no requirement to use a
			specific signal type.
	The value of SETTINGS_DEPRECATE_RFC7540_PRIORITIES MUST be 0 or 1.		The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1. Any
	Any value other than 0 or 1 MUST be treated as a connection error		value other than 0 or 1 MUST be treated as a connection error (see
	(see Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR.		Section 5.4.1 of [HTTP2]) of type PROTOCOL_ERROR.
	Endpoints MUST send this SETTINGS parameter as part of the first		Endpoints MUST send this SETTINGS parameter as part of the first
	SETTINGS frame. A sender MUST NOT change the		SETTINGS frame. A sender MUST NOT change the
	SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter value after the first		SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first
	SETTINGS frame. Detection of a change by a receiver MUST be treated		SETTINGS frame. Detection of a change by a receiver MUST be treated
	as a connection error of type PROTOCOL_ERROR.		as a connection error of type PROTOCOL_ERROR.
			The SETTINGS frame precedes any HTTP/2 priority signal sent from a
			client, so a server can determine if it needs to allocate any
			resource to signal handling before they arrive. A server that
			receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore
			HTTP/2 priority signals.
			2.1.1. Advice when Using Extensible Priorities as the Alternative
	Until the client receives the SETTINGS frame from the server, the		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). When
	the client receives the first SETTINGS frame that contains the		the client receives the first SETTINGS frame that contains the
	SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter with value of 1, it		SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD
	SHOULD stop sending the HTTP/2 priority signals. If the value was 0		stop sending the HTTP/2 priority signals. If the value was 0 or if
	or if the settings parameter was absent, it SHOULD stop sending		the settings parameter was absent, it SHOULD stop sending
	PRIORITY_UPDATE frames (Section 7.1), but MAY continue sending the		PRIORITY_UPDATE frames (Section 7.1), but 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.
	The SETTINGS frame precedes any HTTP/2 priority signal sent from a
	client, so a server can determine if it needs to allocate any
	resource to signal handling before they arrive. A server that
	receives SETTINGS_DEPRECATE_RFC7540_PRIORITIES with value of 1 MUST
	ignore HTTP/2 priority signals.
	Where both endpoints disable RFC 7540 stream priority, the client is
	expected to send this scheme's priority signal. Handling of omitted
	signals is described in Section 4.
	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.
	Where HTTP extensions change stream behavior or define new data		Where HTTP extensions change stream behavior or define new data
	carriage mechanisms, they can also define how this priority scheme		carriage mechanisms, they can also define how this priority scheme
	can be applied.		can be applied.
	skipping to change at page 21, line 40 ¶		skipping to change at page 21, line 40 ¶
	Author/change controller: IETF		Author/change controller: IETF
	Specification document(s): This document		Specification document(s): This document
	Related information: n/a		Related information: n/a
	This specification registers the following entry in the HTTP/2		This specification registers the following entry in the HTTP/2
	Settings registry established by [HTTP2]:		Settings registry established by [HTTP2]:
	Name: SETTINGS_DEPRECATE_RFC7540_PRIORITIES		Name: SETTINGS_NO_RFC7540_PRIORITIES
	Code: 0x9		Code: 0x9
	Initial value: 0		Initial value: 0
	Specification: This document		Specification: This document
	This specification registers the following entry in the HTTP/2 Frame		This specification registers the following entry in the HTTP/2 Frame
	Type registry established by [HTTP2]:		Type registry established by [HTTP2]:
	skipping to change at page 22, line 35 ¶		skipping to change at page 22, line 35 ¶
	17.1. Normative References		17.1. Normative References
	[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Semantics", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-semantics-19, 12 September 2021,		httpbis-semantics-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	semantics-19>.		semantics-19>.
	[HTTP2] Thomson, M. and C. Benfield, "Hypertext Transfer Protocol		[HTTP2] Thomson, M. and C. Benfield, "Hypertext Transfer Protocol
	Version 2 (HTTP/2)", Work in Progress, Internet-Draft,		Version 2 (HTTP/2)", Work in Progress, Internet-Draft,
	draft-ietf-httpbis-http2bis-04, 23 September 2021,		draft-ietf-httpbis-http2bis-05, 26 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	http2bis-04>.		http2bis-05>.
	[HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3		[HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-		(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
	quic-http-34, 2 February 2021,		quic-http-34, 2 February 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-quic-		<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
	http-34>.		http-34>.
	[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", RFC 9000,		Multiplexed and Secure Transport", RFC 9000,
	DOI 10.17487/RFC9000, May 2021,		DOI 10.17487/RFC9000, May 2021,
	skipping to change at page 24, line 28 ¶		skipping to change at page 24, line 28 ¶
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Roy Fielding presented the idea of using a header field for		Roy Fielding presented the idea of using a header field for
	representing priorities in http://tools.ietf.org/agenda/83/slides/		representing priorities in http://tools.ietf.org/agenda/83/slides/
	slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/		slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/
	slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3-		slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3-
	prioritization-proposal (https://github.com/pmeenan/http3-		prioritization-proposal (https://github.com/pmeenan/http3-
	prioritization-proposal), Patrick Meenan advocates for representing		prioritization-proposal), Patrick Meenan advocates for representing
	the priorities using a tuple of urgency and concurrency. The ability		the priorities using a tuple of urgency and concurrency. The ability
	to deprecate HTTP/2 prioritization is based on		to disable HTTP/2 prioritization is inspired by
	[I-D.lassey-priority-setting], authored by Brad Lassey and Lucas		[I-D.lassey-priority-setting], authored by Brad Lassey and Lucas
	Pardue, with modifications based on feedback that was not		Pardue, with modifications based on feedback that was not
	incorporated into an update to that document.		incorporated into an update to that document.
	The motivation for defining an alternative to HTTP/2 priorities is		The motivation for defining an alternative to HTTP/2 priorities is
	drawn from discussion within the broad HTTP community. Special		drawn from discussion within the broad HTTP community. Special
	thanks to Roberto Peon, Martin Thomson and Netflix for text that was		thanks to Roberto Peon, Martin Thomson and Netflix for text that was
	incorporated explicitly in this document.		incorporated explicitly in this document.
	In addition to the people above, this document owes a lot to the		In addition to the people above, this document owes a lot to the
	extensive discussion in the HTTP priority design team, consisting of		extensive discussion in the HTTP priority design team, consisting of
	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.
	Appendix B. Change Log		Appendix B. Change Log
	B.1. Since draft-ietf-httpbis-priority-03		B.1. Since draft-ietf-httpbis-priority-05
			* Renamed SETTINGS_DEPRECATE_RFC7540_PRIORITIES to
			SETTINGS_NO_RFC7540_PRIORITIES
			* Clarify that senders of the HTTP/2 setting can use any alternative
			(#1679, #1705)
			B.2. Since draft-ietf-httpbis-priority-04
			* Renamed SETTINGS_DEPRECATE_HTTP2_PRIORITIES to
			SETTINGS_DEPRECATE_RFC7540_PRIORITIES (#1601)
			* Reoriented text towards RFC7540bis (#1561, #1601)
			* Clarify intermediary behavior (#1562)
			B.3. 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.2. Since draft-ietf-httpbis-priority-02		B.4. 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.3. Since draft-ietf-httpbis-priority-01		B.5. 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.4. Since draft-ietf-httpbis-priority-00		B.6. 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.5. Since draft-kazuho-httpbis-priority-04		B.7. 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
	skipping to change at page 26, line 4 ¶		skipping to change at page 26, line 19 ¶
	* 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.6. Since draft-kazuho-httpbis-priority-03		B.8. 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.7. Since draft-kazuho-httpbis-priority-02		B.9. 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.8. Since draft-kazuho-httpbis-priority-01		B.10. Since draft-kazuho-httpbis-priority-01
	* Explain how reprioritization might be supported.		* Explain how reprioritization might be supported.
	B.9. Since draft-kazuho-httpbis-priority-00		B.11. 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. 32 change blocks.
	60 lines changed or deleted		87 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/