draft-kazuho-httpbis-priority-00.txt		draft-kazuho-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: January 9, 2020 Cloudflare		Expires: January 22, 2020 Cloudflare
	July 08, 2019		July 21, 2019
	The Priority HTTP Header Field		The Priority HTTP Header Field
	draft-kazuho-httpbis-priority-00		draft-kazuho-httpbis-priority-01
	Abstract		Abstract
	This document describes the Priority HTTP header field. This header		This document describes the Priority HTTP header field. This header
	field can be used by endpoints to specify the absolute precedence of		field can be used by endpoints to specify the absolute precedence of
	an HTTP response in an HTTP-version-independent way.		an HTTP response in an HTTP-version-independent way.
	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 http://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 January 9, 2020.		This Internet-Draft will expire on January 22, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. The Priority HTTP Header Field . . . . . . . . . . . . . . . 3		2. The Priority HTTP Header Field . . . . . . . . . . . . . . . 4
	2.1. urgency . . . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. urgency . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. progressive . . . . . . . . . . . . . . . . . . . . . . . 4		2.1.1. prerequisite . . . . . . . . . . . . . . . . . . . . 5
	3. Merging Client- and Server-Driven Parameters . . . . . . . . 5		2.1.2. default . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Coexistence with HTTP/2 Priorities . . . . . . . . . . . . . 6		2.1.3. supplementary . . . . . . . . . . . . . . . . . . . . 5
	4.1. The SETTINGS_HEADER_BASED_PRIORITY SETTINGS Parameter . . 6		2.1.4. background . . . . . . . . . . . . . . . . . . . . . 6
	5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. progressive . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Why use an End-to-End Header Field? . . . . . . . . . . . 6		3. Merging Client- and Server-Driven Parameters . . . . . . . . 7
	5.2. Why are there Only Three Levels of Urgency? . . . . . . . 7		4. Coexistence with HTTP/2 Priorities . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4.1. The SETTINGS_HEADER_BASED_PRIORITY SETTINGS Parameter . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.1. Why use an End-to-End Header Field? . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		5.2. Why do Urgencies Have Meanings? . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
			8.1. Normative References . . . . . . . . . . . . . . . . . . 10
			8.2. Informative References . . . . . . . . . . . . . . . . . 10
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
			Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11
			B.1. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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 4, line 17 ¶		skipping to change at page 4, line 26 ¶
	member represents a parameter of the Priority header field. This		member represents a parameter of the Priority header field. This
	document defines the "urgency" and "progressive" parameters. Values		document defines the "urgency" and "progressive" parameters. Values
	of these parameters MUST always be present. When any of the defined		of these parameters MUST always be present. When any of the defined
	parameters are omitted, or if the Priority header field is not used,		parameters are omitted, or if the Priority header field is not used,
	their default values SHOULD be applied.		their default values SHOULD be applied.
	Unknown parameters MUST be ignored.		Unknown parameters MUST be ignored.
	2.1. urgency		2.1. urgency
	The "urgency" parameter takes one of the following sh-tokens as the		The "urgency" parameter takes an integer between -1 and 6 as shown
	value that indicates how an HTTP response affects the usage of other		below:
	responses:
	o "blocking" indicates that the response prevents other responses
	from being used.
	o "document" indicates that the response contains the document that		+-----------------+-------------------------------+
	is being processed.		| Urgency | Definition |
			+-----------------+-------------------------------+
			| -1 | prerequisite (Section 2.1.1) |
			| 0 | default (Section 2.1.2) |
			| between 1 and 5 | supplementary (Section 2.1.3) |
			| 6 | background (Section 2.1.4) |
			+-----------------+-------------------------------+
	o "non-blocking" indicates that the response does not prevent the		Table 1: Urgencies
	client from using the document even though the response is being
	used or referred to by the document.
	The default value is "document".		The value is encoded as an sh-integer. The default value is zero.
	A server SHOULD transmit HTTP responses in the order of their		A server SHOULD transmit HTTP responses in the order of their urgency
	urgency: "blocking" first, followed by "document", followed by "non-		values. The lower the value, the higher the precedence.
	blocking".
	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 "blocking":		set to "-1":
	:method = GET		:method = GET
	:scheme = https		:scheme = https
	:authority = example.net		:authority = example.net
	:path = /style.css		:path = /style.css
	priority = urgency=blocking		priority = urgency=-1
			The definition of the urgencies and their expected use-case are
			described below. Endpoints SHOULD respect the definition of the
			values when assigning urgencies.
			2.1.1. prerequisite
			The prerequisite urgency (value -1) indicates that the response
			prevents other responses with an urgency of prerequisite or default
			from being used.
			For example, use of an external stylesheet can block a web browser
			from rendering the HTML. In such case, the stylesheet is given the
			prerequisite urgency.
			2.1.2. default
			The default urgency (value 0) indicates a response that is to be used
			as it is delivered to the client, but one that does not block other
			responses from being used.
			For example, when a user using a web browser navigates to a new HTML
			document, the request for that HTML is given the default urgency.
			When that HTML document uses a custom font, the request for that
			custom font SHOULD also be given the default urgency. This is
			because the availability of the custom font is likely a precondition
			for the user to use that portion of the HTML document, which is to be
			rendered by that font.
			2.1.3. supplementary
			The supplementary urgency indicates a response that is helpful to the
			client using a composition of responses, even though the response
			itself is not mandatory for using those responses.
			For example, inline images (i.e., images being fetched and displayed
			as part of the document) are visually important elements of an HTML
			document. As such, users will typically not be prevented from using
			the document, at least to some degree, before any or all of these
			images are loaded. Display of those images are thus considered to be
			an improvement for visual clients rather than a prerequisite for all
			user agents. Therefore, such images will be given the supplementary
			urgency.
			Values between 1 and 5 are used to represent this urgency, to provide
			flexibility to the endpoints for giving some responses more or less
			precedence than others that belong to the supplementary group.
			Section 3 explains how these values might be used.
			Clients SHOULD NOT use values 1 and 5. Servers MAY use these values
			to prioritize a response above or below other supplementary
			responses.
			Clients MAY use values 2 to indicate that a request is given
			relatively high priority, or 4 to indicate relatively low priority,
			within the supplementary urgency group.
			For example, an image certain to be visible at the top of the page,
			might be assigned a value of 2 instead of 3, as it will have a high
			visual impact for the user. Conversely, an asynchronously loaded
			JavaScript file might be assigned an urgency value of 4, as it is
			less likely to have a visual impact.
			When none of the considerations above is applicable, the value of 3
			SHOULD be used.
			2.1.4. background
			The background urgency (value 6) is used for responses of which the
			delivery can be postponed without having an impact on using other
			responses.
			As an example, the download of a large file in a web browser would be
			assigned the background urgency so it would not impact further page
			loads on the same connection.
	2.2. progressive		2.2. progressive
	The "progressive" parameter takes an sh-boolean as the value that		The "progressive" parameter takes an sh-boolean as the value that
	indicates if a response can be processed progressively, i.e. provide		indicates if a response can be processed progressively, i.e. provide
	some meaningful output as chunks of the response arrive.		some meaningful output as chunks of the response arrive.
	The default value of the "progressive" parameter is "0".		The default value of the "progressive" parameter is "0".
	A server SHOULD distribute the bandwidth of a connection between		A server SHOULD distribute the bandwidth of a connection between
	progressive responses that share the same urgency.		progressive responses that share the same urgency.
	A server SHOULD transmit non-progressive responses one by one,		A server SHOULD transmit non-progressive responses one by one,
	preferably in the order the requests were generated. Doing so		preferably in the order the requests were generated. Doing so
	maximizes the chance of the client making progress in using the		maximizes the chance of the client making progress in using the
	composition of the HTTP responses at the earliest moment.		composition of the HTTP responses at the earliest moment.
	The following example shows a request for a JPEG file with the		The following example shows a request for a JPEG file with the
	urgency parameter set to "non-blocking" and the progressive parameter		urgency parameter set to "3" and the progressive parameter set to
	set to "1".		"1".
	:method = GET		:method = GET
	:scheme = https		:scheme = https
	:authority = example.net		:authority = example.net
	:path = /image.jpg		:path = /image.jpg
	priority = urgency=non-blocking, progressive=?1		priority = urgency=3, progressive=?1
	3. Merging Client- and Server-Driven Parameters		3. Merging Client- and Server-Driven Parameters
	It is not always the case that the client has the best view of how		It is not always the case that the client has the best understanding
	the HTTP responses should be prioritized. For example, whether a		of how the HTTP responses deserve to be prioritized. For example,
	JPEG image should be served progressively by the server depends on		use of an HTML document might depend heavily on one of the inline
	the structure of that image file - a property only known to the		images. Existence of such dependencies is typically best known to
	server.		the server.
	Therefore, a server is permitted to send a "Priority" response header		By using the "Priority" response header, a server can override the
	field. When used, the parameters found in this response header field		prioritization hints provided by the client. When used, the
	override those specified by the client.		parameters found in the response header field overrides those
			specified by the client.
	For example, when the client sends an HTTP request with		For example, when the client sends an HTTP request with
	:method = GET		:method = GET
	:scheme = https		:scheme = https
	:authority = example.net		:authority = example.net
	:path = /image.jpg		:path = /menu.png
	priority = urgency=non-blocking, progressive=?1		priority = urgency=3, progressive=?1
	and the origin responds with		and the origin responds with
	:status = 200		:status = 200
	content-type = image/jpeg		content-type = image/png
	priority = progressive=?0		priority = urgency=1
	the intermediary's view of the progressiveness of the response		the intermediary's understanding of the urgency is promoted from "3"
	becomes negative, because the server-provided value overrides that		to "1", because the server-provided value overrides the value
	provided by the client. The urgency is deemed as "non-blocking",		provided by the client. The progressiveness continues to be "1", the
	because the server did not specify the parameter.		value specified by the client, as the server did not specify the
			"progressive" parameter.
	4. Coexistence with HTTP/2 Priorities		4. Coexistence with HTTP/2 Priorities
	Standard HTTP/2 ([RFC7540]) endpoints use frame-based prioritization,		Standard HTTP/2 ([RFC7540]) endpoints use frame-based prioritization,
	whereby a client sends priority information in dedicated fields		whereby a client sends priority information in dedicated fields
	present in HEADERS and PRIORITY frames. A client might instead		present in HEADERS and PRIORITY frames. A client might instead
	choose to use header-based prioritization as specified in this		choose to use header-based prioritization as specified in this
	document.		document.
	4.1. The SETTINGS_HEADER_BASED_PRIORITY SETTINGS Parameter		4.1. The SETTINGS_HEADER_BASED_PRIORITY SETTINGS Parameter
	skipping to change at page 7, line 19 ¶		skipping to change at page 9, line 11 ¶
	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.
	5.2. Why are there Only Three Levels of Urgency?		5.2. Why do Urgencies Have Meanings?
	One of the aims of this specification is to define a mechanism for		One of the aims of this specification is to define a mechanism for
	merging client- and server-provided hints for prioritizing the		merging client- and server-provided hints for prioritizing the
	responses. For that to work, each urgency level needs to have a		responses. For that to work, each urgency level needs to have a
	well-defined meaning. As an example, a server can assign the highest		well-defined meaning. As an example, a server can assign the highest
	precedence among the non-blocking responses to an HTTP response		precedence among the supplementary responses to an HTTP response
	carrying an icon, because the meaning of "non-blocking" is shared		carrying an icon, because the meaning of "urgency=1" is shared among
	among the endpoints.		the endpoints.
	This specification restricts itself to defining just three levels of		This specification restricts itself to defining a minimum set of
	urgency, in order to provide sufficient granularity for prioritizing		urgency levels in order to provide sufficient granularity for
	responses for ordinary web browsing, at minimal complexity.		prioritizing responses for ordinary web browsing, at minimal
			complexity.
	However, that does not mean that the prioritization scheme would		However, that does not mean that the prioritization scheme would
	forever be stuck to the three levels. The design provides		forever be stuck to the eight levels. The design provides
	extensibility. If deemed necessary, it would be possible to divide		extensibility. If deemed necessary, it would be possible to
	any of the three urgency levels into sub-levels by defining a new		subdivide any of the eight urgency levels that are currently defined.
	parameter. As an example, a server could assign an "importance"		Or, a graphical user-agent could send a "visible" parameter to
	parameter to the priority of each image that it provides, so that an		indicate if the resource being requested is within the viewport.
	intermediary could prioritize certain images above others. Or, a
	graphical user-agent could send a "visible" parameter to indicate if
	the resource being requested is within the viewport.
	A server can combine the hints provided in the Priority header field		A server can combine the hints provided in the Priority header field
	with other information in order to improve the prioritization of		with other information in order to improve the prioritization of
	responses. For example, a server that receives requests for a font		responses. For example, a server that receives requests for a font
	[RFC8081] and images with the same urgency might give higher		[RFC8081] and images with the same urgency might give higher
	precedence to the font, so that a visual client can render textual		precedence to the font, so that a visual client can render textual
	information at an early moment.		information at an early moment.
	6. Security Considerations		6. Security Considerations
	skipping to change at page 8, line 43 ¶		skipping to change at page 10, line 29 ¶
	Initial value: 0		Initial value: 0
	Specification: This document		Specification: This document
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-httpbis-header-structure]		[I-D.ietf-httpbis-header-structure]
	Nottingham, M. and P. Kamp, "Structured Headers for HTTP",		Nottingham, M. and P. Kamp, "Structured Headers for HTTP",
	draft-ietf-httpbis-header-structure-10 (work in progress),		draft-ietf-httpbis-header-structure-11 (work in progress),
	April 2019.		July 2019.
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	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, <https://www.rfc-		DOI 10.17487/RFC7540, May 2015,
	editor.org/info/rfc7540>.		<https://www.rfc-editor.org/info/rfc7540>.
	8.2. Informative References		8.2. Informative 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-20 (work in progress),		(HTTP/3)", draft-ietf-quic-http-22 (work in progress),
	April 2019.		July 2019.
	[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, <https://www.rfc-		DOI 10.17487/RFC3864, September 2004,
	editor.org/info/rfc3864>.		<https://www.rfc-editor.org/info/rfc3864>.
	[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, <https://www.rfc-		DOI 10.17487/RFC8081, February 2017,
	editor.org/info/rfc8081>.		<https://www.rfc-editor.org/info/rfc8081>.
			8.3. URIs
			[1] http://tools.ietf.org/agenda/83/slides/slides-83-httpbis-5.pdf
			[2] https://github.com/pmeenan/http3-prioritization-proposal
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
			Roy Fielding presented the idea of using a header field for
			representing priorities in http://tools.ietf.org/agenda/83/slides/
			slides-83-httpbis-5.pdf [1]. In https://github.com/pmeenan/http3-
			prioritization-proposal [2], Patrick Meenan advocates for
			representing the priorities using a tuple of urgency and concurrency.
	Many thanks to Robin Marx, Patrick Meenan and Ian Swett for their		Many thanks to Robin Marx, Patrick Meenan and Ian Swett for their
	feedback.		feedback.
			Appendix B. Change Log
			B.1. Since draft-kazuho-httpbis-priority-00
			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
	Lucas Pardue		Lucas Pardue
	Cloudflare		Cloudflare
	Email: lucaspardue.24.7@gmail.com		Email: lucaspardue.24.7@gmail.com
End of changes. 34 change blocks.
	85 lines changed or deleted		181 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/