draft-ietf-httpbis-priority-02.txt		draft-ietf-httpbis-priority-03.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: April 4, 2021 Cloudflare		Expires: 15 July 2021 Cloudflare
	October 01, 2020		11 January 2021
	Extensible Prioritization Scheme for HTTP		Extensible Prioritization Scheme for HTTP
	draft-ietf-httpbis-priority-02		draft-ietf-httpbis-priority-03
	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
	HTTP/2 and HTTP/3 frames for reprioritizing the responses. These		HTTP/2 and HTTP/3 frames for reprioritizing the responses. These
	share a common format structure that is designed to provide future		share a common format structure that is designed to provide future
	extensibility.		extensibility.
	Note to Readers		Note to Readers
	_RFC EDITOR: please remove this section before publication_		_RFC EDITOR: please remove this section before publication_
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	https://lists.w3.org/Archives/Public/ietf-http-wg/ [1].		https://lists.w3.org/Archives/Public/ietf-http-wg/
			(https://lists.w3.org/Archives/Public/ietf-http-wg/).
	Working Group information can be found at https://httpwg.org/ [2];		Working Group information can be found at https://httpwg.org/
	source code and issues list for this draft can be found at		(https://httpwg.org/); source code and issues list for this draft can
	https://github.com/httpwg/http-extensions/labels/priorities [3].		be found at https://github.com/httpwg/http-extensions/labels/
			priorities (https://github.com/httpwg/http-extensions/labels/
			priorities).
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 4, 2021.		This Internet-Draft will expire on 15 July 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
	2. Motivation for Replacing HTTP/2 Priorities . . . . . . . . . 4		2. Motivation for Replacing HTTP/2 Priorities . . . . . . . . . 4
	2.1. Disabling HTTP/2 Priorities . . . . . . . . . . . . . . . 5		2.1. Disabling HTTP/2 Priorities . . . . . . . . . . . . . . . 5
	3. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 6		3. Priority Parameters . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8		3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8
	4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 8		3.3.1. Registration . . . . . . . . . . . . . . . . . . . . 9
	5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 9		4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 9
	6. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 9		5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 10		6. The PRIORITY_UPDATE Frame . . . . . . . . . . . . . . . . . . 10
	6.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 11		6.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 11
	7. Merging Client- and Server-Driven Parameters . . . . . . . . 12		6.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 12
	8. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 13		7. Merging Client- and Server-Driven Parameters . . . . . . . . 13
	9. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 13		8. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 14
	10. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Server Scheduling . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 15		10. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 15		10.1. Coalescing Intermediaries . . . . . . . . . . . . . . . 16
	10.3. Intentional Introduction of Unfairness . . . . . . . . . 16		10.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 17
	11. Why use an End-to-End Header Field? . . . . . . . . . . . . . 16		10.3. Intentional Introduction of Unfairness . . . . . . . . . 17
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 16		11. Why use an End-to-End Header Field? . . . . . . . . . . . . . 17
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	14.1. Normative References . . . . . . . . . . . . . . . . . . 18		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	14.2. Informative References . . . . . . . . . . . . . . . . . 19		14.1. Normative References . . . . . . . . . . . . . . . . . . 20
	14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19		14.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
	B.1. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 20		B.1. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 22
	B.2. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 20		B.2. Since draft-ietf-httpbis-priority-01 . . . . . . . . . . 22
	B.3. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 21		B.3. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 22
	B.4. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 21		B.4. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 22
	B.5. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 21		B.5. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 23
	B.6. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 21		B.6. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 23
	B.7. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 21		B.7. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		B.8. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	It is common for an HTTP ([RFC7230]) resource representation to have		It is common for an HTTP ([RFC7230]) 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 8, line 20 ¶		skipping to change at page 8, line 37 ¶
	"true".		"true".
	:method = GET		:method = GET
	:scheme = https		:scheme = https
	:authority = example.net		:authority = example.net
	:path = /image.jpg		:path = /image.jpg
	priority = u=5, i		priority = u=5, i
	3.3. Defining New Parameters		3.3. Defining New Parameters
	When attempting to extend priorities, care must be taken to ensure		When attempting to define new parameters, care must be taken so that
	any use of existing parameters leaves them either unchanged or		they do not adversely interfere with prioritization performed by
	modified in a way that is backwards compatible for peers that are		existing endpoints or intermediaries that do not understand the newly
	unaware of the extended meaning.		defined parameter. Since unknown parameters are ignored, new
			parameters should not change the interpretation of or modify the
			predefined parameters in a way that is not backwards compatible or
			fallback safe.
	For example, if there is a need to provide more granularity than		For example, if there is a need to provide more granularity than
	eight urgency levels, it would be possible to subdivide the range		eight urgency levels, it would be possible to subdivide the range
	using an additional parameter. Implementations that do not recognize		using an additional parameter. Implementations that do not recognize
	the parameter can safely continue to use the less granular eight		the parameter can safely continue to use the less granular eight
	levels.		levels.
	Alternatively, the urgency can be augmented. For example, a		Alternatively, the urgency can be augmented. For example, a
	graphical user agent could send a "visible" parameter to indicate if		graphical user agent could send a "visible" parameter to indicate if
	the resource being requested is within the viewport.		the resource being requested is within the viewport.
			Generic parameters are preferred over vendor-specific, application-
			specific or deployment-specific values. If a generic value cannot be
			agreed upon in the community, the parameter's name should be
			correspondingly specific (e.g., with a prefix that identifies the
			vendor, application or deployment).
			3.3.1. Registration
			New Priority parameters can be defined by registering them in the
			HTTP Priority Parameters Registry.
			Registration requests are reviewed and approved by a Designated
			Expert, as per [RFC8126], Section 4.5. A specification document is
			appreciated, but not required.
			The Expert(s) should consider the following factors when evaluating
			requests:
			* Community feedback
			* If the parameters are sufficiently well-defined and adhere to the
			guidance provided in Section 3.3.
			Registration requests should use the following template:
			* Name: [a name for the Priority Parameter that matches key]
			* Description: [a description of the parameter semantics and value]
			* Reference: [to a specification defining this parameter]
			See the registry at https://iana.org/assignments/http-priority
			(https://iana.org/assignments/http-priority) for details on where to
			send registration requests.
	4. The Priority HTTP Header Field		4. The Priority HTTP Header Field
	The Priority HTTP header field can appear in requests and responses.		The Priority HTTP header field can appear in requests and responses.
	A client uses it to specify the priority of the response. A server		A client uses it to specify the priority of the response. A server
	uses it to inform the client that the priority was overwritten. An		uses it to inform the client that the priority was overwritten. An
	intermediary can use the Priority information from client requests		intermediary can use the Priority information from client requests
	and server responses to correct or amend the precedence to suit it		and server responses to correct or amend the precedence to suit it
	(see Section 7).		(see Section 7).
	The Priority header field is an end-to-end signal of the request		The Priority header field is an end-to-end signal of the request
	skipping to change at page 9, line 46 ¶		skipping to change at page 11, line 6 ¶
	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 MUST 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_FRAME_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. Furthermore, HTTP/3 offers no guaranteed		references is open (except for HTTP/2 push streams; see Section 6.1).
	ordering across streams, which could cause the frame to be received		Furthermore, HTTP/3 offers no guaranteed ordering across streams,
	earlier than intended. Either case leads to a race condition where a		which could cause the frame to be received earlier than intended.
	server receives a PRIORITY_UPDATE frame that references a request		Either case leads to a race condition where a server receives a
	stream that is yet to be opened. To solve this condition, for the		PRIORITY_UPDATE frame that references a request stream that is yet to
	purposes of scheduling, the most recently received PRIORITY_UPDATE		be opened. To solve this condition, for the purposes of scheduling,
	frame can be considered as the most up-to-date information that		the most recently received PRIORITY_UPDATE frame can be considered as
	overrides any other signal. Servers SHOULD buffer the most recently		the most up-to-date information that overrides any other signal.
	received PRIORITY_UPDATE frame and apply it once the referenced		Servers SHOULD buffer the most recently received PRIORITY_UPDATE
	stream is opened. Holding PRIORITY_UPDATE frames for each stream		frame and apply it once the referenced stream is opened. Holding
	requires server resources, which can can be bound by local		PRIORITY_UPDATE frames for each stream requires server resources,
	implementation policy. (TODO: consider resolving #1261, and adding		which can can be bound by local implementation policy. Although
	more text about bounds). Although there is no limit to the number		there is no limit to the number of PRIORITY_UPDATES that can be sent,
	PRIORITY_UPDATES that can be sent, storing only the most recently		storing only the most recently received frame limits resource
	received frame limits resource commitment.		commitment.
	6.1. HTTP/2 PRIORITY_UPDATE Frame		6.1. HTTP/2 PRIORITY_UPDATE Frame
	The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to		The HTTP/2 PRIORITY_UPDATE frame (type=0x10) is used by clients to
	signal the initial priority of a response, or to reprioritize a		signal the initial priority of a response, or to reprioritize a
	response or push stream. It carries the stream ID of the response		response or push stream. It carries the stream ID of the response
	and the priority in ASCII text, using the same representation as the		and the priority in ASCII text, using the same representation as the
	Priority header field value.		Priority header field value.
	The Stream Identifier field ([RFC7540], Section 4.1) in the		The Stream Identifier field ([RFC7540], Section 4.1) in the
	skipping to change at page 10, line 35 ¶		skipping to change at page 11, line 43 ¶
	as a connection error of type PROTOCOL_ERROR.		as a connection error of type PROTOCOL_ERROR.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	|R| Prioritized Stream ID (31) |		|R| Prioritized Stream ID (31) |
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	| Priority Field Value (*) ...		| Priority Field Value (*) ...
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Figure 1: HTTP/2 PRIORITY_UPDATE Frame Payload		Figure 1: HTTP/2 PRIORITY_UPDATE Frame Payload
	The PRIORITY_UPDATE frame payload has the following fields:		The PRIORITY_UPDATE frame payload has the following fields:
	R: A reserved 1-bit field. The semantics of this bit are undefined,		R: A reserved 1-bit field. The semantics of this bit are undefined,
	and the bit MUST remain unset (0x0) when sending and MUST be		and the bit MUST remain unset (0x0) when sending and MUST be
	ignored when receiving.		ignored when receiving.
	Prioritized Stream ID: A 31-bit stream identifier for the stream		Prioritized Stream ID: A 31-bit stream identifier for the stream
	that is the target of the priority update.		that is the target of the priority update.
	Priority Field Value: The priority update value in ASCII text,		Priority Field Value: The priority update value in ASCII text,
	encoded using Structured Fields.		encoded using Structured Fields.
	The Prioritized Stream ID MUST be within the stream limit. If a		When the PRIORITY_UPDATE frame applies to a request stream, clients
	server receives a PRIORITY_UPDATE with a Prioritized Stream ID that		SHOULD provide a Prioritized Stream ID that refers to a stream in the
	is beyond the stream limits, this SHOULD be treated as a connection		"open", "half-closed (local)", or "idle" state. Servers can discard
	error of type PROTOCOL_ERROR.		frames where the Prioritized Stream ID refers to a stream in the
			"half-closed (local)" or "closed" state. The number of streams which
			have been prioritized but remain in the "idle" state plus the number
			of active streams (those in the "open" or either "half-closed" state;
			see section 5.1.2 of [RFC7540]) MUST NOT exceed the value of the
			SETTINGS_MAX_CONCURRENT_STREAMS parameter. Servers that receive such
			a PRIORITY_UPDATE MUST respond with a connection error of type
			PROTOCOL_ERROR.
			When the PRIORITY_UPDATE frame applies to a push stream, clients
			SHOULD provide a Prioritized Stream ID that refers to a stream in the
			"reserved (remote)" or "half-closed (local)" state. Servers can
			discard frames where the Prioritized Stream ID refers to a stream in
			the "closed" state. Clients MUST NOT provide a Prioritized Stream ID
			that refers to a push stream in the "idle" state. Servers that
			receive a PRIORITY_UPDATE for a push stream in the "idle" state MUST
			respond with a connection error of type PROTOCOL_ERROR.
	If a PRIORITY_UPDATE frame is received with a Prioritized Stream ID		If a PRIORITY_UPDATE frame is received with a Prioritized Stream ID
	of 0x0, the recipient MUST respond with a connection error of type		of 0x0, the recipient MUST respond with a connection error of type
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	If a client receives a PRIORITY_UPDATE frame, it MUST respond with a		If a client receives a PRIORITY_UPDATE frame, it MUST respond with a
	connection error of type PROTOCOL_ERROR.		connection error of type PROTOCOL_ERROR.
	6.2. HTTP/3 PRIORITY_UPDATE Frame		6.2. HTTP/3 PRIORITY_UPDATE Frame
	skipping to change at page 11, line 37 ¶		skipping to change at page 13, line 12 ¶
	frame on a stream other than the client control stream MUST be		frame on a stream other than the client control stream MUST be
	treated as a connection error of type H3_FRAME_UNEXPECTED.		treated as a connection error of type H3_FRAME_UNEXPECTED.
	HTTP/3 PRIORITY_UPDATE Frame {		HTTP/3 PRIORITY_UPDATE Frame {
	Type (i) = 0xF0700..0xF0701,		Type (i) = 0xF0700..0xF0701,
	Length (i),		Length (i),
	Prioritized Element ID (i),		Prioritized Element ID (i),
	Priority Field Value (..),		Priority Field Value (..),
	}		}
	Figure 2: HTTP/3 PRIORITY_UPDATE Frame		Figure 2: HTTP/3 PRIORITY_UPDATE Frame
	The PRIORITY_UPDATE frame payload has the following fields:		The PRIORITY_UPDATE frame payload has the following fields:
	Prioritized Element ID: The stream ID or push ID that is the target		Prioritized Element ID: The stream ID or push ID that is the target
	of the priority update.		of the priority update.
	Priority Field Value: The priority update value in ASCII text,		Priority Field Value: The priority update value in ASCII text,
	encoded using Structured Fields.		encoded using Structured Fields.
	The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST		The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST
	skipping to change at page 14, line 35 ¶		skipping to change at page 16, line 5 ¶
	2. At the same urgency level, an incremental request of		2. At the same urgency level, an incremental request of
	indeterminate length followed by a non-incremental large		indeterminate length followed by a non-incremental large
	resource.		resource.
	It is RECOMMENDED that servers avoid such starvation where possible.		It is RECOMMENDED that servers avoid such starvation where possible.
	The method to do so is an implementation decision. For example, a		The method to do so is an implementation decision. For example, a
	server might pre-emptively send responses of a particular incremental		server might pre-emptively send responses of a particular incremental
	type based on other information such as content size.		type based on other information such as content size.
			Optimal scheduling of server push is difficult, especially when
			pushed resources contend with active concurrent requests. Servers
			can consider many factors when scheduling, such as the type or size
			of resource being pushed, the priority of the request that triggered
			the push, the count of active concurrent responses, the priority of
			other active concurrent responses, etc. There is no general guidance
			on the best way to apply these. A server that is too simple could
			easily push at too high a priority and block client requests, or push
			at too low a priority and delay the response, negating intended goals
			of server push.
			Priority signals are a factor for server push scheduling. The
			concept of parameter value defaults applies slightly differently
			because there is no explicit client-signalled initial priority. A
			server can apply priority signals provided in an origin response; see
			the merging guidance given in Section 7. In the absence of origin
			signals, applying default parameter values could be suboptimal. How
			ever a server decides to schedule a pushed response, it can signal
			the intended priority to the client by including the Priority field
			in a PUSH_PROMISE or HEADERS frame.
	10. Fairness		10. Fairness
	As a general guideline, a server SHOULD NOT use priority information		As a general guideline, a server SHOULD NOT use priority information
	for making schedule decisions across multiple connections, unless it		for making schedule decisions across multiple connections, unless it
	knows that those connections originate from the same client. Due to		knows that those connections originate from the same client. Due to
	this, priority information conveyed over a non-coalesced HTTP		this, priority information conveyed over a non-coalesced HTTP
	connection (e.g., HTTP/1.1) might go unused.		connection (e.g., HTTP/1.1) might go unused.
	The remainder of this section discusses scenarios where unfairness is		The remainder of this section discusses scenarios where unfairness is
	problematic and presents possible mitigations, or where unfairness is		problematic and presents possible mitigations, or where unfairness is
	desirable.		desirable.
	TODO: Discuss if we should add a signal that mitigates this issue.
	For example, we might add a SETTINGS parameter that indicates the
	next hop that the connection is NOT coalesced (see
	https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99).
	10.1. Coalescing Intermediaries		10.1. Coalescing Intermediaries
	When an intermediary coalesces HTTP requests coming from multiple		When an intermediary coalesces HTTP requests coming from multiple
	clients into one HTTP/2 or HTTP/3 connection going to the backend		clients into one HTTP/2 or HTTP/3 connection going to the backend
	server, requests that originate from one client might have higher		server, requests that originate from one client might have higher
	precedence than those coming from others.		precedence than those coming from others.
	It is sometimes beneficial for the server running behind an		It is sometimes beneficial for the server running behind an
	intermediary to obey to the value of the Priority header field. As		intermediary to obey to the value of the Priority header field. As
	an example, a resource-constrained server might defer the		an example, a resource-constrained server might defer the
	skipping to change at page 15, line 34 ¶		skipping to change at page 17, line 18 ¶
	intermediary is coalescing requests, then it could serve the		intermediary is coalescing requests, then it could serve the
	responses in round-robin manner. This can work if the constrained		responses in round-robin manner. This can work if the constrained
	resource is network capacity between the intermediary and the user		resource is network capacity between the intermediary and the user
	agent, as the intermediary buffers responses and forwards the chunks		agent, as the intermediary buffers responses and forwards the chunks
	based on the prioritization scheme it implements.		based on the prioritization scheme it implements.
	A server can determine if a request came from an intermediary through		A server can determine if a request came from an intermediary through
	configuration, or by consulting if that request contains one of the		configuration, or by consulting if that request contains one of the
	following header fields:		following header fields:
	o Forwarded, X-Forwarded-For ([RFC7239])		* Forwarded, X-Forwarded-For ([RFC7239])
	o Via ([RFC7230], Section 5.7.1)		* Via ([RFC7230], Section 5.7.1)
	10.2. HTTP/1.x Back Ends		10.2. HTTP/1.x Back Ends
	It is common for CDN infrastructure to support different HTTP		It is common for CDN infrastructure to support different HTTP
	versions on the front end and back end. For instance, the client-		versions on the front end and back end. For instance, the client-
	facing edge might support HTTP/2 and HTTP/3 while communication to		facing edge might support HTTP/2 and HTTP/3 while communication to
	back end servers is done using HTTP/1.1. Unlike with connection		back end servers is done using HTTP/1.1. Unlike with connection
	coalescing, the CDN will "de-mux" requests into discrete connections		coalescing, the CDN will "de-mux" requests into discrete connections
	to the back end. As HTTP/1.1 and older do not provide a way to		to the back end. As HTTP/1.1 and older do not provide a way to
	concurrently transmit multiple responses, there is no immediate		concurrently transmit multiple responses, there is no immediate
	skipping to change at page 18, line 28 ¶		skipping to change at page 20, line 11 ¶
	This specification registers the following entries in the HTTP/3		This specification registers the following entries in the HTTP/3
	Frame Type registry established by [I-D.ietf-quic-http]:		Frame Type registry established by [I-D.ietf-quic-http]:
	Frame Type: PRIORITY_UPDATE		Frame Type: PRIORITY_UPDATE
	Code: 0xF0700 and 0xF0701		Code: 0xF0700 and 0xF0701
	Specification: This document		Specification: This document
			Upon publication, please create the HTTP Priority Parameters registry
			at https://iana.org/assignments/http-priority
			(https://iana.org/assignments/http-priority) and populate it with the
			types defined in Section 3; see Section 3.3.1 for its associated
			procedures.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.ietf-quic-http]		[I-D.ietf-quic-http]
	Bishop, M., "Hypertext Transfer Protocol Version 3		Bishop, M., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", draft-ietf-quic-http-31 (work in progress),		(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
	September 2020.		quic-http-33, 15 December 2020, <http://www.ietf.org/
			internet-drafts/draft-ietf-quic-http-33.txt>.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-31 (work		and Secure Transport", Work in Progress, Internet-Draft,
	in progress), September 2020.		draft-ietf-quic-transport-33, 13 December 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-quic-
			transport-33.txt>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/info/rfc7540>.		<https://www.rfc-editor.org/info/rfc7540>.
			[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P. Kamp, "Structured Field Values for		Nottingham, M. and P. Kamp, "Structured Field Values for
	HTTP", draft-ietf-httpbis-header-structure-19 (work in		HTTP", Work in Progress, Internet-Draft, draft-ietf-
	progress), June 2020.		httpbis-header-structure-19, 3 June 2020,
			<http://www.ietf.org/internet-drafts/draft-ietf-httpbis-
			header-structure-19.txt>.
	14.2. Informative References		14.2. Informative References
	[CVE-2019-9513]		[CVE-2019-9513]
	Common Vulnerabilities and Exposures, "CVE-2019-9513",		Common Vulnerabilities and Exposures, "CVE-2019-9513", 1
	March 2019, <https://cve.mitre.org/cgi-bin/		March 2019, <https://cve.mitre.org/cgi-bin/
	cvename.cgi?name=CVE-2019-9513>.		cvename.cgi?name=CVE-2019-9513>.
	[I-D.lassey-priority-setting]		[I-D.lassey-priority-setting]
	Lassey, B. and L. Pardue, "Declaring Support for HTTP/2		Lassey, B. and L. Pardue, "Declaring Support for HTTP/2
	Priorities", draft-lassey-priority-setting-00 (work in		Priorities", Work in Progress, Internet-Draft, draft-
	progress), July 2019.		lassey-priority-setting-00, 25 July 2019,
			<http://www.ietf.org/internet-drafts/draft-lassey-
			priority-setting-00.txt>.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	DOI 10.17487/RFC3864, September 2004,		DOI 10.17487/RFC3864, September 2004,
	<https://www.rfc-editor.org/info/rfc3864>.		<https://www.rfc-editor.org/info/rfc3864>.
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<https://www.rfc-editor.org/info/rfc7234>.		<https://www.rfc-editor.org/info/rfc7234>.
	[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",		[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
	RFC 7239, DOI 10.17487/RFC7239, June 2014,		RFC 7239, DOI 10.17487/RFC7239, June 2014,
	<https://www.rfc-editor.org/info/rfc7239>.		<https://www.rfc-editor.org/info/rfc7239>.
	[RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081,		[RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081,
	DOI 10.17487/RFC8081, February 2017,		DOI 10.17487/RFC8081, February 2017,
	<https://www.rfc-editor.org/info/rfc8081>.		<https://www.rfc-editor.org/info/rfc8081>.
	14.3. URIs
	[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
	[2] https://httpwg.org/
	[3] https://github.com/httpwg/http-extensions/labels/priorities
	[4] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf
	[5] https://github.com/pmeenan/http3-prioritization-proposal
	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 [4]. In https://github.com/pmeenan/http3-		slides-83-httpbis-5.pdf (http://tools.ietf.org/agenda/83/slides/
	prioritization-proposal [5], Patrick Meenan advocates for		slides-83-httpbis-5.pdf). In https://github.com/pmeenan/http3-
	representing the priorities using a tuple of urgency and concurrency.		prioritization-proposal (https://github.com/pmeenan/http3-
	The ability to deprecate HTTP/2 prioritization is based on		prioritization-proposal), Patrick Meenan advocates for representing
			the priorities using a tuple of urgency and concurrency. The ability
			to deprecate HTTP/2 prioritization is based on
	[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-01		B.1. Since draft-ietf-httpbis-priority-01
	o PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,		* Describe considerations for server push prioritisation (#1056,
			#1345)
			* Define HTTP/2 PRIORITY_UPDATE ID limits in HTTP/2 terms (#1261,
			#1344)
			* Add a Parameters registry (#1371)
			B.2. Since draft-ietf-httpbis-priority-01
			* PRIORITY_UPDATE frame changes (#1096, #1079, #1167, #1262, #1267,
	#1271)		#1271)
	o Add section to describe server scheduling considerations (#1215,		* Add section to describe server scheduling considerations (#1215,
	#1232, #1266)		#1232, #1266)
	o Remove specific instructions related to intermediary fairness		* Remove specific instructions related to intermediary fairness
	(#1022, #1264)		(#1022, #1264)
	B.2. Since draft-ietf-httpbis-priority-00		B.3. Since draft-ietf-httpbis-priority-00
	o Move text around (#1217, #1218)		* Move text around (#1217, #1218)
	o 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.3. Since draft-kazuho-httpbis-priority-04		B.4. Since draft-kazuho-httpbis-priority-04
			* Minimize semantics of Urgency levels (#1023, #1026)
	o Minimize semantics of Urgency levels (#1023, #1026)
	o Reduce guidance about how intermediary implements merging priority		* Reduce guidance about how intermediary implements merging priority
	signals (#1026)		signals (#1026)
	o Remove mention of CDN-Loop (#1062)		* Remove mention of CDN-Loop (#1062)
	o Editorial changes		* Editorial changes
	o Make changes due to WG adoption		* Make changes due to WG adoption
	o Removed outdated Consideration (#118)		* Removed outdated Consideration (#118)
	B.4. Since draft-kazuho-httpbis-priority-03		B.5. Since draft-kazuho-httpbis-priority-03
	o Changed numbering from "[-1,6]" to "[0,7]" (#78)		* Changed numbering from "[-1,6]" to "[0,7]" (#78)
	o Replaced priority scheme negotiation with HTTP/2 priority		* Replaced priority scheme negotiation with HTTP/2 priority
	deprecation (#100)		deprecation (#100)
	o Shorten parameter names (#108)		* Shorten parameter names (#108)
	o Expand on considerations (#105, #107, #109, #110, #111, #113)		* Expand on considerations (#105, #107, #109, #110, #111, #113)
	B.5. Since draft-kazuho-httpbis-priority-02		B.6. Since draft-kazuho-httpbis-priority-02
	o Consolidation of the problem statement (#61, #73)		* Consolidation of the problem statement (#61, #73)
	o Define SETTINGS_PRIORITIES for negotiation (#58, #69)		* Define SETTINGS_PRIORITIES for negotiation (#58, #69)
	o Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)		* Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)
	o Explain fairness issue and mitigations (#56)		* Explain fairness issue and mitigations (#56)
	B.6. Since draft-kazuho-httpbis-priority-01		B.7. Since draft-kazuho-httpbis-priority-01
	o Explain how reprioritization might be supported.		* Explain how reprioritization might be supported.
	B.7. Since draft-kazuho-httpbis-priority-00		B.8. Since draft-kazuho-httpbis-priority-00
	o 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. 57 change blocks.
	135 lines changed or deleted		224 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/