draft-ietf-quic-http-19.txt		draft-ietf-quic-http-latest.txt
	QUIC Working Group M. Bishop, Ed.		QUIC Working Group M. Bishop, Ed.
	Internet-Draft Akamai		Internet-Draft Akamai
	Intended status: Standards Track March 11, 2019		Intended status: Standards Track April 21, 2019
	Expires: September 12, 2019		Expires: October 23, 2019
	Hypertext Transfer Protocol Version 3 (HTTP/3)		Hypertext Transfer Protocol Version 3 (HTTP/3)
	draft-ietf-quic-http-19		draft-ietf-quic-http-latest
	Abstract		Abstract
	The QUIC transport protocol has several features that are desirable		The QUIC transport protocol has several features that are desirable
	in a transport for HTTP, such as stream multiplexing, per-stream flow		in a transport for HTTP, such as stream multiplexing, per-stream flow
	control, and low-latency connection establishment. This document		control, and low-latency connection establishment. This document
	describes a mapping of HTTP semantics over QUIC. This document also		describes a mapping of HTTP semantics over QUIC. This document also
	identifies HTTP/2 features that are subsumed by QUIC, and describes		identifies HTTP/2 features that are subsumed by QUIC, and describes
	how HTTP/2 extensions can be ported to HTTP/3.		how HTTP/2 extensions can be ported to HTTP/3.
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	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 12, 2019.		This Internet-Draft will expire on October 23, 2019.
	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 33 ¶		skipping to change at page 2, line 33 ¶
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
	2. Connection Setup and Management . . . . . . . . . . . . . . . 5		2. Connection Setup and Management . . . . . . . . . . . . . . . 5
	2.1. Draft Version Identification . . . . . . . . . . . . . . 5		2.1. Draft Version Identification . . . . . . . . . . . . . . 5
	2.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 5		2.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 5
	2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6		2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6
	2.3. Connection Establishment . . . . . . . . . . . . . . . . 6		2.3. Connection Establishment . . . . . . . . . . . . . . . . 6
	2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7		2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7
	3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7		3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7
	3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8		3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8
	3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8		3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8
	3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 9		3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 10
	3.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 10		3.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 10
	3.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 10		3.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 11
	4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11		4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12		4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12
	4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 12		4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13
	4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 12		4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 13		4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 14
	4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 13		4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14
	4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16		4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 17
	4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 17		4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 18
	4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19		4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 20
	4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20		4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 21
	4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 20		4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 21
	4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 21		4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 22
	4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 22		4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 23
	5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 22		5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 23
	5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 22		5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 23
	5.1.1. Header Formatting and Compression . . . . . . . . . . 24		5.1.1. Header Formatting and Compression . . . . . . . . . . 25
	5.1.2. Request Cancellation and Rejection . . . . . . . . . 24		5.1.2. Request Cancellation and Rejection . . . . . . . . . 25
	5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 25		5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 26
	5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 26		5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 27
	5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 27		5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 28
	5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 27		5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 28
	5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 28		5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 29
	6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 29		6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 31
	6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 30		6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 31
	6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 30		6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 31
	6.3. Immediate Application Closure . . . . . . . . . . . . . . 31		6.3. Immediate Application Closure . . . . . . . . . . . . . . 33
	6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 32		6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 33
	7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 32		7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 33
	8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33		8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 34
	8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 33		8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 34
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 35		9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
	10.1. Registration of HTTP/3 Identification String . . . . . . 35		10.1. Registration of HTTP/3 Identification String . . . . . . 37
	10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 36		10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 37
	10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 36		10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37
	10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 37		10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 38
	10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 38		10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 39
	10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 41		10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 42
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	11.1. Normative References . . . . . . . . . . . . . . . . . . 42		11.1. Normative References . . . . . . . . . . . . . . . . . . 43
	11.2. Informative References . . . . . . . . . . . . . . . . . 43		11.2. Informative References . . . . . . . . . . . . . . . . . 44
	11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43		11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
	Appendix A. Considerations for Transitioning from HTTP/2 . . . . 44		Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45
	A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 44		A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45
	A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 44		A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45
	A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 46		A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48
	A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 47		A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 48		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50
	B.1. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 48		B.1. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 50
	B.2. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 49		B.2. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 50
	B.3. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 49		B.3. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 50
	B.4. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 50		B.4. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 51
	B.5. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 50		B.5. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 51
	B.6. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 50		B.6. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 51
	B.7. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 50		B.7. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 52
	B.8. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 51		B.8. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 52
	B.9. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 51		B.9. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 52
	B.10. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 51		B.10. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 52
	B.11. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 51		B.11. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 52
	B.12. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 51		B.12. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 52
	B.13. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 51		B.13. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 53
	B.14. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 51		B.14. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 53
	B.15. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 52		B.15. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 53
	B.16. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 52		B.16. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 53
	B.17. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 52		B.17. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 53
	B.18. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 52		B.18. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 53
	B.19. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 53		B.19. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 54
	B.20. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 53		B.20. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 54
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 54
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55
	1. Introduction		1. Introduction
	HTTP semantics are used for a broad range of services on the		HTTP semantics are used for a broad range of services on the
	Internet. These semantics have commonly been used with two different		Internet. These semantics have commonly been used with two different
	TCP mappings, HTTP/1.1 and HTTP/2. HTTP/2 introduced a framing and		TCP mappings, HTTP/1.1 and HTTP/2. HTTP/2 introduced a framing and
	multiplexing layer to improve latency without modifying the transport		multiplexing layer to improve latency without modifying the transport
	layer. However, TCP's lack of visibility into parallel requests in		layer. However, TCP's lack of visibility into parallel requests in
	both mappings limited the possible performance gains.		both mappings limited the possible performance gains.
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 18 ¶
	| Stream Type (i) ...		| Stream Type (i) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Unidirectional Stream Header		Figure 1: Unidirectional Stream Header
	Some stream types are reserved (Section 3.2.3). Two stream types are		Some stream types are reserved (Section 3.2.3). Two stream types are
	defined in this document: control streams (Section 3.2.1) and push		defined in this document: control streams (Section 3.2.1) and push
	streams (Section 3.2.2). Other stream types can be defined by		streams (Section 3.2.2). Other stream types can be defined by
	extensions to HTTP/3; see Section 7 for more details.		extensions to HTTP/3; see Section 7 for more details.
	Both clients and servers SHOULD send a value of three or greater for		The performance of HTTP/3 connections in the early phase of their
	the QUIC transport parameter "initial_max_uni_streams".		lifetime is sensitive to the creation and exchange of data on
			unidirectional streams. Endpoints that set low values for the QUIC
			transport parameters "initial_max_uni_streams" and
			"initial_max_stream_data_uni" will increase the chance that the
			remote peer reaches the limit early and becomes blocked. In
			particular, the value chosen for "initial_max_uni_streams" should
			consider that remote peers may wish to exercise reserved stream
			behaviour (Section 3.2.3). To reduce the likelihood of blocking,
			both clients and servers SHOULD send a value of three or greater for
			the QUIC transport parameter "initial_max_uni_streams", and a value
			of 1,024 or greater for the QUIC transport parameter
			"initial_max_stream_data_uni".
	If the stream header indicates a stream type which is not supported		If the stream header indicates a stream type which is not supported
	by the recipient, the remainder of the stream cannot be consumed as		by the recipient, the remainder of the stream cannot be consumed as
	the semantics are unknown. Recipients of unknown stream types MAY		the semantics are unknown. Recipients of unknown stream types MAY
	trigger a QUIC STOP_SENDING frame with an error code of		trigger a QUIC STOP_SENDING frame with an error code of
	HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an		HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an
	error of any kind.		error of any kind.
	Implementations MAY send stream types before knowing whether the peer		Implementations MAY send stream types before knowing whether the peer
	supports them. However, stream types which could modify the state or		supports them. However, stream types which could modify the state or
	skipping to change at page 14, line 27 ¶		skipping to change at page 15, line 27 ¶
	The PRIORITY frame payload has the following fields:		The PRIORITY frame payload has the following fields:
	PT (Prioritized Element Type): A two-bit field indicating the type		PT (Prioritized Element Type): A two-bit field indicating the type
	of element being prioritized (see Table 2). When sent on a		of element being prioritized (see Table 2). When sent on a
	request stream, this MUST be set to "11". When sent on the		request stream, this MUST be set to "11". When sent on the
	control stream, this MUST NOT be set to "11".		control stream, this MUST NOT be set to "11".
	DT (Element Dependency Type): A two-bit field indicating the type of		DT (Element Dependency Type): A two-bit field indicating the type of
	element being depended on (see Table 3).		element being depended on (see Table 3).
	Empty: A four-bit field which MUST be zero when sent and MUST be		Empty: A four-bit field which MUST be zero when sent and has no
	ignored on receipt.		semantic value on receipt.
	Prioritized Element ID: A variable-length integer that identifies		Prioritized Element ID: A variable-length integer that identifies
	the element being prioritized. Depending on the value of		the element being prioritized. Depending on the value of
	Prioritized Type, this contains the Stream ID of a request stream,		Prioritized Type, this contains the Stream ID of a request stream,
	the Push ID of a promised resource, a Placeholder ID of a		the Push ID of a promised resource, a Placeholder ID of a
	placeholder, or is absent.		placeholder, or is absent.
	Element Dependency ID: A variable-length integer that identifies the		Element Dependency ID: A variable-length integer that identifies the
	element on which a dependency is being expressed. Depending on		element on which a dependency is being expressed. Depending on
	the value of Dependency Type, this contains the Stream ID of a		the value of Dependency Type, this contains the Stream ID of a
	skipping to change at page 15, line 42 ¶		skipping to change at page 16, line 42 ¶
	Note that unlike in [RFC7540], the root of the tree cannot be		Note that unlike in [RFC7540], the root of the tree cannot be
	referenced using a Stream ID of 0, as in QUIC stream 0 carries a		referenced using a Stream ID of 0, as in QUIC stream 0 carries a
	valid HTTP request. The root of the tree cannot be reprioritized. A		valid HTTP request. The root of the tree cannot be reprioritized. A
	PRIORITY frame sent on a request stream with the Prioritized Element		PRIORITY frame sent on a request stream with the Prioritized Element
	Type set to any value other than "11" or which expresses a dependency		Type set to any value other than "11" or which expresses a dependency
	on a request with a greater Stream ID than the current stream MUST be		on a request with a greater Stream ID than the current stream MUST be
	treated as a stream error of type HTTP_MALFORMED_FRAME. Likewise, a		treated as a stream error of type HTTP_MALFORMED_FRAME. Likewise, a
	PRIORITY frame sent on a control stream with the Prioritized Element		PRIORITY frame sent on a control stream with the Prioritized Element
	Type set to "11" MUST be treated as a connection error of type		Type set to "11" MUST be treated as a connection error of type
			HTTP_MALFORMED_FRAME. A PRIORITY frame with Empty bits not set to
			zero MAY be treated as a connection error of type
	HTTP_MALFORMED_FRAME.		HTTP_MALFORMED_FRAME.
	When a PRIORITY frame claims to reference a request, the associated		When a PRIORITY frame claims to reference a request, the associated
	ID MUST identify a client-initiated bidirectional stream. A server		ID MUST identify a client-initiated bidirectional stream. A server
	MUST treat receipt of a PRIORITY frame identifying a stream of any		MUST treat receipt of a PRIORITY frame identifying a stream of any
	other type as a connection error of type HTTP_MALFORMED_FRAME.		other type as a connection error of type HTTP_MALFORMED_FRAME.
	A PRIORITY frame that references a non-existent Push ID, a		A PRIORITY frame that references a non-existent Push ID, a
	Placeholder ID greater than the server's limit, or a Stream ID the		Placeholder ID greater than the server's limit, or a Stream ID the
	client is not yet permitted to open MUST be treated as an		client is not yet permitted to open MUST be treated as an
	skipping to change at page 18, line 15 ¶		skipping to change at page 19, line 15 ¶
	An implementation MUST ignore the contents for any SETTINGS		An implementation MUST ignore the contents for any SETTINGS
	identifier it does not understand.		identifier it does not understand.
	4.2.5.1. Defined SETTINGS Parameters		4.2.5.1. Defined SETTINGS Parameters
	The following settings are defined in HTTP/3:		The following settings are defined in HTTP/3:
	SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited.		SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited.
	See Section 5.1.1 for usage.		See Section 5.1.1 for usage.
	SETTINGS_NUM_PLACEHOLDERS (0x8): The default value is 0. However,		SETTINGS_NUM_PLACEHOLDERS (0x9): The default value is 0. However,
	this value SHOULD be set to a non-zero value by servers. See		this value SHOULD be set to a non-zero value by servers. See
	Section 5.3.1 for usage.		Section 5.3.1 for usage.
	Setting identifiers of the format "0x1f * N + 0x21" for integer		Setting identifiers of the format "0x1f * N + 0x21" for integer
	values of N are reserved to exercise the requirement that unknown		values of N are reserved to exercise the requirement that unknown
	identifiers be ignored. Such settings have no defined meaning.		identifiers be ignored. Such settings have no defined meaning.
	Endpoints SHOULD include at least one such setting in their SETTINGS		Endpoints SHOULD include at least one such setting in their SETTINGS
	frame. Endpoints MUST NOT consider such settings to have any meaning		frame. Endpoints MUST NOT consider such settings to have any meaning
	upon receipt.		upon receipt.
	skipping to change at page 29, line 22 ¶		skipping to change at page 30, line 22 ¶
	(see Section 4.2.6) on the request stream which generated the push.		(see Section 4.2.6) on the request stream which generated the push.
	This allows the server push to be associated with a client request.		This allows the server push to be associated with a client request.
	Ordering of a PUSH_PROMISE in relation to certain parts of the		Ordering of a PUSH_PROMISE in relation to certain parts of the
	response is important (see Section 8.2.1 of [RFC7540]). Promised		response is important (see Section 8.2.1 of [RFC7540]). Promised
	requests MUST conform to the requirements in Section 8.2 of		requests MUST conform to the requirements in Section 8.2 of
	[RFC7540].		[RFC7540].
	The same server push can be associated with additional client		The same server push can be associated with additional client
	requests using a DUPLICATE_PUSH frame (see Section 4.2.9). Ordering		requests using a DUPLICATE_PUSH frame (see Section 4.2.9). Ordering
	of a DUPLICATE_PUSH in relation to certain parts of the response is		of a DUPLICATE_PUSH in relation to certain parts of the response is
	similarly important. Due to reordering, DUPLICATE_PUSH frames can		similarly important.
	arrive before the corresponding PUSH_PROMISE frame, in which case the
	request headers of the push would not be immediately available.
	Clients which receive a DUPLICATE_PUSH frame for an as-yet-unknown
	Push ID can either delay generating new requests for content
	referenced following the DUPLICATE_PUSH frame until the request
	headers become available, or can initiate requests for discovered
	resources and cancel the requests if the requested resource is
	already being pushed.
	When a server later fulfills a promise, the server push response is		When a server later fulfills a promise, the server push response is
	conveyed on a push stream (see Section 3.2.2). The push stream		conveyed on a push stream (see Section 3.2.2). The push stream
	identifies the Push ID of the promise that it fulfills, then contains		identifies the Push ID of the promise that it fulfills, then contains
	a response to the promised request using the same format described		a response to the promised request using the same format described
	for responses in Section 5.1.		for responses in Section 5.1.
			Due to reordering, DUPLICATE_PUSH frames or push stream data can
			arrive before the corresponding PUSH_PROMISE frame. When a client
			receives a DUPLICATE_PUSH frame for an as-yet-unknown Push ID, the
			request headers of the push are not immediately available. The
			client can either delay generating new requests for content
			referenced following the DUPLICATE_PUSH frame until the request
			headers become available, or can initiate requests for discovered
			resources and cancel the requests if the requested resource is
			already being pushed. When a client receives a new push stream with
			an as-yet-unknown Push ID, both the associated client request and the
			pushed request headers are unknown. The client can buffer the stream
			data in expectation of the matching PUSH_PROMISE. The client can use
			stream flow control (see section 4.1 of [QUIC-TRANSPORT]) to limit
			the amount of data a server may commit to the pushed stream.
	If a promised server push is not needed by the client, the client		If a promised server push is not needed by the client, the client
	SHOULD send a CANCEL_PUSH frame. If the push stream is already open		SHOULD send a CANCEL_PUSH frame. If the push stream is already open
	or opens after sending the CANCEL_PUSH frame, a QUIC STOP_SENDING		or opens after sending the CANCEL_PUSH frame, a QUIC STOP_SENDING
	frame with an appropriate error code can also be used (e.g.,		frame with an appropriate error code can also be used (e.g.,
	HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see Section 8). This		HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see Section 8). This
	asks the server not to transfer additional data and indicates that it		asks the server not to transfer additional data and indicates that it
	will be discarded upon receipt.		will be discarded upon receipt.
	6. Connection Closure		6. Connection Closure
	skipping to change at page 37, line 35 ¶		skipping to change at page 38, line 41 ¶
	| | | |		| | | |
	| Reserved | 0x9 | N/A |		| Reserved | 0x9 | N/A |
	| | | |		| | | |
	| MAX_PUSH_ID | 0xD | Section 4.2.8 |		| MAX_PUSH_ID | 0xD | Section 4.2.8 |
	| | | |		| | | |
	| DUPLICATE_PUSH | 0xE | Section 4.2.9 |		| DUPLICATE_PUSH | 0xE | Section 4.2.9 |
	+----------------+------+----------------+		+----------------+------+----------------+
	Additionally, each code of the format "0x1f * N + 0x21" for integer		Additionally, each code of the format "0x1f * N + 0x21" for integer
	values of N (that is, "0x21", "0x40", ..., through		values of N (that is, "0x21", "0x40", ..., through
	"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.		"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
	10.4. Settings Parameters		10.4. Settings Parameters
	This document establishes a registry for HTTP/3 settings. The		This document establishes a registry for HTTP/3 settings. The
	"HTTP/3 Settings" registry governs a 62-bit space. This space is		"HTTP/3 Settings" registry governs a 62-bit space. This space is
	split into three spaces that are governed by different policies.		split into three spaces that are governed by different policies.
	Values between "0x00" and "0x3f" (in hexadecimal) are assigned via		Values between "0x00" and "0x3f" (in hexadecimal) are assigned via
	the Standards Action or IESG Review policies [RFC8126]. Values from		the Standards Action or IESG Review policies [RFC8126]. Values from
	"0x40" to "0x3fff" operate on the Specification Required policy		"0x40" to "0x3fff" operate on the Specification Required policy
	[RFC8126]. All other values are assigned to Private Use [RFC8126].		[RFC8126]. All other values are assigned to Private Use [RFC8126].
	skipping to change at page 38, line 32 ¶		skipping to change at page 39, line 39 ¶
	| Reserved | 0x2 | N/A |		| Reserved | 0x2 | N/A |
	| | | |		| | | |
	| Reserved | 0x3 | N/A |		| Reserved | 0x3 | N/A |
	| | | |		| | | |
	| Reserved | 0x4 | N/A |		| Reserved | 0x4 | N/A |
	| | | |		| | | |
	| Reserved | 0x5 | N/A |		| Reserved | 0x5 | N/A |
	| | | |		| | | |
	| MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.1 |		| MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.1 |
	| | | |		| | | |
	| NUM_PLACEHOLDERS | 0x8 | Section 4.2.5.1 |		| NUM_PLACEHOLDERS | 0x9 | Section 4.2.5.1 |
	+----------------------+------+------------------+		+----------------------+------+------------------+
	Additionally, each code of the format "0x1f * N + 0x21" for integer		Additionally, each code of the format "0x1f * N + 0x21" for integer
	values of N (that is, "0x21", "0x40", ..., through		values of N (that is, "0x21", "0x40", ..., through
	"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.		"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
	10.5. Error Codes		10.5. Error Codes
	This document establishes a registry for HTTP/3 error codes. The		This document establishes a registry for HTTP/3 error codes. The
	"HTTP/3 Error Code" registry manages a 16-bit space. The "HTTP/3		"HTTP/3 Error Code" registry manages a 16-bit space. The "HTTP/3
	Error Code" registry operates under the "Expert Review" policy		Error Code" registry operates under the "Expert Review" policy
	[RFC8126].		[RFC8126].
	Registrations for error codes are required to include a description		Registrations for error codes are required to include a description
	of the error code. An expert reviewer is advised to examine new		of the error code. An expert reviewer is advised to examine new
	skipping to change at page 41, line 51 ¶		skipping to change at page 43, line 15 ¶
	+----------------+------+----------------+--------+		+----------------+------+----------------+--------+
	| Stream Type | Code | Specification | Sender |		| Stream Type | Code | Specification | Sender |
	+----------------+------+----------------+--------+		+----------------+------+----------------+--------+
	| Control Stream | 0x00 | Section 3.2.1 | Both |		| Control Stream | 0x00 | Section 3.2.1 | Both |
	| | | | |		| | | | |
	| Push Stream | 0x01 | Section 5.4 | Server |		| Push Stream | 0x01 | Section 5.4 | Server |
	+----------------+------+----------------+--------+		+----------------+------+----------------+--------+
	Additionally, each code of the format "0x1f * N + 0x21" for integer		Additionally, each code of the format "0x1f * N + 0x21" for integer
	values of N (that is, "0x21", "0x40", ..., through		values of N (that is, "0x21", "0x40", ..., through
	"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.		"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP		[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
	Alternative Services", RFC 7838, DOI 10.17487/RFC7838,		Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
	April 2016, <https://www.rfc-editor.org/info/rfc7838>.		April 2016, <https://www.rfc-editor.org/info/rfc7838>.
	[HTTP-REPLAY]		[HTTP-REPLAY]
	Thomson, M., Nottingham, M., and W. Tarreau, "Using Early		Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
	Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September		Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
	2018, <https://www.rfc-editor.org/info/rfc8470>.		2018, <https://www.rfc-editor.org/info/rfc8470>.
	[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:		[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
	Header Compression for HTTP over QUIC", draft-ietf-quic-		Header Compression for HTTP over QUIC", draft-ietf-quic-
	qpack-07 (work in progress).		qpack-latest (work in progress).
	[QUIC-TRANSPORT]		[QUIC-TRANSPORT]
	Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based		Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
	Multiplexed and Secure Transport", draft-ietf-quic-		Multiplexed and Secure Transport", draft-ietf-quic-
	transport-19 (work in progress).		transport-latest (work in progress).
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, DOI 10.17487/RFC0793, September 1981,		RFC 793, DOI 10.17487/RFC0793, September 1981,
	<https://www.rfc-editor.org/info/rfc793>.		<https://www.rfc-editor.org/info/rfc793>.
	[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>.
	skipping to change at page 45, line 15 ¶		skipping to change at page 46, line 25 ¶
	be received in the order sent, HTTP/3 will break them.		be received in the order sent, HTTP/3 will break them.
	For example, implicit in the HTTP/2 prioritization scheme is the		For example, implicit in the HTTP/2 prioritization scheme is the
	notion of in-order delivery of priority changes (i.e., dependency		notion of in-order delivery of priority changes (i.e., dependency
	tree mutations): since operations on the dependency tree such as		tree mutations): since operations on the dependency tree such as
	reparenting a subtree are not commutative, both sender and receiver		reparenting a subtree are not commutative, both sender and receiver
	must apply them in the same order to ensure that both sides have a		must apply them in the same order to ensure that both sides have a
	consistent view of the stream dependency tree. HTTP/2 specifies		consistent view of the stream dependency tree. HTTP/2 specifies
	priority assignments in PRIORITY frames and (optionally) in HEADERS		priority assignments in PRIORITY frames and (optionally) in HEADERS
	frames. To achieve in-order delivery of priority changes in HTTP/3,		frames. To achieve in-order delivery of priority changes in HTTP/3,
	PRIORITY frames are sent on the control stream and exclusive		PRIORITY frames are sent as the first frame on a request stream or on
	prioritization has been removed.		the control stream and exclusive prioritization has been removed.
			HTTP/3 permits the prioritisation of requests, pushes and
			placeholders that each exist in separate identifier spaces. The
			HTTP/3 PRIORITY frame replaces the stream dependency field with
			fields that can identify the element of interest and its dependency.
	Likewise, HPACK was designed with the assumption of in-order		Likewise, HPACK was designed with the assumption of in-order
	delivery. A sequence of encoded header blocks must arrive (and be		delivery. A sequence of encoded header blocks must arrive (and be
	decoded) at an endpoint in the same order in which they were encoded.		decoded) at an endpoint in the same order in which they were encoded.
	This ensures that the dynamic state at the two endpoints remains in		This ensures that the dynamic state at the two endpoints remains in
	sync. As a result, HTTP/3 uses a modified version of HPACK,		sync. As a result, HTTP/3 uses a modified version of HPACK,
	described in [QPACK].		described in [QPACK].
	Frame type definitions in HTTP/3 often use the QUIC variable-length		Frame type definitions in HTTP/3 often use the QUIC variable-length
	integer encoding. In particular, Stream IDs use this encoding, which		integer encoding. In particular, Stream IDs use this encoding, which
	skipping to change at page 45, line 48 ¶		skipping to change at page 47, line 16 ¶
	portable to QUIC simply by replacing Stream 0 in HTTP/2 with a		portable to QUIC simply by replacing Stream 0 in HTTP/2 with a
	control stream in HTTP/3. HTTP/3 extensions will not assume		control stream in HTTP/3. HTTP/3 extensions will not assume
	ordering, but would not be harmed by ordering, and would be portable		ordering, but would not be harmed by ordering, and would be portable
	to HTTP/2 in the same manner.		to HTTP/2 in the same manner.
	Below is a listing of how each HTTP/2 frame type is mapped:		Below is a listing of how each HTTP/2 frame type is mapped:
	DATA (0x0): Padding is not defined in HTTP/3 frames. See		DATA (0x0): Padding is not defined in HTTP/3 frames. See
	Section 4.2.1.		Section 4.2.1.
	HEADERS (0x1): As described above, the PRIORITY region of HEADERS is		HEADERS (0x1): The PRIORITY region of HEADERS is not defined in
	not supported. A separate PRIORITY frame MUST be used. Padding		HTTP/3 frames. A separate PRIORITY frame is used in all cases.
	is not defined in HTTP/3 frames. See Section 4.2.2.		Padding is not defined in HTTP/3 frames. See Section 4.2.2.
	PRIORITY (0x2): As described above, the PRIORITY frame is sent on		PRIORITY (0x2): As described above, the PRIORITY frame references a
	the control stream and can reference a variety of identifiers.		variety of identifiers. It is sent as the first frame on a
	See Section 4.2.3.		request streams or on the control stream. See Section 4.2.3.
	RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC		RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC
	provides stream lifecycle management. The same code point is used		provides stream lifecycle management. The same code point is used
	for the CANCEL_PUSH frame (Section 4.2.4).		for the CANCEL_PUSH frame (Section 4.2.4).
	SETTINGS (0x4): SETTINGS frames are sent only at the beginning of		SETTINGS (0x4): SETTINGS frames are sent only at the beginning of
	the connection. See Section 4.2.5 and Appendix A.3.		the connection. See Section 4.2.5 and Appendix A.3.
	PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream;		PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream;
	instead the push stream references the PUSH_PROMISE frame using a		instead the push stream references the PUSH_PROMISE frame using a
End of changes. 22 change blocks.
	102 lines changed or deleted		126 lines changed or added
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/