draft-ietf-quic-http-23.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 September 12, 2019		Intended status: Standards Track October 19, 2019
	Expires: March 15, 2020		Expires: April 21, 2020
	Hypertext Transfer Protocol Version 3 (HTTP/3)		Hypertext Transfer Protocol Version 3 (HTTP/3)
	draft-ietf-quic-http-23		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 March 15, 2020.		This Internet-Draft will expire on April 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 4		1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 4
	1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5		1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 4
	2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 5		2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 5
	2.1. Document Organization . . . . . . . . . . . . . . . . . . 6		2.1. Document Organization . . . . . . . . . . . . . . . . . . 6
	2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6		2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6
	3. Connection Setup and Management . . . . . . . . . . . . . . . 8		3. Connection Setup and Management . . . . . . . . . . . . . . . 8
	3.1. Draft Version Identification . . . . . . . . . . . . . . 8		3.1. Draft Version Identification . . . . . . . . . . . . . . 8
	3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 8		3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 8
	3.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 9		3.3. Connection Establishment . . . . . . . . . . . . . . . . 9
	3.3. Connection Establishment . . . . . . . . . . . . . . . . 10		3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 9
	3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 10		4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 10
	4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 11		4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 10
	4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 11		4.1.1. Header Formatting and Compression . . . . . . . . . . 11
	4.1.1. Header Formatting and Compression . . . . . . . . . . 12
	4.1.2. Request Cancellation and Rejection . . . . . . . . . 13		4.1.2. Request Cancellation and Rejection . . . . . . . . . 13
	4.1.3. Malformed Requests and Responses . . . . . . . . . . 14		4.1.3. Malformed Requests and Responses . . . . . . . . . . 13
	4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 15		4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 14
	4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 16		4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 15
	4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 16		4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 15
	5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 17		5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 17
	5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 18		5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 17
	5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 18		5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 17
	5.3. Immediate Application Closure . . . . . . . . . . . . . . 19		5.3. Immediate Application Closure . . . . . . . . . . . . . . 19
	5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 20		5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 19
	6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 20		6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 19
	6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 20		6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 20
	6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 21		6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 20
	6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 22		6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 21
	6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 23		6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 22
	6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 23		6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 22
			7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 23
	7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 24
	7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 24		7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 24
	7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 25		7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 25
	7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 25		7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 25
	7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 26		7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 25
	7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 26		7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 25
	7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 27		7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 26
	7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 30		7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 29
	7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 31		7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 30
	7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 31		7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 31
	7.2.8. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 32		7.2.8. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 32
	7.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 33		7.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 33
	8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33		8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
	8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 34		8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 33
	9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 35		9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 35
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 36		10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 36		10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 36
	10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 36		10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 36
	10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 36		10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 36
	10.4. Migration . . . . . . . . . . . . . . . . . . . . . . . 37		10.4. Migration . . . . . . . . . . . . . . . . . . . . . . . 36
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	11.1. Registration of HTTP/3 Identification String . . . . . . 37		11.1. Registration of HTTP/3 Identification String . . . . . . 36
	11.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 37		11.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37
	11.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37		11.3. Settings Parameters . . . . . . . . . . . . . . . . . . 38
	11.4. Settings Parameters . . . . . . . . . . . . . . . . . . 39		11.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . 39
	11.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 40		11.5. Stream Types . . . . . . . . . . . . . . . . . . . . . . 41
	11.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 42		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43		12.1. Normative References . . . . . . . . . . . . . . . . . . 42
	12.1. Normative References . . . . . . . . . . . . . . . . . . 43
	12.2. Informative References . . . . . . . . . . . . . . . . . 44		12.2. Informative References . . . . . . . . . . . . . . . . . 44
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 44
	Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45		Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45
	A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45		A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45
	A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45		A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45
	A.2.1. Prioritization Differences . . . . . . . . . . . . . 46		A.2.1. Prioritization Differences . . . . . . . . . . . . . 46
	A.2.2. Header Compression Differences . . . . . . . . . . . 46		A.2.2. Header Compression Differences . . . . . . . . . . . 46
	A.2.3. Guidance for New Frame Type Definitions . . . . . . . 47		A.2.3. Guidance for New Frame Type Definitions . . . . . . . 46
	A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 47		A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 47
	A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48		A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48
	A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49		A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50
	B.1. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 50		B.1. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 50
	B.2. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 51		B.2. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 51
	B.3. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 51		B.3. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 51
	B.4. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 52		B.4. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 52
	B.5. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 52		B.5. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 52
	B.6. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 53		B.6. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 52
	B.7. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 53		B.7. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 52
	B.8. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 53		B.8. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 53
	B.9. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 53		B.9. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 53
	B.10. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 54		B.10. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 53
	B.11. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 54		B.11. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 54
	B.12. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 54		B.12. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 54
	B.13. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 54		B.13. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 54
	B.14. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 54		B.14. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 54
	B.15. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 55		B.15. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 54
	B.16. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 55		B.16. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 54
	B.17. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 55		B.17. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 55
	B.18. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 55		B.18. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 55
	B.19. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 55		B.19. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 55
	B.20. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 56		B.20. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 55
	B.21. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 56		B.21. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 55
	B.22. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 56		B.22. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 55
	B.23. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 56		B.23. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 56
	B.24. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 57		B.24. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 56
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 56
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57
	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/3 supports the same		TCP mappings, HTTP/1.1 and HTTP/2. HTTP/3 supports the same
	semantics over a new transport protocol, QUIC.		semantics over a new transport protocol, QUIC.
	1.1. Prior versions of HTTP		1.1. Prior versions of HTTP
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 13 ¶
	described in this document.		described in this document.
	Connectivity problems (e.g. firewall blocking UDP) can result in QUIC		Connectivity problems (e.g. firewall blocking UDP) can result in QUIC
	connection establishment failure, in which case the client SHOULD		connection establishment failure, in which case the client SHOULD
	continue using the existing connection or try another alternative		continue using the existing connection or try another alternative
	endpoint offered by the origin.		endpoint offered by the origin.
	Servers MAY serve HTTP/3 on any UDP port, since an alternative always		Servers MAY serve HTTP/3 on any UDP port, since an alternative always
	includes an explicit port.		includes an explicit port.
	3.2.1. QUIC Version Hints
	This document defines the "quic" parameter for Alt-Svc, which MAY be
	used to provide version-negotiation hints to HTTP/3 clients. QUIC
	versions are four-byte sequences with no additional constraints on
	format. Leading zeros SHOULD be omitted for brevity.
	Syntax:
	quic = DQUOTE version-number [ "," version-number ] * DQUOTE
	version-number = 1*8HEXDIG; hex-encoded QUIC version
	Where multiple versions are listed, the order of the values reflects
	the server's preference (with the first value being the most
	preferred version). Reserved versions MAY be listed, but unreserved
	versions which are not supported by the alternative SHOULD NOT be
	present in the list. Origins MAY omit supported versions for any
	reason.
	Clients MUST ignore any included versions which they do not support.
	The "quic" parameter MUST NOT occur more than once; clients SHOULD
	process only the first occurrence.
	For example, suppose a server supported both version 0x00000001 and
	the version rendered in ASCII as "Q034". If it also opted to include
	the reserved version (from Section 15 of [QUIC-TRANSPORT])
	0x1abadaba, it could specify the following header field:
	Alt-Svc: h3=":49288";quic="1,1abadaba,51303334"
	A client acting on this header field would drop the reserved version
	(not supported), then attempt to connect to the alternative using the
	first version in the list which it does support, if any.
	3.3. Connection Establishment		3.3. Connection Establishment
	HTTP/3 relies on QUIC as the underlying transport. The QUIC version		HTTP/3 relies on QUIC as the underlying transport. The QUIC version
	being used MUST use TLS version 1.3 or greater as its handshake		being used MUST use TLS version 1.3 or greater as its handshake
	protocol. HTTP/3 clients MUST indicate the target domain name during		protocol. HTTP/3 clients MUST indicate the target domain name during
	the TLS handshake. This may be done using the Server Name Indication		the TLS handshake. This may be done using the Server Name Indication
	(SNI) [RFC6066] extension to TLS or using some other mechanism.		(SNI) [RFC6066] extension to TLS or using some other mechanism.
	QUIC connections are established as described in [QUIC-TRANSPORT].		QUIC connections are established as described in [QUIC-TRANSPORT].
	During connection establishment, HTTP/3 support is indicated by		During connection establishment, HTTP/3 support is indicated by
	skipping to change at page 13, line 11 ¶		skipping to change at page 12, line 20 ¶
	to lowercase prior to their encoding. A request or response		to lowercase prior to their encoding. A request or response
	containing uppercase header field names MUST be treated as malformed		containing uppercase header field names MUST be treated as malformed
	(Section 4.1.3).		(Section 4.1.3).
	As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with		As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with
	the ':' character (ASCII 0x3a) to convey the target URI, the method		the ':' character (ASCII 0x3a) to convey the target URI, the method
	of the request, and the status code for the response. These pseudo-		of the request, and the status code for the response. These pseudo-
	header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2].		header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2].
	Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT		Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT
	generate pseudo-header fields other than those defined in [HTTP2].		generate pseudo-header fields other than those defined in [HTTP2].
	The restrictions on the use of pseudo-header fields in		The restrictions on the use of pseudo-header fields in Section 8.1.2
	Section 8.1.2.1 of [HTTP2] also apply to HTTP/3.		of [HTTP2] also apply to HTTP/3. Messages which are considered
			malformed under these restrictions are handled as described in
			Section 4.1.3.
	HTTP/3 uses QPACK header compression as described in [QPACK], a		HTTP/3 uses QPACK header compression as described in [QPACK], a
	variation of HPACK which allows the flexibility to avoid header-		variation of HPACK which allows the flexibility to avoid header-
	compression-induced head-of-line blocking. See that document for		compression-induced head-of-line blocking. See that document for
	additional details.		additional details.
	To allow for better compression efficiency, the cookie header field		To allow for better compression efficiency, the cookie header field
	[RFC6265] MAY be split into separate header fields, each with one or		[RFC6265] MAY be split into separate header fields, each with one or
	more cookie-pairs, before compression. If a decompressed header list		more cookie-pairs, before compression. If a decompressed header list
	contains multiple cookie header fields, these MUST be concatenated		contains multiple cookie header fields, these MUST be concatenated
	skipping to change at page 21, line 29 ¶		skipping to change at page 20, line 41 ¶
	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 (i) ...		| Stream Type (i) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Unidirectional Stream Header		Figure 1: Unidirectional Stream Header
	Some stream types are reserved (Section 6.2.3). Two stream types are		Some stream types are reserved (Section 6.2.3). Two stream types are
	defined in this document: control streams (Section 6.2.1) and push		defined in this document: control streams (Section 6.2.1) and push
	streams (Section 6.2.2). Other stream types can be defined by		streams (Section 6.2.2). [QPACK] defines two additional stream
	extensions to HTTP/3; see Section 9 for more details.		types. Other stream types can be defined by extensions to HTTP/3;
			see Section 9 for more details.
	The performance of HTTP/3 connections in the early phase of their		The performance of HTTP/3 connections in the early phase of their
	lifetime is sensitive to the creation and exchange of data on		lifetime is sensitive to the creation and exchange of data on
	unidirectional streams. Endpoints that excessively restrict the		unidirectional streams. Endpoints that excessively restrict the
	number of streams or the flow control window of these streams will		number of streams or the flow control window of these streams will
	increase the chance that the remote peer reaches the limit early and		increase the chance that the remote peer reaches the limit early and
	becomes blocked. In particular, implementations should consider that		becomes blocked. In particular, implementations should consider that
	remote peers may wish to exercise reserved stream behavior		remote peers may wish to exercise reserved stream behavior
	(Section 6.2.3) with some of the unidirectional streams they are		(Section 6.2.3) with some of the unidirectional streams they are
	permitted to use. To avoid blocking, the transport parameters sent		permitted to use. To avoid blocking, the transport parameters sent
	skipping to change at page 24, line 14 ¶		skipping to change at page 23, line 19 ¶
	7. HTTP Framing Layer		7. HTTP Framing Layer
	HTTP frames are carried on QUIC streams, as described in Section 6.		HTTP frames are carried on QUIC streams, as described in Section 6.
	HTTP/3 defines three stream types: control stream, request stream,		HTTP/3 defines three stream types: control stream, request stream,
	and push stream. This section describes HTTP/3 frame formats and the		and push stream. This section describes HTTP/3 frame formats and the
	streams types on which they are permitted; see Table 1 for an		streams types on which they are permitted; see Table 1 for an
	overview. A comparison between HTTP/2 and HTTP/3 frames is provided		overview. A comparison between HTTP/2 and HTTP/3 frames is provided
	in Appendix A.2.		in Appendix A.2.
	+----------------+---------+----------+---------+-------------------+		+----------------+------------+------------+-----------+------------+
	| Frame | Control | Request | Push | Section |		| Frame | Control | Request | Push | Section |
	| | Stream | Stream | Stream | |		| | Stream | Stream | Stream | |
	+----------------+---------+----------+---------+-------------------+		+----------------+------------+------------+-----------+------------+
	| DATA | No | Yes | Yes | Section 7.2.1 |		| DATA | No | Yes | Yes | Section 7. |
	| | | | | |		| | | | | 2.1 |
	| HEADERS | No | Yes | Yes | Section 7.2.2 |		| | | | | |
	| | | | | |		| HEADERS | No | Yes | Yes | Section 7. |
	| CANCEL_PUSH | Yes | No | No | Section 7.2.3 |		| | | | | 2.2 |
	| | | | | |		| | | | | |
	| SETTINGS | Yes (1) | No | No | Section 7.2.4 |		| CANCEL_PUSH | Yes | No | No | Section 7. |
	| | | | | |		| | | | | 2.3 |
	| PUSH_PROMISE | No | Yes | No | Section 7.2.5 |		| | | | | |
	| | | | | |		| SETTINGS | Yes (1) | No | No | Section 7. |
	| GOAWAY | Yes | No | No | Section 7.2.6 |		| | | | | 2.4 |
	| | | | | |		| | | | | |
	| MAX_PUSH_ID | Yes | No | No | Section 7.2.7 |		| PUSH_PROMISE | No | Yes | No | Section 7. |
	| | | | | |		| | | | | 2.5 |
	| DUPLICATE_PUSH | No | Yes | No | Section 7.2.8 |		| | | | | |
	| | | | | |		| GOAWAY | Yes | No | No | Section 7. |
	| Reserved | Yes | Yes | Yes | {{frame-reserved} |		| | | | | 2.6 |
	+----------------+---------+----------+---------+-------------------+		| | | | | |
			| MAX_PUSH_ID | Yes | No | No | Section 7. |
			| | | | | 2.7 |
			| | | | | |
			| DUPLICATE_PUSH | No | Yes | No | Section 7. |
			| | | | | 2.8 |
			| | | | | |
			| Reserved | Yes | Yes | Yes | Section 7. |
			| | | | | 2.9 |
			+----------------+------------+------------+-----------+------------+
	Table 1: HTTP/3 frames and stream type overview		Table 1: HTTP/3 frames and stream type overview
	Certain frames can only occur as the first frame of a particular		Certain frames can only occur as the first frame of a particular
	stream type; these are indicated in Table 1 with a (1). Specific		stream type; these are indicated in Table 1 with a (1). Specific
	guidance is provided in the relevant section.		guidance is provided in the relevant section.
	Note that, unlike QUIC frames, HTTP/3 frames can span multiple		Note that, unlike QUIC frames, HTTP/3 frames can span multiple
	packets.		packets.
	skipping to change at page 26, line 38 ¶		skipping to change at page 25, line 50 ¶
	respond with a connection error (Section 8) of type		respond with a connection error (Section 8) of type
	HTTP_FRAME_UNEXPECTED.		HTTP_FRAME_UNEXPECTED.
	7.2.3. CANCEL_PUSH		7.2.3. CANCEL_PUSH
	The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a		The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a
	server push prior to the push stream being received. The CANCEL_PUSH		server push prior to the push stream being received. The CANCEL_PUSH
	frame identifies a server push by Push ID (see Section 7.2.5),		frame identifies a server push by Push ID (see Section 7.2.5),
	encoded as a variable-length integer.		encoded as a variable-length integer.
	When a server receives this frame, it aborts sending the response for		When a client sends CANCEL_PUSH, it is indicating that it does not
	the identified server push. If the server has not yet started to		wish to receive the promised resource. The server SHOULD abort
	send the server push, it can use the receipt of a CANCEL_PUSH frame		sending the resource, but the mechanism to do so depends on the state
	to avoid opening a push stream. If the push stream has been opened		of the corresponding push stream. If the server has not yet created
	by the server, the server SHOULD abruptly terminate that stream.		a push stream, it does not create one. If the push stream is open,
			the server SHOULD abruptly terminate that stream. If the push stream
			has already ended, the server MAY still abruptly terminate the stream
			or MAY take no action.
	A server can send the CANCEL_PUSH frame to indicate that it will not		When a server sends CANCEL_PUSH, it is indicating that it will not be
	be fulfilling a promise prior to creation of a push stream. Once the		fulfilling a promise and has not created a push stream. The client
	push stream has been created, sending CANCEL_PUSH has no effect on		should not expect the corresponding promise to be fulfilled.
	the state of the push stream. The server SHOULD abruptly terminate
	the push stream instead.		Sending CANCEL_PUSH has no direct effect on the state of existing
			push streams. A server SHOULD NOT send a CANCEL_PUSH when it has
			already created a corresponding push stream, and a client SHOULD NOT
			send a CANCEL_PUSH when it has already received a corresponding push
			stream.
	A CANCEL_PUSH frame is sent on the control stream. Receiving a		A CANCEL_PUSH frame is sent on the control stream. Receiving a
	CANCEL_PUSH frame on a stream other than the control stream MUST be		CANCEL_PUSH frame on a stream other than the control stream MUST be
	treated as a connection error of type HTTP_FRAME_UNEXPECTED.		treated as a connection error of type HTTP_FRAME_UNEXPECTED.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Push ID (i) ...		| Push ID (i) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: CANCEL_PUSH frame payload		Figure 6: CANCEL_PUSH frame payload
	The CANCEL_PUSH frame carries a Push ID encoded as a variable-length		The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
	integer. The Push ID identifies the server push that is being		integer. The Push ID identifies the server push that is being
	cancelled (see Section 7.2.5).		cancelled (see Section 7.2.5). If a CANCEL_PUSH frame is received
			which references a Push ID greater than currently allowed on the
			connection, this MUST be treated as a connection error of type
			HTTP_ID_ERROR.
	If the client receives a CANCEL_PUSH frame, that frame might identify		If the client receives a CANCEL_PUSH frame, that frame might identify
	a Push ID that has not yet been mentioned by a PUSH_PROMISE frame.		a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due
			to reordering. If a server receives a CANCEL_PUSH frame for a Push
			ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST
			be treated as a connection error of type HTTP_ID_ERROR.
	7.2.4. SETTINGS		7.2.4. SETTINGS
	The SETTINGS frame (type=0x4) conveys configuration parameters that		The SETTINGS frame (type=0x4) conveys configuration parameters that
	affect how endpoints communicate, such as preferences and constraints		affect how endpoints communicate, such as preferences and constraints
	on peer behavior. Individually, a SETTINGS parameter can also be		on peer behavior. Individually, a SETTINGS parameter can also be
	referred to as a "setting"; the identifier and value of each setting		referred to as a "setting"; the identifier and value of each setting
	parameter can be referred to as a "setting identifier" and a "setting		parameter can be referred to as a "setting identifier" and a "setting
	value".		value".
	skipping to change at page 31, line 43 ¶		skipping to change at page 31, line 21 ¶
	client MUST treat a GOAWAY frame on a stream other than the control		client MUST treat a GOAWAY frame on a stream other than the control
	stream as a connection error (Section 8) of type		stream as a connection error (Section 8) of type
	HTTP_FRAME_UNEXPECTED.		HTTP_FRAME_UNEXPECTED.
	See Section 5.2 for more information on the use of the GOAWAY frame.		See Section 5.2 for more information on the use of the GOAWAY frame.
	7.2.7. MAX_PUSH_ID		7.2.7. 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 PUSH_PROMISE
	frame. Consequently, this also limits the number of push streams		and CANCEL_PUSH frames. Consequently, this also limits the number of
	that the server can initiate in addition to the limit maintained by		push streams that the server can initiate in addition to the limit
	the QUIC transport.		maintained by the QUIC transport.
	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_FRAME_UNEXPECTED.		connection error of type HTTP_FRAME_UNEXPECTED.
	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_FRAME_UNEXPECTED.		HTTP_FRAME_UNEXPECTED.
	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 33, line 42 ¶		skipping to change at page 33, line 19 ¶
	ignored (Section 9). These frames have no semantics, and can be sent		ignored (Section 9). These frames have no semantics, and can be sent
	on any open stream when application-layer padding is desired. They		on any open stream when application-layer padding is desired. They
	MAY also be sent on connections where no data is currently being		MAY also be sent on connections where no data is currently being
	transferred. Endpoints MUST NOT consider these frames to have any		transferred. Endpoints MUST NOT consider these frames to have any
	meaning upon receipt.		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.
	Frame types which were used in HTTP/2 where there is no corresponding		Frame types which were used in HTTP/2 where there is no corresponding
	HTTP/3 frame have also been reserved (Section 11.3). These frame		HTTP/3 frame have also been reserved (Section 11.2). These frame
	types MUST NOT be sent, and receipt MAY be treated as an error of		types MUST NOT be sent, and receipt MAY be treated as an error of
	type HTTP_UNEXPECTED_FRAME.		type HTTP_FRAME_UNEXPECTED.
	8. Error Handling		8. Error Handling
	QUIC allows the application to abruptly terminate (reset) individual		QUIC allows the application to abruptly terminate (reset) individual
	streams or the entire connection when an error is encountered. These		streams or the entire connection when an error is encountered. These
	are referred to as "stream errors" or "connection errors" and are		are referred to as "stream errors" or "connection errors" and are
	described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose		described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose
	to treat a stream error as a connection error.		to treat a stream error as a connection error.
	Because new error codes can be defined without negotiation (see		Because new error codes can be defined without negotiation (see
	skipping to change at page 35, line 39 ¶		skipping to change at page 35, line 20 ¶
	are effective only within the scope of a single HTTP/3 connection.		are effective only within the scope of a single HTTP/3 connection.
	This applies to the protocol elements defined in this document. This		This applies to the protocol elements defined in this document. This
	does not affect the existing options for extending HTTP, such as		does not affect the existing options for extending HTTP, such as
	defining new methods, status codes, or header fields.		defining new methods, status codes, or header fields.
	Extensions are permitted to use new frame types (Section 7.2), new		Extensions are permitted to use new frame types (Section 7.2), new
	settings (Section 7.2.4.1), new error codes (Section 8), or new		settings (Section 7.2.4.1), new error codes (Section 8), or new
	unidirectional stream types (Section 6.2). Registries are		unidirectional stream types (Section 6.2). Registries are
	established for managing these extension points: frame types		established for managing these extension points: frame types
	(Section 11.3), settings (Section 11.4), error codes (Section 11.5),		(Section 11.2), settings (Section 11.3), error codes (Section 11.4),
	and stream types (Section 11.6).		and stream types (Section 11.5).
	Implementations MUST ignore unknown or unsupported values in all		Implementations MUST ignore unknown or unsupported values in all
	extensible protocol elements. Implementations MUST discard frames		extensible protocol elements. Implementations MUST discard frames
	and unidirectional streams that have unknown or unsupported types.		and unidirectional streams that have unknown or unsupported types.
	This means that any of these extension points can be safely used by		This means that any of these extension points can be safely used by
	extensions without prior arrangement or negotiation. However, where		extensions without prior arrangement or negotiation. However, where
	a known frame type is required to be in a specific location, such as		a known frame type is required to be in a specific location, such as
	the SETTINGS frame as the first frame of the control stream (see		the SETTINGS frame as the first frame of the control stream (see
	Section 6.2.1), an unknown frame type does not satisfy that		Section 6.2.1), an unknown frame type does not satisfy that
	requirement and SHOULD be treated as an error.		requirement and SHOULD be treated as an error.
	skipping to change at page 37, line 26 ¶		skipping to change at page 37, line 4 ¶
	11.1. Registration of HTTP/3 Identification String		11.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:
	Protocol: HTTP/3		Protocol: HTTP/3
	Identification Sequence: 0x68 0x33 ("h3")		Identification Sequence: 0x68 0x33 ("h3")
	Specification: This document		Specification: This document
	11.2. Registration of QUIC Version Hint Alt-Svc Parameter		11.2. Frame Types
	This document creates a new registration for version-negotiation
	hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter"
	registry established in [RFC7838].
	Parameter: "quic"
	Specification: This document, Section 3.2.1
	11.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 governs a 62-bit space. This space		The "HTTP/3 Frame Type" registry governs a 62-bit space. This space
	is split into three spaces that are governed by different policies.		is 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].
	While this registry is separate from the "HTTP/2 Frame Type" registry		While this registry is separate from the "HTTP/2 Frame Type" registry
	skipping to change at page 39, line 5 ¶		skipping to change at page 38, line 37 ¶
	| | | |		| | | |
	| MAX_PUSH_ID | 0xD | Section 7.2.7 |		| MAX_PUSH_ID | 0xD | Section 7.2.7 |
	| | | |		| | | |
	| DUPLICATE_PUSH | 0xE | Section 7.2.8 |		| DUPLICATE_PUSH | 0xE | Section 7.2.8 |
	+----------------+------+----------------+		+----------------+------+----------------+
	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
	"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.		"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
	11.4. Settings Parameters		11.3. 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].
	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 [HTTP2].		Settings" registry defined in [HTTP2].
	skipping to change at page 40, line 9 ¶		skipping to change at page 39, line 40 ¶
	| | | | |		| | | | |
	| Reserved | 0x5 | N/A | N/A |		| Reserved | 0x5 | N/A | N/A |
	| | | | |		| | | | |
	| MAX_HEADER_LIST_SIZE | 0x6 | Section 7.2.4.1 | Unlimited |		| MAX_HEADER_LIST_SIZE | 0x6 | Section 7.2.4.1 | Unlimited |
	+----------------------+------+------------------+-----------+		+----------------------+------+------------------+-----------+
	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
	"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.		"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
	11.5. Error Codes		11.4. 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 62-bit space. The "HTTP/3		"HTTP/3 Error Code" registry manages a 62-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
	registrations for possible duplication with existing error codes.		registrations for possible duplication with existing error codes.
	Use of existing registrations is to be encouraged, but not mandated.		Use of existing registrations is to be encouraged, but not mandated.
	skipping to change at page 42, line 14 ¶		skipping to change at page 41, line 46 ¶
	| | | | |		| | | | |
	| HTTP_CONNECT_ERROR | 0x010F | TCP reset | Section 8.1 |		| HTTP_CONNECT_ERROR | 0x010F | TCP reset | Section 8.1 |
	| | | or error on | |		| | | or error on | |
	| | | CONNECT | |		| | | CONNECT | |
	| | | request | |		| | | request | |
	| | | | |		| | | | |
	| HTTP_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 |		| HTTP_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 |
	| | | HTTP/1.1 | |		| | | HTTP/1.1 | |
	+----------------------------+--------+-------------+---------------+		+----------------------------+--------+-------------+---------------+
	11.6. Stream Types		11.5. 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 governs a 62-bit space.		types. The "HTTP/3 Stream Type" registry governs a 62-bit space.
	This space is split into three spaces that are governed by different		This space is split into three spaces that are governed by different
	policies. Values between "0x00" and 0x3f (in hexadecimal) are		policies. Values between "0x00" and 0x3f (in hexadecimal) are
	assigned via the Standards Action or IESG Review policies [RFC8126].		assigned via the Standards Action or IESG Review policies [RFC8126].
	Values from "0x40" to "0x3fff" operate on the Specification Required		Values from "0x40" to "0x3fff" operate on the Specification Required
	policy [RFC8126]. All other values are assigned to Private Use		policy [RFC8126]. All other values are assigned to Private Use
	[RFC8126].		[RFC8126].
	skipping to change at page 43, line 25 ¶		skipping to change at page 43, line 12 ¶
	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>.
	[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[HTTP2] 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>.
	[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-10 (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-23 (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 48, line 16 ¶		skipping to change at page 47, line 51 ¶
	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 [HTTP2] have been reserved for simplicity. Note that the frame		in [HTTP2] have been reserved for simplicity. Note that the frame
	type space in HTTP/3 is substantially larger (62 bits versus 8 bits),		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.		so many HTTP/3 frame types have no equivalent HTTP/2 code points.
	See Section 11.3.		See Section 11.2.
	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,
	as the first frame of the control stream, and thereafter cannot		as the first frame of the control stream, and thereafter cannot
	change. This eliminates many corner cases around synchronization of		change. This eliminates many corner cases around synchronization of
	changes.		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
	skipping to change at page 49, line 4 ¶		skipping to change at page 48, line 40 ¶
	initial transport handshake. Specifying		initial transport handshake. Specifying
	SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error.		SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error.
	SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3.		SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3.
	Specifying it in the SETTINGS frame is an error.		Specifying it in the SETTINGS frame is an error.
	SETTINGS_MAX_HEADER_LIST_SIZE: See Section 7.2.4.1.		SETTINGS_MAX_HEADER_LIST_SIZE: See Section 7.2.4.1.
	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 [HTTP2] have been reserved for simplicity.		IDs of settings defined in [HTTP2] have been reserved for simplicity.
	Note that the settings identifier space in HTTP/3 is substantially		Note that the settings identifier space in HTTP/3 is substantially
	larger (62 bits versus 16 bits), so many HTTP/3 settings have no		larger (62 bits versus 16 bits), so many HTTP/3 settings have no
	equivalent HTTP/2 code point. See Section 11.4.		equivalent HTTP/2 code point. See Section 11.3.
	As QUIC streams might arrive out-of-order, endpoints are advised to		As QUIC streams might arrive out-of-order, endpoints are advised to
	not wait for the peers' settings to arrive before responding to other		not wait for the peers' settings to arrive before responding to other
	streams. See Section 7.2.4.2.		streams. See Section 7.2.4.2.
	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 to HTTP/3 error codes; the values are shifted in order to		error codes to HTTP/3 error codes; the values are shifted in order to
	skipping to change at page 50, line 24 ¶		skipping to change at page 50, line 11 ¶
	CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1.		CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1.
	ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1.		ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1.
	INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to		INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to
	provide sufficient security on all connections.		provide sufficient security on all connections.
	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 11.5.		Section 11.4.
	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-22		B.1. Since draft-ietf-quic-http-22
	o Removed priority signaling (#2922,#2924)		o Removed priority signaling (#2922,#2924)
End of changes. 43 change blocks.
	155 lines changed or deleted		131 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/