draft-ietf-quic-http-18.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 January 23, 2019		Intended status: Standards Track February 19, 2019
	Expires: July 27, 2019		Expires: August 23, 2019
	Hypertext Transfer Protocol Version 3 (HTTP/3)		Hypertext Transfer Protocol Version 3 (HTTP/3)
	draft-ietf-quic-http-18		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 July 27, 2019.		This Internet-Draft will expire on August 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 36 ¶		skipping to change at page 2, line 36 ¶
	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 . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . 10
	4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10		4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 11		4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12
	4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11		4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 12
	4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 11		4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 12		4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 13
	4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 12		4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 13
	4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 15		4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16
	4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 16		4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 17
	4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18		4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19
	4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 18		4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20
	4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 19		4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 20
	4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 20		4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 21
	4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 21		4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 22
	5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 21		5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 22
	5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 21		5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 22
	5.1.1. Header Formatting and Compression . . . . . . . . . . 22		5.1.1. Header Formatting and Compression . . . . . . . . . . 24
	5.1.2. Request Cancellation and Rejection . . . . . . . . . 23		5.1.2. Request Cancellation and Rejection . . . . . . . . . 24
	5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 24		5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 25
	5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 25		5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 26
	5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 26		5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 27
	5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 26		5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 27
	5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 27		5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 28
	6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 28		6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 29
	6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 28		6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 30
	6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 29		6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 30
	6.3. Immediate Application Closure . . . . . . . . . . . . . . 30		6.3. Immediate Application Closure . . . . . . . . . . . . . . 31
	6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 30		6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 32
	7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 31		7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 32
	8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31		8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
	8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 32		8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 33
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 33		9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	10.1. Registration of HTTP/3 Identification String . . . . . . 34		10.1. Registration of HTTP/3 Identification String . . . . . . 35
	10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 34		10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 36
	10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 34		10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 36
	10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 36		10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 37
	10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 37		10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 38
	10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 39		10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 41
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
	11.1. Normative References . . . . . . . . . . . . . . . . . . 40		11.1. Normative References . . . . . . . . . . . . . . . . . . 42
	11.2. Informative References . . . . . . . . . . . . . . . . . 41		11.2. Informative References . . . . . . . . . . . . . . . . . 43
	11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42		11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	Appendix A. Considerations for Transitioning from HTTP/2 . . . . 42		Appendix A. Considerations for Transitioning from HTTP/2 . . . . 43
	A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 42		A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 44
	A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 42		A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 44
	A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 45		A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 46
	A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 45		A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 47
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 48
	B.1. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 47		B.1. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 48
	B.2. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 47		B.2. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 48
	B.3. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 47		B.3. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 49
	B.4. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 47		B.4. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 49
	B.5. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 48		B.5. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 49
	B.6. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 48		B.6. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 50
	B.7. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 48		B.7. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 50
	B.8. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 48		B.8. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 50
	B.9. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 49		B.9. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 50
	B.10. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 49		B.10. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 50
	B.11. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 49		B.11. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 50
	B.12. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 49		B.12. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 51
	B.13. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 49		B.13. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 51
	B.14. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 49		B.14. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 51
	B.15. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 50		B.15. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 51
	B.16. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 50		B.16. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 51
	B.17. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 50		B.17. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 51
	B.18. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 50		B.18. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 52
	B.19. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 51		B.19. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 52
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
	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 8, line 43 ¶		skipping to change at page 8, line 43 ¶
	abruptly may be reset at any point in the frame.		abruptly may be reset at any point in the frame.
	HTTP/3 does not use server-initiated bidirectional streams; clients		HTTP/3 does not use server-initiated bidirectional streams; clients
	MUST omit or specify a value of zero for the QUIC transport parameter		MUST omit or specify a value of zero for the QUIC transport parameter
	"initial_max_bidi_streams".		"initial_max_bidi_streams".
	3.2. Unidirectional Streams		3.2. Unidirectional Streams
	Unidirectional streams, in either direction, are used for a range of		Unidirectional streams, in either direction, are used for a range of
	purposes. The purpose is indicated by a stream type, which is sent		purposes. The purpose is indicated by a stream type, which is sent
	as a single byte header at the start of the stream. The format and		as a variable-length integer at the start of the stream. The format
	structure of data that follows this header is determined by the		and structure of data that follows this integer is determined by the
	stream type.		stream type.
	0 1 2 3 4 5 6 7		0 1 2 3
	+-+-+-+-+-+-+-+-+		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	|Stream Type (8)|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	+-+-+-+-+-+-+-+-+		| 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		Both clients and servers SHOULD send a value of three or greater for
	the QUIC transport parameter "initial_max_uni_streams".		the QUIC transport parameter "initial_max_uni_streams".
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 40 ¶
	semantics of existing protocol components, including QPACK or other		semantics of existing protocol components, including QPACK or other
	extensions, MUST NOT be sent until the peer is known to support them.		extensions, MUST NOT be sent until the peer is known to support them.
	A sender can close or reset a unidirectional stream unless otherwise		A sender can close or reset a unidirectional stream unless otherwise
	specified. A receiver MUST tolerate unidirectional streams being		specified. A receiver MUST tolerate unidirectional streams being
	closed or reset prior to the reception of the unidirectional stream		closed or reset prior to the reception of the unidirectional stream
	header.		header.
	3.2.1. Control Streams		3.2.1. Control Streams
	A control stream is indicated by a stream type of "0x43" (ASCII 'C').		A control stream is indicated by a stream type of "0x00". Data on
	Data on this stream consists of HTTP/3 frames, as defined in		this stream consists of HTTP/3 frames, as defined in Section 4.2.
	Section 4.2.
	Each side MUST initiate a single control stream at the beginning of		Each side MUST initiate a single control stream at the beginning of
	the connection and send its SETTINGS frame as the first frame on this		the connection and send its SETTINGS frame as the first frame on this
	stream. If the first frame of the control stream is any other frame		stream. If the first frame of the control stream is any other frame
	type, this MUST be treated as a connection error of type		type, this MUST be treated as a connection error of type
	HTTP_MISSING_SETTINGS. Only one control stream per peer is		HTTP_MISSING_SETTINGS. Only one control stream per peer is
	permitted; receipt of a second stream which claims to be a control		permitted; receipt of a second stream which claims to be a control
	stream MUST be treated as a connection error of type		stream MUST be treated as a connection error of type
	HTTP_WRONG_STREAM_COUNT. The sender MUST NOT close the control		HTTP_WRONG_STREAM_COUNT. The sender MUST NOT close the control
	stream. If the control stream is closed at any point, this MUST be		stream. If the control stream is closed at any point, this MUST be
	treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.		treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.
	A pair of unidirectional streams is used rather than a single		A pair of unidirectional streams is used rather than a single
	bidirectional stream. This allows either peer to send data as soon		bidirectional stream. This allows either peer to send data as soon
	they are able. Depending on whether 0-RTT is enabled on the		they are able. Depending on whether 0-RTT is enabled on the
	connection, either client or server might be able to send stream data		connection, either client or server might be able to send stream data
	first after the cryptographic handshake completes.		first after the cryptographic handshake completes.
	3.2.2. Push Streams		3.2.2. Push Streams
	A push stream is indicated by a stream type of "0x50" (ASCII 'P'),		A push stream is indicated by a stream type of "0x01", followed by
	followed by the Push ID of the promise that it fulfills, encoded as a		the Push ID of the promise that it fulfills, encoded as a variable-
	variable-length integer. The remaining data on this stream consists		length integer. The remaining data on this stream consists of HTTP/3
	of HTTP/3 frames, as defined in Section 4.2, and fulfills a promised		frames, as defined in Section 4.2, and fulfills a promised server
	server push. Server push and Push IDs are described in Section 5.4.		push. Server push and Push IDs are described in Section 5.4.
	Only servers can push; if a server receives a client-initiated push		Only servers can push; if a server receives a client-initiated push
	stream, this MUST be treated as a stream error of type		stream, this MUST be treated as a stream error of type
	HTTP_WRONG_STREAM_DIRECTION.		HTTP_WRONG_STREAM_DIRECTION.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Stream Type (8)| Push ID (i) ...		| 0x01 (i) ...
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Push ID (i) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Push Stream Header		Figure 2: Push Stream Header
	Each Push ID MUST only be used once in a push stream header. If a		Each Push ID MUST only be used once in a push stream header. If a
	push stream header includes a Push ID that was used in another push		push stream header includes a Push ID that was used in another push
	stream header, the client MUST treat this as a connection error of		stream header, the client MUST treat this as a connection error of
	type HTTP_DUPLICATE_PUSH.		type HTTP_DUPLICATE_PUSH.
	3.2.3. Reserved Stream Types		3.2.3. Reserved Stream Types
	Stream types of the format "0x1f * N" are reserved to exercise the		Stream types of the format "0x1f * N + 0x21" for integer values of N
	requirement that unknown types be ignored. These streams have no		are reserved to exercise the requirement that unknown types be
	semantic meaning, and can be sent when application-layer padding is		ignored. These streams have no semantics, and can be sent when
	desired. They MAY also be sent on connections where no request data		application-layer padding is desired. They MAY also be sent on
	is currently being transferred. Endpoints MUST NOT consider these		connections where no data is currently being transferred. Endpoints
	streams to have any meaning upon receipt.		MUST NOT consider these streams to have any meaning upon receipt.
	The payload and length of the stream are selected in any manner the		The payload and length of the stream are selected in any manner the
	implementation chooses.		implementation chooses.
	4. HTTP Framing Layer		4. HTTP Framing Layer
	As discussed above, frames are carried on QUIC streams and used on		HTTP frames are carried on QUIC streams, as described in Section 3.
	control streams, request streams, and push streams. This section		HTTP/3 defines three stream types: control stream, request stream,
	describes HTTP framing in QUIC. For a comparison with HTTP/2 frames,		and push stream. This section describes HTTP/3 frame formats and the
	see Appendix A.2.		streams types on which they are permitted; see Table 1 for an
			overiew. A comparison between HTTP/2 and HTTP/3 frames is provided
			in Appendix A.2.
			+----------------+------------+------------+-----------+------------+
			| Frame | Control | Request | Push | Section |
			| | Stream | Stream | Stream | |
			+----------------+------------+------------+-----------+------------+
			| DATA | No | Yes | Yes | Section |
			| | | | | 4.2.1 |
			| | | | | |
			| HEADERS | No | Yes | Yes | Section |
			| | | | | 4.2.2 |
			| | | | | |
			| PRIORITY | Yes | Yes (1) | No | Section |
			| | | | | 4.2.3 |
			| | | | | |
			| CANCEL_PUSH | Yes | No | No | Section |
			| | | | | 4.2.4 |
			| | | | | |
			| SETTINGS | Yes (1) | No | No | Section |
			| | | | | 4.2.5 |
			| | | | | |
			| PUSH_PROMISE | No | Yes | No | Section |
			| | | | | 4.2.6 |
			| | | | | |
			| GOAWAY | Yes | No | No | Section |
			| | | | | 4.2.7 |
			| | | | | |
			| MAX_PUSH_ID | Yes | No | No | Section |
			| | | | | 4.2.8 |
			| | | | | |
			| DUPLICATE_PUSH | No | Yes | No | Section |
			| | | | | 4.2.9 |
			+----------------+------------+------------+-----------+------------+
			Table 1: HTTP/3 frames and stream type overview
			Certain frames can only occur as the first frame of a particular
			stream type; these are indicated in Table 1 with a (1). Specific
			guidance is provided in the relevant section.
	4.1. Frame Layout		4.1. Frame Layout
	All frames have the following format:		All frames have the following format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length (i) ...		| Type (i) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (8) | Frame Payload (*) ...		| Length (i) ...
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Frame Payload (*) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: HTTP/3 frame format		Figure 3: HTTP/3 frame format
	A frame includes the following fields:		A frame includes the following fields:
	Length: A variable-length integer that describes the length of the		Type: A variable-length integer that identifies the frame type.
	Frame Payload. This length does not include the Type field.
	Type: An 8-bit type for the frame.		Length: A variable-length integer that describes the length of the
			Frame Payload.
	Frame Payload: A payload, the semantics of which are determined by		Frame Payload: A payload, the semantics of which are determined by
	the Type field.		the Type field.
	Each frame's payload MUST contain exactly the fields identified in		Each frame's payload MUST contain exactly the fields identified in
	its description. A frame payload that contains additional bytes		its description. A frame payload that contains additional bytes
	after the identified fields or a frame payload that terminates before		after the identified fields or a frame payload that terminates before
	the end of the identified fields MUST be treated as a connection		the end of the identified fields MUST be treated as a connection
	error of type HTTP_MALFORMED_FRAME.		error of type HTTP_MALFORMED_FRAME.
	skipping to change at page 13, line 20 ¶		skipping to change at page 14, line 20 ¶
	| [Element Dependency ID (i)] ...		| [Element Dependency ID (i)] ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Weight (8) |		| Weight (8) |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 6: PRIORITY frame payload		Figure 6: PRIORITY frame payload
	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 1). 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 2).		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 MUST be
	ignored on receipt.		ignored 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.
	skipping to change at page 13, line 47 ¶		skipping to change at page 14, line 47 ¶
	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
	request stream, the Push ID of a promised resource, the		request stream, the Push ID of a promised resource, the
	Placeholder ID of a placeholder, or is absent. For details of		Placeholder ID of a placeholder, or is absent. For details of
	dependencies, see Section 5.3 and [RFC7540], Section 5.3.		dependencies, see Section 5.3 and [RFC7540], Section 5.3.
	Weight: An unsigned 8-bit integer representing a priority weight for		Weight: An unsigned 8-bit integer representing a priority weight for
	the prioritized element (see [RFC7540], Section 5.3). Add one to		the prioritized element (see [RFC7540], Section 5.3). Add one to
	the value to obtain a weight between 1 and 256.		the value to obtain a weight between 1 and 256.
	The values for the Prioritized Element Type (Table 1) and Element		The values for the Prioritized Element Type (Table 2) and Element
	Dependency Type (Table 2) imply the interpretation of the associated		Dependency Type (Table 3) imply the interpretation of the associated
	Element ID fields.		Element ID fields.
	+---------+------------------+---------------------------------+		+---------+------------------+---------------------------------+
	| PT Bits | Type Description | Prioritized Element ID Contents |		| PT Bits | Type Description | Prioritized Element ID Contents |
	+---------+------------------+---------------------------------+		+---------+------------------+---------------------------------+
	| 00 | Request stream | Stream ID |		| 00 | Request stream | Stream ID |
	| | | |		| | | |
	| 01 | Push stream | Push ID |		| 01 | Push stream | Push ID |
	| | | |		| | | |
	| 10 | Placeholder | Placeholder ID |		| 10 | Placeholder | Placeholder ID |
	| | | |		| | | |
	| 11 | Current stream | Absent |		| 11 | Current stream | Absent |
	+---------+------------------+---------------------------------+		+---------+------------------+---------------------------------+
	Table 1: Prioritized Element Types		Table 2: Prioritized Element Types
	+---------+------------------+--------------------------------+		+---------+------------------+--------------------------------+
	| DT Bits | Type Description | Element Dependency ID Contents |		| DT Bits | Type Description | Element Dependency ID Contents |
	+---------+------------------+--------------------------------+		+---------+------------------+--------------------------------+
	| 00 | Request stream | Stream ID |		| 00 | Request stream | Stream ID |
	| | | |		| | | |
	| 01 | Push stream | Push ID |		| 01 | Push stream | Push ID |
	| | | |		| | | |
	| 10 | Placeholder | Placeholder ID |		| 10 | Placeholder | Placeholder ID |
	| | | |		| | | |
	| 11 | Root of the tree | Absent |		| 11 | Root of the tree | Absent |
	+---------+------------------+--------------------------------+		+---------+------------------+--------------------------------+
	Table 2: Element Dependency Types		Table 3: Element Dependency Types
	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
	skipping to change at page 16, line 39 ¶		skipping to change at page 17, line 39 ¶
	provide a mechanism to identify when the choice takes effect.		provide a mechanism to identify when the choice takes effect.
	Different values for the same parameter can be advertised by each		Different values for the same parameter can be advertised by each
	peer. For example, a client might be willing to consume a very large		peer. For example, a client might be willing to consume a very large
	response header, while servers are more cautious about request size.		response header, while servers are more cautious about request size.
	Parameters MUST NOT occur more than once in the SETTINGS frame. A		Parameters MUST NOT occur more than once in the SETTINGS frame. A
	receiver MAY treat the presence of the same parameter more than once		receiver MAY treat the presence of the same parameter more than once
	as a connection error of type HTTP_MALFORMED_FRAME.		as a connection error of type HTTP_MALFORMED_FRAME.
	The payload of a SETTINGS frame consists of zero or more parameters,		The payload of a SETTINGS frame consists of zero or more parameters.
	each consisting of an unsigned 16-bit setting identifier and a value		Each parameter consists of a setting identifier and a value, both
	which uses the QUIC variable-length integer encoding.		encoded as QUIC variable-length integers.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier (16) | Value (i) ...		| Identifier (i) ...
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Value (i) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 8: SETTINGS parameter format		Figure 8: SETTINGS parameter format
	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 (0x8): 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 "0x?a?a" are reserved to exercise		Setting identifiers of the format "0x1f * N + 0x21" for integer
	the requirement that unknown identifiers be ignored. Such settings		values of N are reserved to exercise the requirement that unknown
	have no defined meaning. Endpoints SHOULD include at least one such		identifiers be ignored. Such settings have no defined meaning.
	setting in their SETTINGS frame. Endpoints MUST NOT consider such		Endpoints SHOULD include at least one such setting in their SETTINGS
	settings to have any meaning upon receipt.		frame. Endpoints MUST NOT consider such settings to have any meaning
			upon receipt.
	Because the setting has no defined meaning, the value of the setting		Because the setting has no defined meaning, the value of the setting
	can be any value the implementation selects.		can be any value the implementation selects.
	Additional settings can be defined by extensions to HTTP/3; see		Additional settings can be defined by extensions to HTTP/3; see
	Section 7 for more details.		Section 7 for more details.
	4.2.5.2. Initialization		4.2.5.2. Initialization
	An HTTP implementation MUST NOT send frames or requests which would		An HTTP implementation MUST NOT send frames or requests which would
	skipping to change at page 21, line 15 ¶		skipping to change at page 22, line 25 ¶
	Allowing duplicate references to the same Push ID is primarily to		Allowing duplicate references to the same Push ID is primarily to
	reduce duplication caused by concurrent requests. A server SHOULD		reduce duplication caused by concurrent requests. A server SHOULD
	avoid reusing a Push ID over a long period. Clients are likely to		avoid reusing a Push ID over a long period. Clients are likely to
	consume server push responses and not retain them for reuse over		consume server push responses and not retain them for reuse over
	time. Clients that see a DUPLICATE_PUSH that uses a Push ID that		time. Clients that see a DUPLICATE_PUSH that uses a Push ID that
	they have since consumed and discarded are forced to ignore the		they have since consumed and discarded are forced to ignore the
	DUPLICATE_PUSH.		DUPLICATE_PUSH.
	4.2.10. Reserved Frame Types		4.2.10. Reserved Frame Types
	Frame types of the format "0xb + (0x1f * N)" are reserved to exercise		Frame types of the format "0x1f * N + 0x21" for integer values of N
	the requirement that unknown types be ignored (Section 7). These		are reserved to exercise the requirement that unknown types be
	frames have no semantic value, and can be sent when application-layer		ignored (Section 7). These frames have no semantics, and can be sent
	padding is desired. They MAY also be sent on connections where no		when application-layer padding is desired. They MAY also be sent on
	request data is currently being transferred. Endpoints MUST NOT		connections where no data is currently being transferred. Endpoints
	consider these frames to have any meaning upon receipt.		MUST NOT consider these frames to have any meaning upon receipt.
	The payload and length of the frames are selected in any manner the		The payload and length of the frames are selected in any manner the
	implementation chooses.		implementation chooses.
	5. HTTP Request Lifecycle		5. HTTP Request Lifecycle
	5.1. HTTP Message Exchanges		5.1. HTTP Message Exchanges
	A client sends an HTTP request on a client-initiated bidirectional		A client sends an HTTP request on a client-initiated bidirectional
	QUIC stream. A client MUST send only a single request on a given		QUIC stream. A client MUST send only a single request on a given
	skipping to change at page 23, line 48 ¶		skipping to change at page 25, line 13 ¶
	a stream.		a stream.
	When the server rejects a request without performing any application		When the server rejects a request without performing any application
	processing, it SHOULD abort its response stream with the error code		processing, it SHOULD abort its response stream with the error code
	HTTP_REQUEST_REJECTED. In this context, "processed" means that some		HTTP_REQUEST_REJECTED. In this context, "processed" means that some
	data from the stream was passed to some higher layer of software that		data from the stream was passed to some higher layer of software that
	might have taken some action as a result. The client can treat		might have taken some action as a result. The client can treat
	requests rejected by the server as though they had never been sent at		requests rejected by the server as though they had never been sent at
	all, thereby allowing them to be retried later on a new connection.		all, thereby allowing them to be retried later on a new connection.
	Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for		Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for
	requests which were partially or fully processed. When a client		requests which were partially or fully processed. When a server
	sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a server MAY		abandons a response after partial processing, it SHOULD abort its
	indicate the error code HTTP_REQUEST_REJECTED in the corresponding		response stream with the error code HTTP_REQUEST_CANCELLED.
	RESET_STREAM if no processing was performed. Clients MUST NOT reset
	streams with the HTTP_REQUEST_REJECTED error code except in response		When a client sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a
	to a QUIC STOP_SENDING frame.		server MAY send the error code HTTP_REQUEST_REJECTED in the
			corresponding RESET_STREAM if no processing was performed. Clients
			MUST NOT reset streams with the HTTP_REQUEST_REJECTED error code
			except in response to a QUIC STOP_SENDING frame that contains the
			same code.
	If a stream is cancelled after receiving a complete response, the		If a stream is cancelled after receiving a complete response, the
	client MAY ignore the cancellation and use the response. However, if		client MAY ignore the cancellation and use the response. However, if
	a stream is cancelled after receiving a partial response, the		a stream is cancelled after receiving a partial response, the
	response SHOULD NOT be used. Automatically retrying such requests is		response SHOULD NOT be used. Automatically retrying such requests is
	not possible, unless this is otherwise permitted (e.g., idempotent		not possible, unless this is otherwise permitted (e.g., idempotent
	actions like GET, PUT, or DELETE).		actions like GET, PUT, or DELETE).
	5.2. The CONNECT Method		5.2. The CONNECT Method
	skipping to change at page 25, line 44 ¶		skipping to change at page 27, line 14 ¶
	Due to reordering between streams, an element can also be prioritized		Due to reordering between streams, an element can also be prioritized
	which is not yet in the tree. Such elements are added to the tree		which is not yet in the tree. Such elements are added to the tree
	with the requested priority.		with the requested priority.
	When a prioritized element is first created, it has a default initial		When a prioritized element is first created, it has a default initial
	weight of 16 and a default dependency. Requests and placeholders are		weight of 16 and a default dependency. Requests and placeholders are
	dependent on the root of the priority tree; pushes are dependent on		dependent on the root of the priority tree; pushes are dependent on
	the client request on which the PUSH_PROMISE frame was sent.		the client request on which the PUSH_PROMISE frame was sent.
	Requests may override the default intial values by including a		Requests may override the default initial values by including a
	PRIORTIY frame (see Section 4.2.3) at the beginning of the stream.		PRIORTIY frame (see Section 4.2.3) at the beginning of the stream.
	These priorities can be updated by sending a PRIORITY frame on the		These priorities can be updated by sending a PRIORITY frame on the
	control stream.		control stream.
	5.3.1. Placeholders		5.3.1. Placeholders
	In HTTP/2, certain implementations used closed or unused streams as		In HTTP/2, certain implementations used closed or unused streams as
	placeholders in describing the relative priority of requests. This		placeholders in describing the relative priority of requests. This
	created confusion as servers could not reliably identify which		created confusion as servers could not reliably identify which
	elements of the priority tree could be discarded safely. Clients		elements of the priority tree could be discarded safely. Clients
	skipping to change at page 32, line 31 ¶		skipping to change at page 33, line 45 ¶
	HTTP_PUSH_REFUSED (0x02): The server has attempted to push content		HTTP_PUSH_REFUSED (0x02): The server has attempted to push content
	which the client will not accept on this connection.		which the client will not accept on this connection.
	HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the		HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the
	HTTP stack.		HTTP stack.
	HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push		HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push
	content which the client has cached.		content which the client has cached.
	HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the		HTTP_REQUEST_CANCELLED (0x05): The request or its response is
	requested data.		cancelled.
	HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated		HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated
	without containing a fully-formed request.		without containing a fully-formed request.
	HTTP_CONNECT_ERROR (0x07): The connection established in response to		HTTP_CONNECT_ERROR (0x07): The connection established in response to
	a CONNECT request was reset or abnormally closed.		a CONNECT request was reset or abnormally closed.
	HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is		HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is
	exhibiting a behavior that might be generating excessive load.		exhibiting a behavior that might be generating excessive load.
	skipping to change at page 33, line 38 ¶		skipping to change at page 34, line 51 ¶
	permitted in the current state.		permitted in the current state.
	HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without		HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without
	performing any application processing.		performing any application processing.
	HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol		HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol
	requirements in a way which doesn't match a more specific error		requirements in a way which doesn't match a more specific error
	code, or endpoint declines to use the more specific error code.		code, or endpoint declines to use the more specific error code.
	HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type.		HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type.
	The frame type is included as the last byte of the error code.		If the frame type is "0xfe" or less, the type is included as the
	For example, an error in a MAX_PUSH_ID frame would be indicated		last byte of the error code. For example, an error in a
	with the code (0x10D).		MAX_PUSH_ID frame would be indicated with the code (0x10D). The
			last byte "0xff" is used to indicate any frame type greater than
			"0xfe".
	9. Security Considerations		9. Security Considerations
	The security considerations of HTTP/3 should be comparable to those		The security considerations of HTTP/3 should be comparable to those
	of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames		of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames
	and Padding fields in other frames to make a connection more		and Padding fields in other frames to make a connection more
	resistant to traffic analysis, HTTP/3 can rely on QUIC PADDING frames		resistant to traffic analysis, HTTP/3 can rely on QUIC PADDING frames
	or employ the reserved frame and stream types discussed in		or employ the reserved frame and stream types discussed in
	Section 4.2.10 and Section 3.2.3.		Section 4.2.10 and Section 3.2.3.
	When HTTP Alternative Services is used for discovery for HTTP/3		When HTTP Alternative Services is used for discovery for HTTP/3
	endpoints, the security considerations of [ALTSVC] also apply.		endpoints, the security considerations of [ALTSVC] also apply.
	Several protocol elements contain nested length elements, typically		Several protocol elements contain nested length elements, typically
	in the form of frames with an explicit length containing variable-		in the form of frames with an explicit length containing variable-
	length integers. This could pose a security risk to an incautious		length integers. This could pose a security risk to an incautious
	implementer. An implementation MUST ensure that the length of a		implementer. An implementation MUST ensure that the length of a
	frame exactly matches the length of the fields it contains.		frame exactly matches the length of the fields it contains.
			Certain HTTP implementations use the client address for logging or
			access-control purposes. Since a QUIC client's address might change
			during a connection (and future versions might support simultaneous
			use of multiple addresses), such implementations will need to either
			actively retrieve the client's current address or addresses when they
			are relevant or explicitly accept that the original address might
			change.
	10. IANA Considerations		10. IANA Considerations
	10.1. Registration of HTTP/3 Identification String		10.1. Registration of HTTP/3 Identification String
	This document creates a new registration for the identification of		This document creates a new registration for the identification of
	HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol		HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol
	IDs" registry established in [RFC7301].		IDs" registry established in [RFC7301].
	The "h3" string identifies HTTP/3:		The "h3" string identifies HTTP/3:
	skipping to change at page 34, line 40 ¶		skipping to change at page 36, line 18 ¶
	hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter"		hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter"
	registry established in [RFC7838].		registry established in [RFC7838].
	Parameter: "quic"		Parameter: "quic"
	Specification: This document, Section 2.2.1		Specification: This document, Section 2.2.1
	10.3. Frame Types		10.3. Frame Types
	This document establishes a registry for HTTP/3 frame type codes.		This document establishes a registry for HTTP/3 frame type codes.
	The "HTTP/3 Frame Type" registry manages an 8-bit space. The "HTTP/3		The "HTTP/3 Frame Type" registry governs a 62-bit space. This space
	Frame Type" registry operates under either of the "IETF Review" or		is split into three spaces that are governed by different policies.
	"IESG Approval" policies [RFC8126] for values from 0x00 up to and		Values between "0x00" and "0x3f" (in hexadecimal) are assigned via
	including 0xef, with values from 0xf0 up to and including 0xff being		the Standards Action or IESG Review policies [RFC8126]. Values from
	reserved for Experimental Use.		"0x40" to "0x3fff" operate on the Specification Required policy
			[RFC8126]. All other values are assigned to Private Use [RFC8126].
	While this registry is separate from the "HTTP/2 Frame Type" registry		While this registry is separate from the "HTTP/2 Frame Type" registry
	defined in [RFC7540], it is preferable that the assignments parallel		defined in [RFC7540], it is preferable that the assignments parallel
	each other. If an entry is present in only one registry, every		each other where the code spaces overlap. If an entry is present in
	effort SHOULD be made to avoid assigning the corresponding value to		only one registry, every effort SHOULD be made to avoid assigning the
	an unrelated operation.		corresponding value to an unrelated operation.
	New entries in this registry require the following information:		New entries in this registry require the following information:
	Frame Type: A name or label for the frame type.		Frame Type: A name or label for the frame type.
	Code: The 8-bit code assigned to the frame type.		Code: The 62-bit code assigned to the frame type.
	Specification: A reference to a specification that includes a		Specification: A reference to a specification that includes a
	description of the frame layout and its semantics, including any		description of the frame layout and its semantics, including any
	parts of the frame that are conditionally present.		parts of the frame that are conditionally present.
	The entries in the following table are registered by this document.		The entries in the following table are registered by this document.
	+----------------+------+----------------+		+----------------+------+----------------+
	| Frame Type | Code | Specification |		| Frame Type | Code | Specification |
	+----------------+------+----------------+		+----------------+------+----------------+
	skipping to change at page 35, line 43 ¶		skipping to change at page 37, line 33 ¶
	| | | |		| | | |
	| Reserved | 0x8 | N/A |		| Reserved | 0x8 | N/A |
	| | | |		| | | |
	| 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 "0xb + (0x1f * N)" for values		Additionally, each code of the format "0x1f * N + 0x21" for integer
	of N in the range (0..7) (that is, "0xb", "0x2a", "0x49", "0x68",		values of N (that is, "0x21", "0x40", ..., through
	"0x87", "0xa6", "0xc5", and "0xe4"), the following values should be		"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.
	registered:
	Frame Type: Reserved - GREASE
	Specification: Section 4.2.10
	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 manages a 16-bit space. The "HTTP/3		"HTTP/3 Settings" registry governs a 62-bit space. This space is
	Settings" registry operates under the "Expert Review" policy		split into three spaces that are governed by different policies.
	[RFC8126] for values in the range from 0x0000 to 0xefff, with values		Values between "0x00" and "0x3f" (in hexadecimal) are assigned via
	between and 0xf000 and 0xffff being reserved for Experimental Use.		the Standards Action or IESG Review policies [RFC8126]. Values from
			"0x40" to "0x3fff" operate on the Specification Required policy
			[RFC8126]. All other values are assigned to Private Use [RFC8126].
	The designated experts are the same as those for the "HTTP/2		The designated experts are the same as those for the "HTTP/2
	Settings" registry defined in [RFC7540].		Settings" registry defined in [RFC7540].
	While this registry is separate from the "HTTP/2 Settings" registry		While this registry is separate from the "HTTP/2 Settings" registry
	defined in [RFC7540], it is preferable that the assignments parallel		defined in [RFC7540], it is preferable that the assignments parallel
	each other. If an entry is present in only one registry, every		each other. If an entry is present in only one registry, every
	effort SHOULD be made to avoid assigning the corresponding value to		effort SHOULD be made to avoid assigning the corresponding value to
	an unrelated operation.		an unrelated operation.
	New registrations are advised to provide the following information:		New registrations are advised to provide the following information:
	Name: A symbolic name for the setting. Specifying a setting name is		Name: A symbolic name for the setting. Specifying a setting name is
	optional.		optional.
	Code: The 16-bit code assigned to the setting.		Code: The 62-bit code assigned to the setting.
	Specification: An optional reference to a specification that		Specification: An optional reference to a specification that
	describes the use of the setting.		describes the use of the setting.
	The entries in the following table are registered by this document.		The entries in the following table are registered by this document.
	+----------------------+------+------------------+		+----------------------+------+------------------+
	| Setting Name | Code | Specification |		| Setting Name | Code | Specification |
	+----------------------+------+------------------+		+----------------------+------+------------------+
	| Reserved | 0x2 | N/A |		| Reserved | 0x2 | N/A |
	skipping to change at page 36, line 49 ¶		skipping to change at page 38, line 35 ¶
	| | | |		| | | |
	| 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 | 0x8 | Section 4.2.5.1 |
	+----------------------+------+------------------+		+----------------------+------+------------------+
	Additionally, each code of the format "0x?a?a" where each "?" is any		Additionally, each code of the format "0x1f * N + 0x21" for integer
	four bits (that is, "0x0a0a", "0x0a1a", etc. through "0xfafa"), the		values of N (that is, "0x21", "0x40", ..., through
	following values should be registered:		"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.
	Name: Reserved - GREASE
	Specification: Section 4.2.5.1
	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 39, line 36 ¶		skipping to change at page 41, line 18 ¶
	| | | processed | |		| | | processed | |
	| | | | |		| | | | |
	| HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 |		| HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 |
	| | | frame | |		| | | frame | |
	| | | formatting | |		| | | formatting | |
	+---------------------------+--------+---------------+--------------+		+---------------------------+--------+---------------+--------------+
	10.6. Stream Types		10.6. Stream Types
	This document establishes a registry for HTTP/3 unidirectional stream		This document establishes a registry for HTTP/3 unidirectional stream
	types. The "HTTP/3 Stream Type" registry manages an 8-bit space.		types. The "HTTP/3 Stream Type" registry governs a 62-bit space.
	The "HTTP/3 Stream Type" registry operates under either of the "IETF		This space is split into three spaces that are governed by different
	Review" or "IESG Approval" policies [RFC8126] for values from 0x00 up		policies. Values between "0x00" and 0x3f (in hexadecimal) are
	to and including 0xef, with values from 0xf0 up to and including 0xff		assigned via the Standards Action or IESG Review policies [RFC8126].
	being reserved for Experimental Use.		Values from "0x40" to "0x3fff" operate on the Specification Required
			policy [RFC8126]. All other values are assigned to Private Use
			[RFC8126].
	New entries in this registry require the following information:		New entries in this registry require the following information:
	Stream Type: A name or label for the stream type.		Stream Type: A name or label for the stream type.
	Code: The 8-bit code assigned to the stream type.		Code: The 62-bit code assigned to the stream type.
	Specification: A reference to a specification that includes a		Specification: A reference to a specification that includes a
	description of the stream type, including the layout semantics of		description of the stream type, including the layout semantics of
	its payload.		its payload.
	Sender: Which endpoint on a connection may initiate a stream of this		Sender: Which endpoint on a connection may initiate a stream of this
	type. Values are "Client", "Server", or "Both".		type. Values are "Client", "Server", or "Both".
	The entries in the following table are registered by this document.		The entries in the following table are registered by this document.
	+----------------+------+----------------+--------+		+----------------+------+----------------+--------+
	| Stream Type | Code | Specification | Sender |		| Stream Type | Code | Specification | Sender |
	+----------------+------+----------------+--------+		+----------------+------+----------------+--------+
	| Control Stream | 0x43 | Section 3.2.1 | Both |		| Control Stream | 0x00 | Section 3.2.1 | Both |
	| | | | |		| | | | |
	| Push Stream | 0x50 | Section 5.4 | Server |		| Push Stream | 0x01 | Section 5.4 | Server |
	+----------------+------+----------------+--------+		+----------------+------+----------------+--------+
	Additionally, for each code of the format "0x1f * N" for values of N		Additionally, each code of the format "0x1f * N + 0x21" for integer
	in the range (0..8) (that is, "0x00", "0x1f", "0x3e", "0x5d", "0x7c",		values of N (that is, "0x21", "0x40", ..., through
	"0x9b", "0xba", "0xd9", "0xf8"), the following values should be		"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.
	registered:
	Stream Type: Reserved - GREASE
	Specification: Section 3.2.3
	Sender: Both
	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>.
	[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-06 (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-18 (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 41, line 39 ¶		skipping to change at page 43, line 14 ¶
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,		DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/info/rfc7540>.		<https://www.rfc-editor.org/info/rfc7540>.
	[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP		[RFC7838] 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>.
			[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		11.2. Informative References
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
	July 2014, <https://www.rfc-editor.org/info/rfc7301>.		July 2014, <https://www.rfc-editor.org/info/rfc7301>.
	[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP		[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
	Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,		Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
	<https://www.rfc-editor.org/info/rfc7413>.		<https://www.rfc-editor.org/info/rfc7413>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.
	11.3. URIs		11.3. URIs
	[1] https://mailarchive.ietf.org/arch/search/?email_list=quic		[1] https://mailarchive.ietf.org/arch/search/?email_list=quic
	[2] https://github.com/quicwg		[2] https://github.com/quicwg
	[3] https://github.com/quicwg/base-drafts/labels/-http		[3] https://github.com/quicwg/base-drafts/labels/-http
	[4] https://www.iana.org/assignments/message-headers		[4] https://www.iana.org/assignments/message-headers
	skipping to change at page 44, line 49 ¶		skipping to change at page 46, line 26 ¶
	contain an error code. See Section 4.2.7.		contain an error code. See Section 4.2.7.
	WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC		WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC
	provides flow control.		provides flow control.
	CONTINUATION (0x9): CONTINUATION frames do not exist; instead,		CONTINUATION (0x9): CONTINUATION frames do not exist; instead,
	larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted.		larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted.
	Frame types defined by extensions to HTTP/2 need to be separately		Frame types defined by extensions to HTTP/2 need to be separately
	registered for HTTP/3 if still applicable. The IDs of frames defined		registered for HTTP/3 if still applicable. The IDs of frames defined
	in [RFC7540] have been reserved for simplicity. See Section 10.3.		in [RFC7540] have been reserved for simplicity. Note that the frame
			type space in HTTP/3 is substantially larger (62 bits versus 8 bits),
			so many HTTP/3 frame types have no equivalent HTTP/2 code points.
			See Section 10.3.
	A.3. HTTP/2 SETTINGS Parameters		A.3. HTTP/2 SETTINGS Parameters
	An important difference from HTTP/2 is that settings are sent once,		An important difference from HTTP/2 is that settings are sent once,
	at the beginning of the connection, and thereafter cannot change.		at the beginning of the connection, and thereafter cannot change.
	This eliminates many corner cases around synchronization of changes.		This eliminates many corner cases around synchronization of changes.
	Some transport-level options that HTTP/2 specifies via the SETTINGS		Some transport-level options that HTTP/2 specifies via the SETTINGS
	frame are superseded by QUIC transport parameters in HTTP/3. The		frame are superseded by QUIC transport parameters in HTTP/3. The
	HTTP-level options that are retained in HTTP/3 have the same value as		HTTP-level options that are retained in HTTP/3 have the same value as
	skipping to change at page 45, line 46 ¶		skipping to change at page 47, line 24 ¶
	In HTTP/3, setting values are variable-length integers (6, 14, 30, or		In HTTP/3, setting values are variable-length integers (6, 14, 30, or
	62 bits long) rather than fixed-length 32-bit fields as in HTTP/2.		62 bits long) rather than fixed-length 32-bit fields as in HTTP/2.
	This will often produce a shorter encoding, but can produce a longer		This will often produce a shorter encoding, but can produce a longer
	encoding for settings which use the full 32-bit space. Settings		encoding for settings which use the full 32-bit space. Settings
	ported from HTTP/2 might choose to redefine the format of their		ported from HTTP/2 might choose to redefine the format of their
	settings to avoid using the 62-bit encoding.		settings to avoid using the 62-bit encoding.
	Settings need to be defined separately for HTTP/2 and HTTP/3. The		Settings need to be defined separately for HTTP/2 and HTTP/3. The
	IDs of settings defined in [RFC7540] have been reserved for		IDs of settings defined in [RFC7540] have been reserved for
	simplicity. See Section 10.4.		simplicity. Note that the settings identifier space in HTTP/3 is
			substantially larger (62 bits versus 16 bits), so many HTTP/3
			settings have no equivalent HTTP/2 code point. See Section 10.4.
	A.4. HTTP/2 Error Codes		A.4. HTTP/2 Error Codes
	QUIC has the same concepts of "stream" and "connection" errors that		QUIC has the same concepts of "stream" and "connection" errors that
	HTTP/2 provides. However, there is no direct portability of HTTP/2		HTTP/2 provides. However, there is no direct portability of HTTP/2
	error codes.		error codes.
	The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the		The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the
	HTTP/3 error codes as follows:		HTTP/3 error codes as follows:
End of changes. 48 change blocks.
	192 lines changed or deleted		247 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/