draft-ietf-quic-http-19.txt		draft-ietf-quic-http-20.txt
	QUIC M. Bishop, Ed.		QUIC M. Bishop, Ed.
	Internet-Draft Akamai		Internet-Draft Akamai
	Intended status: Standards Track March 11, 2019		Intended status: Standards Track April 23, 2019
	Expires: September 12, 2019		Expires: October 25, 2019
	Hypertext Transfer Protocol Version 3 (HTTP/3)		Hypertext Transfer Protocol Version 3 (HTTP/3)
	draft-ietf-quic-http-19		draft-ietf-quic-http-20
	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 25, 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-19 . . . . . . . . . . . . . . 50
	B.2. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 49		B.2. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 50
	B.3. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 49		B.3. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 50
	B.4. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 50		B.4. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 51
	B.5. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 50		B.5. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 51
	B.6. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 50		B.6. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 51
	B.7. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 50		B.7. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 52
	B.8. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 51		B.8. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 52
	B.9. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 51		B.9. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 52
	B.10. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 51		B.10. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 52
	B.11. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 51		B.11. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 52
	B.12. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 51		B.12. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 53
	B.13. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 51		B.13. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 53
	B.14. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 51		B.14. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 53
	B.15. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 52		B.15. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 53
	B.16. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 52		B.16. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 53
	B.17. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 52		B.17. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 54
	B.18. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 52		B.18. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 54
	B.19. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 53		B.19. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 54
	B.20. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 53		B.20. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 54
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53		B.21. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 55
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55
			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 20, line 46 ¶		skipping to change at page 21, line 46 ¶
	See Section 6.2 for more information on the use of the GOAWAY frame.		See Section 6.2 for more information on the use of the GOAWAY frame.
	4.2.8. MAX_PUSH_ID		4.2.8. MAX_PUSH_ID
	The MAX_PUSH_ID frame (type=0xD) is used by clients to control the		The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
	number of server pushes that the server can initiate. This sets the		number of server pushes that the server can initiate. This sets the
	maximum value for a Push ID that the server can use in a PUSH_PROMISE		maximum value for a Push ID that the server can use in a PUSH_PROMISE
	frame. Consequently, this also limits the number of push streams		frame. Consequently, this also limits the number of push streams
	that the server can initiate in addition to the limit set by the QUIC		that the server can initiate in addition to the limit set by the QUIC
	MAX_STREAM_ID frame.		MAX_STREAMS frame.
	The MAX_PUSH_ID frame is always sent on the control stream. Receipt		The MAX_PUSH_ID frame is always sent on the control stream. Receipt
	of a MAX_PUSH_ID frame on any other stream MUST be treated as a		of a MAX_PUSH_ID frame on any other stream MUST be treated as a
	connection error of type HTTP_WRONG_STREAM.		connection error of type HTTP_WRONG_STREAM.
	A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the		A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the
	receipt of a MAX_PUSH_ID frame as a connection error of type		receipt of a MAX_PUSH_ID frame as a connection error of type
	HTTP_UNEXPECTED_FRAME.		HTTP_UNEXPECTED_FRAME.
	The maximum Push ID is unset when a connection is created, meaning		The maximum Push ID is unset when a connection is created, meaning
	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 31, line 43 ¶		skipping to change at page 33, line 5 ¶
	prohibited. After allowing time for any in-flight requests (at least		prohibited. After allowing time for any in-flight requests (at least
	one round-trip time), the server MAY send another GOAWAY frame with		one round-trip time), the server MAY send another GOAWAY frame with
	an updated last Stream ID. This ensures that a connection can be		an updated last Stream ID. This ensures that a connection can be
	cleanly shut down without losing requests.		cleanly shut down without losing requests.
	Once all accepted requests have been processed, the server can permit		Once all accepted requests have been processed, the server can permit
	the connection to become idle, or MAY initiate an immediate closure		the connection to become idle, or MAY initiate an immediate closure
	of the connection. An endpoint that completes a graceful shutdown		of the connection. An endpoint that completes a graceful shutdown
	SHOULD use the HTTP_NO_ERROR code when closing the connection.		SHOULD use the HTTP_NO_ERROR code when closing the connection.
			If a client has consumed all available bidirectional stream IDs with
			requests, the server need not send a GOAWAY frame, since the client
			is unable to make further requests.
	6.3. Immediate Application Closure		6.3. Immediate Application Closure
	An HTTP/3 implementation can immediately close the QUIC connection at		An HTTP/3 implementation can immediately close the QUIC connection at
	any time. This results in sending a QUIC CONNECTION_CLOSE frame to		any time. This results in sending a QUIC CONNECTION_CLOSE frame to
	the peer; the error code in this frame indicates to the peer why the		the peer; the error code in this frame indicates to the peer why the
	connection is being closed. See Section 8 for error codes which can		connection is being closed. See Section 8 for error codes which can
	be used when closing a connection.		be used when closing a connection.
	Before closing the connection, a GOAWAY MAY be sent to allow the		Before closing the connection, a GOAWAY MAY be sent to allow the
	client to retry some requests. Including the GOAWAY frame in the		client to retry some requests. Including the GOAWAY frame in the
	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), March 2019.		qpack-08 (work in progress), April 2019.
	[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-18 (work in progress), March 2019.		transport-18 (work in progress), April 2019.
	[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
	skipping to change at page 48, line 47 ¶		skipping to change at page 50, line 15 ¶
	HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1.		HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1.
	Error codes need to be defined for HTTP/2 and HTTP/3 separately. See		Error codes need to be defined for HTTP/2 and HTTP/3 separately. See
	Section 10.5.		Section 10.5.
	Appendix B. Change Log		Appendix B. Change Log
	*RFC Editor's Note:* Please remove this section prior to		*RFC Editor's Note:* Please remove this section prior to
	publication of a final version of this document.		publication of a final version of this document.
	B.1. Since draft-ietf-quic-http-18		B.1. Since draft-ietf-quic-http-19
			o SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530)
			o Non-zero bits in the Empty field of the PRIORITY frame MAY be
			treated as an error (#2501)
			B.2. Since draft-ietf-quic-http-18
	o Resetting streams following a GOAWAY is recommended, but not		o Resetting streams following a GOAWAY is recommended, but not
	required (#2256,#2457)		required (#2256,#2457)
	o Use variable-length integers throughout (#2437,#2233,#2253,#2275)		o Use variable-length integers throughout (#2437,#2233,#2253,#2275)
	* Variable-length frame types, stream types, and settings		* Variable-length frame types, stream types, and settings
	identifiers		identifiers
	* Renumbered stream type assignments		* Renumbered stream type assignments
	* Modified associated reserved values		* Modified associated reserved values
	o Frame layout switched from Length-Type-Value to Type-Length-Value		o Frame layout switched from Length-Type-Value to Type-Length-Value
	(#2395,#2235)		(#2395,#2235)
	o Specified error code for servers receiving DUPLICATE_PUSH (#2497)		o Specified error code for servers receiving DUPLICATE_PUSH (#2497)
	o Use connection error for invalid PRIORITY (#2507, #2508)		o Use connection error for invalid PRIORITY (#2507, #2508)
	B.2. Since draft-ietf-quic-http-17		B.3. Since draft-ietf-quic-http-17
	o HTTP_REQUEST_REJECTED is used to indicate a request can be retried		o HTTP_REQUEST_REJECTED is used to indicate a request can be retried
	(#2106, #2325)		(#2106, #2325)
	o Changed error code for GOAWAY on the wrong stream (#2231, #2343)		o Changed error code for GOAWAY on the wrong stream (#2231, #2343)
	B.3. Since draft-ietf-quic-http-16		B.4. Since draft-ietf-quic-http-16
	o Rename "HTTP/QUIC" to "HTTP/3" (#1973)		o Rename "HTTP/QUIC" to "HTTP/3" (#1973)
	o Changes to PRIORITY frame (#1865, #2075)		o Changes to PRIORITY frame (#1865, #2075)
	* Permitted as first frame of request streams		* Permitted as first frame of request streams
	* Remove exclusive reprioritization		* Remove exclusive reprioritization
	* Changes to Prioritized Element Type bits		* Changes to Prioritized Element Type bits
	skipping to change at page 50, line 5 ¶		skipping to change at page 51, line 31 ¶
	(#1809, #1846, #2038)		(#1809, #1846, #2038)
	o Clarify message processing rules for streams that aren't closed		o Clarify message processing rules for streams that aren't closed
	(#1972, #2003)		(#1972, #2003)
	o Removed reservation of error code 0 and moved HTTP_NO_ERROR to		o Removed reservation of error code 0 and moved HTTP_NO_ERROR to
	this value (#1922)		this value (#1922)
	o Removed prohibition of zero-length DATA frames (#2098)		o Removed prohibition of zero-length DATA frames (#2098)
	B.4. Since draft-ietf-quic-http-15		B.5. Since draft-ietf-quic-http-15
	Substantial editorial reorganization; no technical changes.		Substantial editorial reorganization; no technical changes.
	B.5. Since draft-ietf-quic-http-14		B.6. Since draft-ietf-quic-http-14
	o Recommend sensible values for QUIC transport parameters		o Recommend sensible values for QUIC transport parameters
	(#1720,#1806)		(#1720,#1806)
	o Define error for missing SETTINGS frame (#1697,#1808)		o Define error for missing SETTINGS frame (#1697,#1808)
	o Setting values are variable-length integers (#1556,#1807) and do		o Setting values are variable-length integers (#1556,#1807) and do
	not have separate maximum values (#1820)		not have separate maximum values (#1820)
	o Expanded discussion of connection closure (#1599,#1717,#1712)		o Expanded discussion of connection closure (#1599,#1717,#1712)
	o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)		o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)
	B.6. Since draft-ietf-quic-http-13		B.7. Since draft-ietf-quic-http-13
	o Reserved some frame types for grease (#1333, #1446)		o Reserved some frame types for grease (#1333, #1446)
	o Unknown unidirectional stream types are tolerated, not errors;		o Unknown unidirectional stream types are tolerated, not errors;
	some reserved for grease (#1490, #1525)		some reserved for grease (#1490, #1525)
	o Require settings to be remembered for 0-RTT, prohibit reductions		o Require settings to be remembered for 0-RTT, prohibit reductions
	(#1541, #1641)		(#1541, #1641)
	o Specify behavior for truncated requests (#1596, #1643)		o Specify behavior for truncated requests (#1596, #1643)
	B.7. Since draft-ietf-quic-http-12		B.8. Since draft-ietf-quic-http-12
	o TLS SNI extension isn't mandatory if an alternative method is used		o TLS SNI extension isn't mandatory if an alternative method is used
	(#1459, #1462, #1466)		(#1459, #1462, #1466)
	o Removed flags from HTTP/3 frames (#1388, #1398)		o Removed flags from HTTP/3 frames (#1388, #1398)
	o Reserved frame types and settings for use in preserving		o Reserved frame types and settings for use in preserving
	extensibility (#1333, #1446)		extensibility (#1333, #1446)
	o Added general error code (#1391, #1397)		o Added general error code (#1391, #1397)
	o Unidirectional streams carry a type byte and are extensible		o Unidirectional streams carry a type byte and are extensible
	(#910,#1359)		(#910,#1359)
	o Priority mechanism now uses explicit placeholders to enable		o Priority mechanism now uses explicit placeholders to enable
	persistent structure in the tree (#441,#1421,#1422)		persistent structure in the tree (#441,#1421,#1422)
	B.8. Since draft-ietf-quic-http-11		B.9. Since draft-ietf-quic-http-11
	o Moved QPACK table updates and acknowledgments to dedicated streams		o Moved QPACK table updates and acknowledgments to dedicated streams
	(#1121, #1122, #1238)		(#1121, #1122, #1238)
	B.9. Since draft-ietf-quic-http-10		B.10. Since draft-ietf-quic-http-10
	o Settings need to be remembered when attempting and accepting 0-RTT		o Settings need to be remembered when attempting and accepting 0-RTT
	(#1157, #1207)		(#1157, #1207)
	B.10. Since draft-ietf-quic-http-09		B.11. Since draft-ietf-quic-http-09
	o Selected QCRAM for header compression (#228, #1117)		o Selected QCRAM for header compression (#228, #1117)
	o The server_name TLS extension is now mandatory (#296, #495)		o The server_name TLS extension is now mandatory (#296, #495)
	o Specified handling of unsupported versions in Alt-Svc (#1093,		o Specified handling of unsupported versions in Alt-Svc (#1093,
	#1097)		#1097)
	B.11. Since draft-ietf-quic-http-08		B.12. Since draft-ietf-quic-http-08
	o Clarified connection coalescing rules (#940, #1024)		o Clarified connection coalescing rules (#940, #1024)
	B.12. Since draft-ietf-quic-http-07		B.13. Since draft-ietf-quic-http-07
	o Changes for integer encodings in QUIC (#595,#905)		o Changes for integer encodings in QUIC (#595,#905)
	o Use unidirectional streams as appropriate (#515, #240, #281, #886)		o Use unidirectional streams as appropriate (#515, #240, #281, #886)
	o Improvement to the description of GOAWAY (#604, #898)		o Improvement to the description of GOAWAY (#604, #898)
	o Improve description of server push usage (#947, #950, #957)		o Improve description of server push usage (#947, #950, #957)
	B.13. Since draft-ietf-quic-http-06		B.14. Since draft-ietf-quic-http-06
	o Track changes in QUIC error code usage (#485)		o Track changes in QUIC error code usage (#485)
	B.14. Since draft-ietf-quic-http-05		B.15. Since draft-ietf-quic-http-05
	o Made push ID sequential, add MAX_PUSH_ID, remove		o Made push ID sequential, add MAX_PUSH_ID, remove
	SETTINGS_ENABLE_PUSH (#709)		SETTINGS_ENABLE_PUSH (#709)
	o Guidance about keep-alive and QUIC PINGs (#729)		o Guidance about keep-alive and QUIC PINGs (#729)
	o Expanded text on GOAWAY and cancellation (#757)		o Expanded text on GOAWAY and cancellation (#757)
	B.15. Since draft-ietf-quic-http-04		B.16. Since draft-ietf-quic-http-04
	o Cite RFC 5234 (#404)		o Cite RFC 5234 (#404)
	o Return to a single stream per request (#245,#557)		o Return to a single stream per request (#245,#557)
	o Use separate frame type and settings registries from HTTP/2 (#81)		o Use separate frame type and settings registries from HTTP/2 (#81)
	o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)		o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)
	o Restored GOAWAY (#696)		o Restored GOAWAY (#696)
	o Identify server push using Push ID rather than a stream ID		o Identify server push using Push ID rather than a stream ID
	(#702,#281)		(#702,#281)
	o DATA frames cannot be empty (#700)		o DATA frames cannot be empty (#700)
	B.16. Since draft-ietf-quic-http-03		B.17. Since draft-ietf-quic-http-03
	None.		None.
	B.17. Since draft-ietf-quic-http-02		B.18. Since draft-ietf-quic-http-02
	o Track changes in transport draft		o Track changes in transport draft
	B.18. Since draft-ietf-quic-http-01		B.19. Since draft-ietf-quic-http-01
	o SETTINGS changes (#181):		o SETTINGS changes (#181):
	* SETTINGS can be sent only once at the start of a connection; no		* SETTINGS can be sent only once at the start of a connection; no
	changes thereafter		changes thereafter
	* SETTINGS_ACK removed		* SETTINGS_ACK removed
	* Settings can only occur in the SETTINGS frame a single time		* Settings can only occur in the SETTINGS frame a single time
	skipping to change at page 53, line 4 ¶		skipping to change at page 54, line 35 ¶
	o Alt-Svc parameter changed from "v" to "quic"; format updated		o Alt-Svc parameter changed from "v" to "quic"; format updated
	(#229)		(#229)
	o Closing the connection control stream or any message control		o Closing the connection control stream or any message control
	stream is a fatal error (#176)		stream is a fatal error (#176)
	o HPACK Sequence counter can wrap (#173)		o HPACK Sequence counter can wrap (#173)
	o 0-RTT guidance added		o 0-RTT guidance added
	o Guide to differences from HTTP/2 and porting HTTP/2 extensions		o Guide to differences from HTTP/2 and porting HTTP/2 extensions
	added (#127,#242)		added (#127,#242)
	B.19. Since draft-ietf-quic-http-00		B.20. Since draft-ietf-quic-http-00
	o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)		o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
	o Changed from using HTTP/2 framing within Stream 3 to new framing		o Changed from using HTTP/2 framing within Stream 3 to new framing
	format and two-stream-per-request model (#71,#72,#73)		format and two-stream-per-request model (#71,#72,#73)
	o Adopted SETTINGS format from draft-bishop-httpbis-extended-		o Adopted SETTINGS format from draft-bishop-httpbis-extended-
	settings-01		settings-01
	o Reworked SETTINGS_ACK to account for indeterminate inter-stream		o Reworked SETTINGS_ACK to account for indeterminate inter-stream
	skipping to change at page 53, line 21 ¶		skipping to change at page 55, line 4 ¶
	o Changed from using HTTP/2 framing within Stream 3 to new framing		o Changed from using HTTP/2 framing within Stream 3 to new framing
	format and two-stream-per-request model (#71,#72,#73)		format and two-stream-per-request model (#71,#72,#73)
	o Adopted SETTINGS format from draft-bishop-httpbis-extended-		o Adopted SETTINGS format from draft-bishop-httpbis-extended-
	settings-01		settings-01
	o Reworked SETTINGS_ACK to account for indeterminate inter-stream		o Reworked SETTINGS_ACK to account for indeterminate inter-stream
	order (#75)		order (#75)
	o Described CONNECT pseudo-method (#95)		o Described CONNECT pseudo-method (#95)
	o Updated ALPN token and Alt-Svc guidance (#13,#87)		o Updated ALPN token and Alt-Svc guidance (#13,#87)
	o Application-layer-defined error codes (#19,#74)		o Application-layer-defined error codes (#19,#74)
	B.20. Since draft-shade-quic-http2-mapping-00		B.21. Since draft-shade-quic-http2-mapping-00
	o Adopted as base for draft-ietf-quic-http		o Adopted as base for draft-ietf-quic-http
	o Updated authors/editors list		o Updated authors/editors list
	Acknowledgements		Acknowledgements
	The original authors of this specification were Robbie Shade and Mike		The original authors of this specification were Robbie Shade and Mike
	Warres.		Warres.
End of changes. 47 change blocks.
	124 lines changed or deleted		161 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/