< draft-ietf-httpbis-priority-07.txt		draft-ietf-httpbis-priority-08.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 April 2022 Cloudflare		Expires: 12 May 2022 Cloudflare
	25 October 2021		8 November 2021
	Extensible Prioritization Scheme for HTTP		Extensible Prioritization Scheme for HTTP
	draft-ietf-httpbis-priority-07		draft-ietf-httpbis-priority-08
	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 28 April 2022.		This Internet-Draft will expire on 12 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
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	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 . . . . . . . . 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 . . . . . . . 7		3. Applicability of the Extensible Priority Scheme . . . . . . . 8
	4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 8		4. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10		4.3. Defining New Parameters . . . . . . . . . . . . . . . . . 10
	4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 10		4.3.1. Registration . . . . . . . . . . . . . . . . . . . . 11
	5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 11		5. The Priority HTTP Header Field . . . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . . . 14		7.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 15
	8. Merging Client- and Server-Driven Parameters . . . . . . . . 15		8. Merging Client- and Server-Driven Parameters . . . . . . . . 16
	9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 16		9. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 17
	10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17		10. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Intermediaries with Multiple Backend Connections . . . . 18		10.1. Intermediaries with Multiple Backend Connections . . . . 19
	11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19		11. Scheduling and the CONNECT Method . . . . . . . . . . . . . . 19
	12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 19		12. Retransmission Scheduling . . . . . . . . . . . . . . . . . . 20
	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? . . . . . . . . . . . . . 21		14. Why use an End-to-End Header Field? . . . . . . . . . . . . . 22
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 22		15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	17.1. Normative References . . . . . . . . . . . . . . . . . . 23		17.1. Normative References . . . . . . . . . . . . . . . . . . 24
	17.2. Informative References . . . . . . . . . . . . . . . . . 24		17.2. Informative References . . . . . . . . . . . . . . . . . 24
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
	B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 25		B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
	B.2. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26		B.2. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
	B.3. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26		B.3. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26
	B.4. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 26		B.4. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26
	B.5. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 26		B.5. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27
	B.6. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 26		B.6. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27
	B.7. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27		B.7. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27
	B.8. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27		B.8. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27
	B.9. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 27		B.9. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27
	B.10. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 27		B.10. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28
	B.11. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 27		B.11. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28
	B.12. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28		B.12. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28
			B.13. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 6 ¶
	least equivalent performance characteristics compared to the more		least equivalent performance characteristics compared to the more
	complex RFC 7540 setups seen in practice, at least for the web use		complex RFC 7540 setups seen in practice, at least for the web use
	case.		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_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 explicitly opt out of using		document in order to allow endpoints to omit or ignore HTTP/2
	HTTP/2 priority signals (see Section 5.3.2 of [HTTP2]). Endpoints		priority signals (see Section 5.3.2 of [HTTP2]), as described below.
	are encouraged to use alternative priority signals (for example,
	Section 5 or Section 7.1) but there is no requirement to use a
	specific signal type.
	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.
	Endpoints MUST send this SETTINGS parameter as part of the first		If endpoints use SETTINGS_NO_RFC7540_PRIORITIES they MUST send it in
	SETTINGS frame. A sender MUST NOT change the		the first SETTINGS frame. Senders MUST NOT change the
	SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first		SETTINGS_NO_RFC7540_PRIORITIES value after the first SETTINGS frame.
	SETTINGS frame. Detection of a change by a receiver MUST be treated		Receivers that detect a change MAY treat it as a connection error of
	as a connection error of type PROTOCOL_ERROR.		type PROTOCOL_ERROR.
	The SETTINGS frame precedes any HTTP/2 priority signal sent from a		Clients can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to
	client, so a server can determine if it needs to allocate any		indicate that they are not using HTTP/2 priority signals. The
	resource to signal handling before they arrive. A server that		SETTINGS frame precedes any HTTP/2 priority signal sent from clients,
	receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore		so servers can determine whether they need to allocate any resources
	HTTP/2 priority signals.		to signal handling before signals arrive. A server that receives
			SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 MUST ignore HTTP/2
			priority signals.
			Servers can send SETTINGS_NO_RFC7540_PRIORITIES with a value of 1 to
			indicate that they will ignore HTTP/2 priority signals sent by
			clients.
			Endpoints that send SETTINGS_NO_RFC7540_PRIORITIES are encouraged to
			use alternative priority signals (for example, Section 5 or
			Section 7.1) but there is no requirement to use a specific signal
			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		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_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. If the value was 0 or if
	the settings parameter was absent, it SHOULD stop sending		the settings parameter was absent, it SHOULD stop sending
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 25 ¶
	4. Priority Parameters		4. Priority Parameters
	The priority information is a sequence of key-value pairs, providing		The priority information is a sequence of key-value pairs, providing
	room for future extensions. Each key-value pair represents a		room for future extensions. Each key-value pair represents a
	priority parameter.		priority parameter.
	The Priority HTTP header field (Section 5) is an end-to-end way to		The Priority HTTP header field (Section 5) is an end-to-end way to
	transmit this set of parameters when a request or a response is		transmit this set of parameters when a request or a response is
	issued. In order to reprioritize a request, HTTP-version-specific		issued. In order to reprioritize a request, HTTP-version-specific
	PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by		PRIORITY_UPDATE frames (Section 7.1 and Section 7.2) are used by
	clients to transmit the same information on a single hop. If		clients to transmit the same information on a single hop.
	intermediaries want to specify prioritization on a multiplexed HTTP
	connection, they SHOULD use a PRIORITY_UPDATE frame and SHOULD NOT
	change the Priority header field.
	In both cases, the set of priority parameters is encoded as a		Intermediaries can consume and produce priority signals in a
	Structured Fields Dictionary (see Section 3.2 of		PRIORITY_UPDATE frame or Priority header field. Sending a
	[STRUCTURED-FIELDS]).		PRIORITY_UPDATE frame preserves the signal from the client, but
			provides a signal that overrides for the next hop; see Section 14.
			Replacing or adding a Priority header field overrides any signal from
			a client and can affect prioritization for all subsequent recipients.
			For both the Priority header field and the PRIORITY_UPDATE frame, the
			set of priority parameters is encoded as a Structured Fields
			Dictionary (see Section 3.2 of [STRUCTURED-FIELDS]).
	This document defines the urgency(u) and incremental(i) parameters.		This document defines the urgency(u) and incremental(i) parameters.
	When receiving an HTTP request that does not carry these priority		When receiving an HTTP request that does not carry these priority
	parameters, a server SHOULD act as if their default values were		parameters, a server SHOULD act as if their default values were
	specified. Note that handling of omitted parameters is different		specified. Note that handling of omitted parameters is different
	when processing an HTTP response; see Section 8.		when processing an HTTP response; see Section 8.
	Receivers parse the Dictionary as defined in Section 4.2 of		Receivers parse the Dictionary as defined in Section 4.2 of
	[STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed,		[STRUCTURED-FIELDS]. Where the Dictionary is successfully parsed,
	this document places the additional requirement that unknown priority		this document places the additional requirement that unknown priority
	skipping to change at page 12, line 36 ¶		skipping to change at page 13, line 14 ¶
	PRIORITY_UPDATE frames are sent by clients on the control stream,		PRIORITY_UPDATE frames are sent by clients on the control stream,
	allowing them to be sent independent from the stream that carries the		allowing them to be sent independent from the stream that carries the
	response. This means they can be used to reprioritize a response or		response. This means they can be used to reprioritize a response or
	a push stream; or signal the initial priority of a response instead		a push stream; or signal the initial priority of a response instead
	of the Priority header field.		of the Priority header field.
	A PRIORITY_UPDATE frame communicates a complete set of all parameters		A PRIORITY_UPDATE frame communicates a complete set of all parameters
	in the Priority Field Value field. Omitting a parameter is a signal		in the Priority Field Value field. Omitting a parameter is a signal
	to use the parameter's default value. Failure to parse the Priority		to use the parameter's default value. Failure to parse the Priority
	Field Value MUST be treated as a connection error. In HTTP/2 the		Field Value MAY be treated as a connection error. In HTTP/2 the
	error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type		error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type
	H3_FRAME_ERROR.		H3_GENERAL_PROTOCOL_ERROR.
	A client MAY send a PRIORITY_UPDATE frame before the stream that it		A client MAY send a PRIORITY_UPDATE frame before the stream that it
	references is open (except for HTTP/2 push streams; see Section 7.1).		references is open (except for HTTP/2 push streams; see Section 7.1).
	Furthermore, HTTP/3 offers no guaranteed ordering across streams,		Furthermore, HTTP/3 offers no guaranteed ordering across streams,
	which could cause the frame to be received earlier than intended.		which could cause the frame to be received earlier than intended.
	Either case leads to a race condition where a server receives a		Either case leads to a race condition where a server receives a
	PRIORITY_UPDATE frame that references a request stream that is yet to		PRIORITY_UPDATE frame that references a request stream that is yet to
	be opened. To solve this condition, for the purposes of scheduling,		be opened. To solve this condition, for the purposes of scheduling,
	the most recently received PRIORITY_UPDATE frame can be considered as		the most recently received PRIORITY_UPDATE frame can be considered as
	the most up-to-date information that overrides any other signal.		the most up-to-date information that overrides any other signal.
	skipping to change at page 25, line 45 ¶		skipping to change at page 26, line 22 ¶
	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
	B.1. Since draft-ietf-httpbis-priority-06		B.1. Since draft-ietf-httpbis-priority-06
			* Relax requirements of receiving SETTINGS_NO_RFC7540_PRIORITIES
			that changes value (#1714, #1725)
			* Clarify how intermediaries might use frames vs. headers (#1715,
			#1735)
			* Relax requirement when receiving a PRIORITY_UPDATE with an invalid
			structured field value (#1741, #1756)
			B.2. 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.2. Since draft-ietf-httpbis-priority-05		B.3. 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.3. Since draft-ietf-httpbis-priority-04		B.4. 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.4. Since draft-ietf-httpbis-priority-03		B.5. 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.5. Since draft-ietf-httpbis-priority-02		B.6. 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.6. Since draft-ietf-httpbis-priority-01		B.7. 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.7. Since draft-ietf-httpbis-priority-00		B.8. 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.8. Since draft-kazuho-httpbis-priority-04		B.9. 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.9. Since draft-kazuho-httpbis-priority-03		B.10. 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.10. Since draft-kazuho-httpbis-priority-02		B.11. 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.11. Since draft-kazuho-httpbis-priority-01		B.12. Since draft-kazuho-httpbis-priority-01
	* Explain how reprioritization might be supported.		* Explain how reprioritization might be supported.
	B.12. Since draft-kazuho-httpbis-priority-00		B.13. 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
	Lucas Pardue		Lucas Pardue
	Cloudflare		Cloudflare
	Email: lucaspardue.24.7@gmail.com		Email: lucaspardue.24.7@gmail.com
End of changes. 33 change blocks.
	67 lines changed or deleted		89 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/