draft-ietf-httpbis-priority-00.txt		draft-ietf-httpbis-priority-01.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: September 6, 2020 Cloudflare		Expires: January 14, 2021 Cloudflare
	March 05, 2020		July 13, 2020
	Extensible Prioritization Scheme for HTTP		Extensible Prioritization Scheme for HTTP
	draft-ietf-httpbis-priority-00		draft-ietf-httpbis-priority-01
	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 7 ¶		skipping to change at page 2, line 7 ¶
	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 September 6, 2020.		This Internet-Draft will expire on January 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Urgency . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Incremental . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8		3.3. Defining New Parameters . . . . . . . . . . . . . . . . . 8
	4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 8		4. The Priority HTTP Header Field . . . . . . . . . . . . . . . 8
	5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 8		5. Reprioritization . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 9		5.1. HTTP/2 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 9
	5.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 10		5.2. HTTP/3 PRIORITY_UPDATE Frame . . . . . . . . . . . . . . 10
	6. Merging Client- and Server-Driven Parameters . . . . . . . . 11		6. Merging Client- and Server-Driven Parameters . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Client Scheduling . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Fairness . . . . . . . . . . . . . . . . . . . . . . . . 12		8. Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1.1. Coalescing Intermediaries . . . . . . . . . . . . . . 12		8.1. Coalescing Intermediaries . . . . . . . . . . . . . . . . 13
	7.1.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . 13		8.2. HTTP/1.x Back Ends . . . . . . . . . . . . . . . . . . . 13
	7.1.3. Intentional Introduction of Unfairness . . . . . . . 14		8.3. Intentional Introduction of Unfairness . . . . . . . . . 14
	8. Considerations . . . . . . . . . . . . . . . . . . . . . . . 14		9. Why use an End-to-End Header Field? . . . . . . . . . . . . . 14
	8.1. Why use an End-to-End Header Field? . . . . . . . . . . . 14		10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 15		12.1. Normative References . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . 16		12.2. Informative References . . . . . . . . . . . . . . . . . 17
	10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
	B.1. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 18		B.1. Since draft-ietf-httpbis-priority-00 . . . . . . . . . . 18
	B.2. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 18		B.2. Since draft-kazuho-httpbis-priority-04 . . . . . . . . . 19
	B.3. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 18		B.3. Since draft-kazuho-httpbis-priority-03 . . . . . . . . . 19
	B.4. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 18		B.4. Since draft-kazuho-httpbis-priority-02 . . . . . . . . . 19
	B.5. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 18		B.5. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		B.6. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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 5, line 30 ¶		skipping to change at page 5, line 30 ¶
	2.1. Disabling HTTP/2 Priorities		2.1. Disabling HTTP/2 Priorities
	The problems and insights set out above are motivation for allowing		The problems and insights set out above are motivation for allowing
	endpoints to opt out of using the HTTP/2 priority scheme, in favor of		endpoints to opt out of using the HTTP/2 priority scheme, in favor of
	using an alternative such as the scheme defined in this		using an alternative such as the scheme defined in this
	specification. The SETTINGS_DEPRECATE_HTTP2_PRIORITIES setting		specification. The SETTINGS_DEPRECATE_HTTP2_PRIORITIES setting
	described below enables endpoints to understand their peer's		described below enables endpoints to understand their peer's
	intention. The value of the parameter MUST be 0 or 1. Any value		intention. The value of the parameter MUST be 0 or 1. Any value
	other than 0 or 1 MUST be treated as a connection error (see		other than 0 or 1 MUST be treated as a connection error (see
	[RFC7540]; Section 5.4.1) of type PROTOCOL_ERROR.		[RFC7540], Section 5.4.1) 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. When the peer receives the first SETTINGS frame, it		SETTINGS frame. When the peer receives the first SETTINGS frame, it
	learns the sender has deprecated the HTTP/2 priority scheme if it		learns the sender has deprecated the HTTP/2 priority scheme if it
	receives the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with the		receives the SETTINGS_DEPRECATE_HTTP2_PRIORITIES parameter with the
	value of 1.		value of 1.
	A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES		A sender MUST NOT change the SETTINGS_DEPRECATE_HTTP2_PRIORITIES
	parameter value after the first SETTINGS frame. Detection of a		parameter value after the first SETTINGS frame. Detection of a
	change by a receiver MUST be treated as a connection error of type		change by a receiver MUST be treated as a connection error of type
	skipping to change at page 6, line 45 ¶		skipping to change at page 6, line 45 ¶
	Unknown parameters, parameters with out-of-range values or values of		Unknown parameters, parameters with out-of-range values or values of
	unexpected types MUST be ignored.		unexpected types MUST be ignored.
	3.1. Urgency		3.1. Urgency
	The urgency parameter ("u") takes an integer between 0 and 7, in		The urgency parameter ("u") takes an integer between 0 and 7, in
	descending order of priority. This range provides sufficient		descending order of priority. This range provides sufficient
	granularity for prioritizing responses for ordinary web browsing, at		granularity for prioritizing responses for ordinary web browsing, at
	minimal complexity.		minimal complexity.
	The value is encoded as an sh-integer. The default value is 1.		The value is encoded as an sh-integer. The default value is 3.
	This parameter indicates the sender's recommendation, based on the		This parameter indicates the sender's recommendation, based on the
	expectation that the server would transmit HTTP responses in the		expectation that the server would transmit HTTP responses in the
	order of their urgency values if possible. The smaller the value,		order of their urgency values if possible. The smaller the value,
	the higher the precedence.		the higher the precedence.
	The following example shows a request for a CSS file with the urgency		The following example shows a request for a CSS file with the urgency
	set to "0":		set to "0":
	:method = GET		:method = GET
	skipping to change at page 12, line 27 ¶		skipping to change at page 12, line 27 ¶
	:status = 200		:status = 200
	content-type = image/png		content-type = image/png
	priority = u=1		priority = u=1
	the intermediary might alter its understanding of the urgency from		the intermediary might alter its understanding of the urgency from
	"5" to "1", because it prefers the server-provided value over the		"5" to "1", because it prefers the server-provided value over the
	client's. The incremental value continues to be "true", the value		client's. The incremental value continues to be "true", the value
	specified by the client, as the server did not specify the		specified by the client, as the server did not specify the
	incremental("i") parameter.		incremental("i") parameter.
	7. Security Considerations		7. Client Scheduling
	7.1. Fairness		A client MAY use priority values to make local scheduling choices
			about the requests it initiates.
			8. 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.		TODO: Discuss if we should add a signal that mitigates this issue.
	For example, we might add a SETTINGS parameter that indicates the		For example, we might add a SETTINGS parameter that indicates the
	next hop that the connection is NOT coalesced (see		next hop that the connection is NOT coalesced (see
	https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99).		https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/99).
	7.1.1. Coalescing Intermediaries		8.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
	transmission of software update files that would have the background		transmission of software update files that would have the background
	skipping to change at page 13, line 39 ¶		skipping to change at page 13, line 46 ¶
	Responding to requests coming through an intermediary in a round-		Responding to requests coming through an intermediary in a round-
	robin manner works well when the network bottleneck exists between		robin manner works well when the network bottleneck exists between
	the intermediary and the end client, as the intermediary would be		the intermediary and the end client, as the intermediary would be
	buffering the responses and then be forwarding the chunks of those		buffering the responses and then be forwarding the chunks of those
	buffered responses based on the prioritization scheme it implements.		buffered responses based on the prioritization scheme it implements.
	A sophisticated server MAY use a weighted round-robin reflecting the		A sophisticated server MAY use a weighted round-robin reflecting the
	urgencies expressed in the requests, so that less urgent responses		urgencies expressed in the requests, so that less urgent responses
	would receive less bandwidth in case the bottleneck exists between		would receive less bandwidth in case the bottleneck exists between
	the server and the intermediary.		the server and the intermediary.
	7.1.2. HTTP/1.x Back Ends		8.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
	fairness issue in protocol. However, back end servers MAY still use		fairness issue in protocol. However, back end servers MAY still use
	client headers for request scheduling. Back end servers SHOULD only		client headers for request scheduling. Back end servers SHOULD only
	schedule based on client priority information where that information		schedule based on client priority information where that information
	can be scoped to individual end clients. Authentication and other		can be scoped to individual end clients. Authentication and other
	session information might provide this linkability.		session information might provide this linkability.
	7.1.3. Intentional Introduction of Unfairness		8.3. Intentional Introduction of Unfairness
	It is sometimes beneficial to deprioritize the transmission of one		It is sometimes beneficial to deprioritize the transmission of one
	connection over others, knowing that doing so introduces a certain		connection over others, knowing that doing so introduces a certain
	amount of unfairness between the connections and therefore between		amount of unfairness between the connections and therefore between
	the requests served on those connections.		the requests served on those connections.
	For example, a server might use a scavenging congestion controller on		For example, a server might use a scavenging congestion controller on
	connections that only convey background priority responses such as		connections that only convey background priority responses such as
	software update images. Doing so improves responsiveness of other		software update images. Doing so improves responsiveness of other
	connections at the cost of delaying the delivery of updates.		connections at the cost of delaying the delivery of updates.
	Also, a client MAY use the priority values for making local		9. Why use an End-to-End Header Field?
	scheduling choices for the requests it initiates.
	8. Considerations
	8.1. Why use an End-to-End Header Field?
	Contrary to the prioritization scheme of HTTP/2 that uses a hop-by-		Contrary to the prioritization scheme of HTTP/2 that uses a hop-by-
	hop frame, the Priority header field is defined as end-to-end.		hop frame, the Priority header field is defined as end-to-end.
	The rationale is that the Priority header field transmits how each		The rationale is that the Priority header field transmits how each
	response affects the client's processing of those responses, rather		response affects the client's processing of those responses, rather
	than how relatively urgent each response is to others. The way a		than how relatively urgent each response is to others. The way a
	client processes a response is a property associated to that client		client processes a response is a property associated to that client
	generating that request. Not that of an intermediary. Therefore, it		generating that request. Not that of an intermediary. Therefore, it
	is an end-to-end property. How these end-to-end properties carried		is an end-to-end property. How these end-to-end properties carried
	skipping to change at page 14, line 47 ¶		skipping to change at page 15, line 5 ¶
	for caching intermediaries. Such intermediaries can cache the value		for caching intermediaries. Such intermediaries can cache the value
	of the Priority header field along with the response, and utilize the		of the Priority header field along with the response, and utilize the
	value of the cached header field when serving the cached response,		value of the cached header field when serving the cached response,
	only because the header field is defined as end-to-end rather than		only because the header field is defined as end-to-end rather than
	hop-by-hop.		hop-by-hop.
	It should also be noted that the use of a header field carrying a		It should also be noted that the use of a header field carrying a
	textual value makes the prioritization scheme extensible; see the		textual value makes the prioritization scheme extensible; see the
	discussion below.		discussion below.
	9. IANA Considerations		10. Security Considerations
			[CVE-2019-9513] aka "Resource Loop", is a DoS attack based on
			manipulation of the HTTP/2 priority tree. Extensible priorities does
			not use stream dependencies, which mitigates this vulnerability.
			TBD: depending on the outcome of reprioritization discussions,
			following paragraphs may change or be removed.
			[RFC7540], Section 5.3.4 describes a scenario where closure of
			streams in the priority tree could cause suboptimal prioritization.
			To avoid this, [RFC7540] states that "an endpoint SHOULD retain
			stream prioritization state for a period after streams become
			closed". Retaining state for streams no longer counted towards
			stream concurrency consumes server resources. Furthermore, [RFC7540]
			identifies that reprioritization of a closed stream could affect
			dependents; it recommends updating the priority tree if sufficient
			state is stored, which will also consume server resources. To limit
			this commitment, it is stated that "The amount of prioritization
			state that is retained MAY be limited" and "If a limit is applied,
			endpoints SHOULD maintain state for at least as many streams as
			allowed by their setting for SETTINGS_MAX_CONCURRENT_STREAMS.".
			Extensible priorities does not use stream dependencies, which
			minimizes most of the resource concerns related to this scenario.
			[RFC7540], Section 5.3.4 also presents considerations about the state
			required to store priority information about streams in an "idle"
			state. This state can be limited by adopting the guidance about
			concurrency limits described above. Extensible priorities is subject
			to a similar consideration because PRIORITY_UPDATE frames may arrive
			before the request that they reference. A server is required to
			store the information in order to apply the most up-to-date signal to
			the request. However, HTTP/3 implementations might have practical
			barriers to determining reasonable stream concurrency limits
			depending on the information that is available to them from the QUIC
			transport layer. TODO: so what can we suggest?
			11. IANA Considerations
	This specification registers the following entry in the Permanent		This specification registers the following entry in the Permanent
	Message Header Field Names registry established by [RFC3864]:		Message Header Field Names registry established by [RFC3864]:
	Header field name: Priority		Header field name: Priority
	Applicable protocol: http		Applicable protocol: http
	Status: standard		Status: standard
	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 [RFC7540]:		Settings registry established by [RFC7540]:
	Name: SETTINGS_DEPRECATE_HTTP2_PRIORITIES		Name: SETTINGS_DEPRECATE_HTTP2_PRIORITIES
	skipping to change at page 15, line 43 ¶		skipping to change at page 16, line 39 ¶
	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: 0xF		Code: 0xF
	Specification: This document		Specification: This document
	10. References		12. References
	10.1. Normative References		12.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-27 (work in progress),		(HTTP/3)", draft-ietf-quic-http-29 (work in progress),
	February 2020.		June 2020.
	[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-27 (work		and Secure Transport", draft-ietf-quic-transport-29 (work
	in progress), February 2020.		in progress), June 2020.
	[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>.
	[STRUCTURED-HEADERS]		[STRUCTURED-HEADERS]
	Nottingham, M. and P. Kamp, "Structured Headers for HTTP",		Nottingham, M. and P. Kamp, "Structured Field Values for
	draft-ietf-httpbis-header-structure-15 (work in progress),		HTTP", draft-ietf-httpbis-header-structure-19 (work in
	January 2020.		progress), June 2020.
	10.2. Informative References		12.2. Informative References
	[CVE-2019-9513]		[CVE-2019-9513]
	Common Vulnerabilities and Exposures, "CVE-2019-9513",		Common Vulnerabilities and Exposures, "CVE-2019-9513",
	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", draft-lassey-priority-setting-00 (work in
	progress), July 2019.		progress), July 2019.
	skipping to change at page 17, line 13 ¶		skipping to change at page 18, line 9 ¶
	<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>.
	10.3. URIs		12.3. URIs
	[1] https://lists.w3.org/Archives/Public/ietf-http-wg/		[1] https://lists.w3.org/Archives/Public/ietf-http-wg/
	[2] https://httpwg.org/		[2] https://httpwg.org/
	[3] https://github.com/httpwg/http-extensions/labels/priorities		[3] https://github.com/httpwg/http-extensions/labels/priorities
	[4] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf		[4] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf
	[5] https://github.com/pmeenan/http3-prioritization-proposal		[5] https://github.com/pmeenan/http3-prioritization-proposal
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 45 ¶
	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-kazuho-httpbis-priority-04
			B.1. Since draft-ietf-httpbis-priority-00
			o Move text around (#1217, #1218)
			o Editorial change to the default urgency. The value is 3, which
			was always the intent of previous changes.
			B.2. Since draft-kazuho-httpbis-priority-04
	o Minimize semantics of Urgency levels (#1023, #1026)		o Minimize semantics of Urgency levels (#1023, #1026)
	o Reduce guidance about how intermediary implements merging priority		o Reduce guidance about how intermediary implements merging priority
	signals (#1026)		signals (#1026)
	o Remove mention of CDN-Loop (#1062)		o Remove mention of CDN-Loop (#1062)
	o Editorial changes		o Editorial changes
	o Make changes due to WG adoption		o Make changes due to WG adoption
	o Removed outdated Consideration (#118)		o Removed outdated Consideration (#118)
	B.2. Since draft-kazuho-httpbis-priority-03		B.3. Since draft-kazuho-httpbis-priority-03
	o Changed numbering from "[-1,6]" to "[0,7]" (#78)		o Changed numbering from "[-1,6]" to "[0,7]" (#78)
	o Replaced priority scheme negotiation with HTTP/2 priority		o Replaced priority scheme negotiation with HTTP/2 priority
	deprecation (#100)		deprecation (#100)
	o Shorten parameter names (#108)		o Shorten parameter names (#108)
	o Expand on considerations (#105, #107, #109, #110, #111, #113)		o Expand on considerations (#105, #107, #109, #110, #111, #113)
	B.3. Since draft-kazuho-httpbis-priority-02		B.4. Since draft-kazuho-httpbis-priority-02
	o Consolidation of the problem statement (#61, #73)		o Consolidation of the problem statement (#61, #73)
	o Define SETTINGS_PRIORITIES for negotiation (#58, #69)		o Define SETTINGS_PRIORITIES for negotiation (#58, #69)
	o Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)		o Define PRIORITY_UPDATE frame for HTTP/2 and HTTP/3 (#51)
	o Explain fairness issue and mitigations (#56)		o Explain fairness issue and mitigations (#56)
	B.4. Since draft-kazuho-httpbis-priority-01		B.5. Since draft-kazuho-httpbis-priority-01
	o Explain how reprioritization might be supported.		o Explain how reprioritization might be supported.
	B.5. Since draft-kazuho-httpbis-priority-00		B.6. Since draft-kazuho-httpbis-priority-00
	o Expand urgency levels from 3 to 8.		o 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. 27 change blocks.
	55 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/