< draft-ietf-httpbis-priority-08.txt		draft-ietf-httpbis-priority-09.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: 12 May 2022 Cloudflare		Expires: 14 May 2022 Cloudflare
	8 November 2021		10 November 2021
	Extensible Prioritization Scheme for HTTP		Extensible Prioritization Scheme for HTTP
	draft-ietf-httpbis-priority-08		draft-ietf-httpbis-priority-09
	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 12 May 2022.		This Internet-Draft will expire on 14 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 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	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? . . . . . . . . . . . . . 22
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 22		15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23		17. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	17.1. Normative References . . . . . . . . . . . . . . . . . . 24		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 . . . . . . . . . . . . . . . . . . . . . 26		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
	B.1. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26		B.1. Since draft-ietf-httpbis-priority-08 . . . . . . . . . . 26
	B.2. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26		B.2. Since draft-ietf-httpbis-priority-07 . . . . . . . . . . 26
	B.3. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26		B.3. Since draft-ietf-httpbis-priority-06 . . . . . . . . . . 26
	B.4. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 26		B.4. Since draft-ietf-httpbis-priority-05 . . . . . . . . . . 26
	B.5. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27		B.5. Since draft-ietf-httpbis-priority-04 . . . . . . . . . . 27
	B.6. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27		B.6. Since draft-ietf-httpbis-priority-03 . . . . . . . . . . 27
	B.7. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27		B.7. Since draft-ietf-httpbis-priority-02 . . . . . . . . . . 27
	B.8. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27		B.8. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 27
	B.9. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 27		B.9. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 27
	B.10. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28		B.10. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 28
	B.11. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28		B.11. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 28
	B.12. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28		B.12. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 28
	B.13. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28		B.13. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		B.14. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 28
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	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 8, line 30 ¶		skipping to change at page 8, line 30 ¶
	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.		clients to transmit the same information on a single hop.
	Intermediaries can consume and produce priority signals in a		Intermediaries can consume and produce priority signals in a
	PRIORITY_UPDATE frame or Priority header field. Sending a		PRIORITY_UPDATE frame or Priority header field. Sending a
	PRIORITY_UPDATE frame preserves the signal from the client, but		PRIORITY_UPDATE frame preserves the signal from the client, but
	provides a signal that overrides for the next hop; see Section 14.		provides a signal that overrides that for the next hop; see
	Replacing or adding a Priority header field overrides any signal from		Section 14. Replacing or adding a Priority header field overrides
	a client and can affect prioritization for all subsequent recipients.		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		For both the Priority header field and the PRIORITY_UPDATE frame, the
	set of priority parameters is encoded as a Structured Fields		set of priority parameters is encoded as a Structured Fields
	Dictionary (see Section 3.2 of [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.
	skipping to change at page 26, line 20 ¶		skipping to change at page 26, line 20 ¶
	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.
	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		_RFC EDITOR: please remove this section before publication_
			B.1. Since draft-ietf-httpbis-priority-08
			* Changelog fixups
			B.2. 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.2. Since draft-ietf-httpbis-priority-06		B.3. 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.3. Since draft-ietf-httpbis-priority-05		B.4. 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.4. Since draft-ietf-httpbis-priority-04		B.5. 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.5. Since draft-ietf-httpbis-priority-03		B.6. 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.6. Since draft-ietf-httpbis-priority-02		B.7. 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.7. Since draft-ietf-httpbis-priority-01		B.8. 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.8. Since draft-ietf-httpbis-priority-00		B.9. 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.9. Since draft-kazuho-httpbis-priority-04		B.10. 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.10. Since draft-kazuho-httpbis-priority-03		B.11. 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.11. Since draft-kazuho-httpbis-priority-02		B.12. 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.12. Since draft-kazuho-httpbis-priority-01		B.13. Since draft-kazuho-httpbis-priority-01
	* Explain how reprioritization might be supported.		* Explain how reprioritization might be supported.
	B.13. Since draft-kazuho-httpbis-priority-00		B.14. 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. 20 change blocks.
	35 lines changed or deleted		44 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/