draft-kazuho-httpbis-priority-01.txt		draft-kazuho-httpbis-priority-02.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 22, 2020 Cloudflare		Expires: January 24, 2020 Cloudflare
	July 21, 2019		July 23, 2019
	The Priority HTTP Header Field		The Priority HTTP Header Field
	draft-kazuho-httpbis-priority-01		draft-kazuho-httpbis-priority-02
	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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 January 22, 2020.		This Internet-Draft will expire on January 24, 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
	(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 22 ¶		skipping to change at page 2, line 22 ¶
	2.1.2. default . . . . . . . . . . . . . . . . . . . . . . . 5		2.1.2. default . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.3. supplementary . . . . . . . . . . . . . . . . . . . . 5		2.1.3. supplementary . . . . . . . . . . . . . . . . . . . . 5
	2.1.4. background . . . . . . . . . . . . . . . . . . . . . 6		2.1.4. background . . . . . . . . . . . . . . . . . . . . . 6
	2.2. progressive . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. progressive . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Merging Client- and Server-Driven Parameters . . . . . . . . 7		3. Merging Client- and Server-Driven Parameters . . . . . . . . 7
	4. Coexistence with HTTP/2 Priorities . . . . . . . . . . . . . 7		4. Coexistence with HTTP/2 Priorities . . . . . . . . . . . . . 7
	4.1. The SETTINGS_HEADER_BASED_PRIORITY SETTINGS Parameter . . 8		4.1. The SETTINGS_HEADER_BASED_PRIORITY SETTINGS Parameter . . 8
	5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 8		5. Considerations . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Why use an End-to-End Header Field? . . . . . . . . . . . 8		5.1. Why use an End-to-End Header Field? . . . . . . . . . . . 8
	5.2. Why do Urgencies Have Meanings? . . . . . . . . . . . . . 9		5.2. Why do Urgencies Have Meanings? . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5.3. Reprioritization . . . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11		8.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
	B.1. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 11		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		B.1. Since draft-kazuho-httpbis-priority-01 . . . . . . . . . 12
			B.2. Since draft-kazuho-httpbis-priority-00 . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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 9, line 40 ¶		skipping to change at page 9, line 40 ¶
	Or, a graphical user-agent could send a "visible" parameter to		Or, a graphical user-agent could send a "visible" parameter to
	indicate if the resource being requested is within the viewport.		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.
			5.3. Reprioritization
			Once a client sends a request, it cannot reprioritize the
			corresponding response by using the Priority header field. This is
			because an HTTP header field can only be sent as part of an HTTP
			message.
			Therefore, to support reprioritization, it is necessary to define a
			HTTP-version-dependent mechanism for transmitting the priority
			parameters.
			One approach that we can use in HTTP/2 ([RFC7540]) is to use a frame
			that carries the priority parameters.
			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
			+---------------------------------------------------------------+
			|R| Stream ID (31) |
			+---------------------------------------------------------------+
			| Priority Field Value (*) ...
			+---------------------------------------------------------------+
			Figure 1: Reprioritization frame payload
			The Reprioritization frame would be sent on stream 0. This frame
			carries the stream ID of the response that is being reprioritized,
			and the updated priority in ASCII text, using the same
			represententation as that of the Priority header field value.
			As an example, a web browser might issue a prefetch request for an
			HTML on stream 31, with the urgency parameter of the Priority request
			header field set to "background". Then, when the user navigates to
			the HTML while prefetch is in action, it would send a
			reprioritization frame with the stream ID set to 31, and the priority
			field value set to "urgency=0".
	6. Security Considerations		6. Security Considerations
	TBD		TBD
	7. IANA Considerations		7. 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
	skipping to change at page 11, line 38 ¶		skipping to change at page 12, line 24 ¶
	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 [1]. In https://github.com/pmeenan/http3-		slides-83-httpbis-5.pdf [1]. In https://github.com/pmeenan/http3-
	prioritization-proposal [2], Patrick Meenan advocates for		prioritization-proposal [2], Patrick Meenan advocates for
	representing the priorities using a tuple of urgency and concurrency.		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		Appendix B. Change Log
	B.1. Since draft-kazuho-httpbis-priority-00		B.1. Since draft-kazuho-httpbis-priority-01
			o Explain how reprioritization might be supported.
			B.2. 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
	Lucas Pardue		Lucas Pardue
	Cloudflare		Cloudflare
	Email: lucaspardue.24.7@gmail.com		Email: lucaspardue.24.7@gmail.com
End of changes. 7 change blocks.
	14 lines changed or deleted		57 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/