draft-ietf-quic-http-02.txt		draft-ietf-quic-http-03.txt
	QUIC M. Bishop, Ed.		QUIC M. Bishop, Ed.
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track March 13, 2017		Intended status: Standards Track May 21, 2017
	Expires: September 14, 2017		Expires: November 22, 2017
	Hypertext Transfer Protocol (HTTP) over QUIC		Hypertext Transfer Protocol (HTTP) over QUIC
	draft-ietf-quic-http-02		draft-ietf-quic-http-03
	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 QUIC.		how HTTP/2 extensions can be ported to QUIC.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 14, 2017.		This Internet-Draft will expire on November 22, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 29 ¶		skipping to change at page 2, line 29 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3		1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
	2. QUIC Advertisement . . . . . . . . . . . . . . . . . . . . . 3		2. QUIC Advertisement . . . . . . . . . . . . . . . . . . . . . 3
	2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . . . 4		2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . . . 4
	3. Connection Establishment . . . . . . . . . . . . . . . . . . 4		3. Connection Establishment . . . . . . . . . . . . . . . . . . 4
	3.1. Draft Version Identification . . . . . . . . . . . . . . 5		3.1. Draft Version Identification . . . . . . . . . . . . . . 5
	4. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 5		4. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 5
	4.1. Stream 3: Connection Control Stream . . . . . . . . . . . 6		4.1. Stream 1: Connection Control Stream . . . . . . . . . . . 6
	4.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 6		4.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 6
	4.2.1. Header Compression . . . . . . . . . . . . . . . . . 7		4.2.1. Header Compression . . . . . . . . . . . . . . . . . 7
	4.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 8		4.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 8
	4.3. Stream Priorities . . . . . . . . . . . . . . . . . . . . 9		4.3. Stream Priorities . . . . . . . . . . . . . . . . . . . . 9
	4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9		4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 9
	5. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10		5. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10		5.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10
	5.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 10		5.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 10
	5.2.1. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 10		5.2.1. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 10
	5.2.2. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 11		5.2.2. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 11
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	9.1. Registration of HTTP/QUIC Identification String . . . . . 21		9.1. Registration of HTTP/QUIC Identification String . . . . . 21
	9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 21		9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 21
	9.3. Existing Frame Types . . . . . . . . . . . . . . . . . . 21		9.3. Existing Frame Types . . . . . . . . . . . . . . . . . . 21
	9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 22		9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 22
	9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 23		9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	10.1. Normative References . . . . . . . . . . . . . . . . . . 25		10.1. Normative References . . . . . . . . . . . . . . . . . . 25
	10.2. Informative References . . . . . . . . . . . . . . . . . 26		10.2. Informative References . . . . . . . . . . . . . . . . . 26
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 26
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 26
	B.1. Since draft-ietf-quic-http-01: . . . . . . . . . . . . . 26		B.1. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 26
	B.2. Since draft-ietf-quic-http-00: . . . . . . . . . . . . . 27		B.2. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 27
	B.3. Since draft-shade-quic-http2-mapping-00: . . . . . . . . 27		B.3. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 27
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27		B.4. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 28
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	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, drawing heavily on		describes a mapping of HTTP semantics over QUIC, drawing heavily on
	the existing TCP mapping, HTTP/2. Specifically, this document		the existing TCP mapping, HTTP/2. Specifically, this document
	identifies HTTP/2 features that are subsumed by QUIC, and describes		identifies HTTP/2 features that are subsumed by QUIC, and describes
	how the other features can be implemented atop QUIC.		how the other features can be implemented atop QUIC.
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 43 ¶
	document. It's not shouting; when they are capitalized, they have		document. It's not shouting; when they are capitalized, they have
	the special meaning defined in [RFC2119].		the special meaning defined in [RFC2119].
	2. QUIC Advertisement		2. QUIC Advertisement
	An HTTP origin advertises the availability of an equivalent HTTP/QUIC		An HTTP origin advertises the availability of an equivalent HTTP/QUIC
	endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC		endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC
	frame ([RFC7838]), using the ALPN token defined in Section 3.		frame ([RFC7838]), using the ALPN token defined in Section 3.
	For example, an origin could indicate in an HTTP/1.1 or HTTP/2		For example, an origin could indicate in an HTTP/1.1 or HTTP/2
	response that HTTP/QUIC was available on UDP port 443 at the same		response that HTTP/QUIC was available on UDP port 50781 at the same
	hostname by including the following header in any response:		hostname by including the following header in any response:
	Alt-Svc: hq=":443"		Alt-Svc: hq=":50781"
	On receipt of an Alt-Svc header indicating HTTP/QUIC support, a		On receipt of an Alt-Svc header indicating HTTP/QUIC support, a
	client MAY attempt to establish a QUIC connection to the indicated		client MAY attempt to establish a QUIC connection to the indicated
	host and port and, if successful, send HTTP requests using the		host and port and, if successful, send HTTP requests using the
	mapping described in this document.		mapping 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/QUIC on any UDP port. Servers MUST use the
			same port across all IP addresses that serve a single domain, and
			SHOULD NOT change this port.
	2.1. QUIC Version Hints		2.1. QUIC Version Hints
	This document defines the "quic" parameter for Alt-Svc, which MAY be		This document defines the "quic" parameter for Alt-Svc, which MAY be
	used to provide version-negotiation hints to HTTP/QUIC clients. QUIC		used to provide version-negotiation hints to HTTP/QUIC clients. QUIC
	versions are four-octet sequences with no additional constraints on		versions are four-octet sequences with no additional constraints on
	format. Syntax:		format. Syntax:
	quic = version-number		quic = version-number
	version-number = 1*8HEXDIG; hex-encoded QUIC version		version-number = 1*8HEXDIG; hex-encoded QUIC version
	Leading zeros SHOULD be omitted for brevity. When multiple versions		Leading zeros SHOULD be omitted for brevity. When multiple versions
	are supported, the "quic" parameter MAY be repeated multiple times in		are supported, the "quic" parameter MAY be repeated multiple times in
	a single Alt-Svc entry. For example, if a server supported both		a single Alt-Svc entry. For example, if a server supported both
	version 0x00000001 and the version rendered in ASCII as "Q034", it		version 0x00000001 and the version rendered in ASCII as "Q034", it
	could specify the following header:		could specify the following header:
	Alt-Svc: hq=":443";quic=1;quic=51303334		Alt-Svc: hq=":49288";quic=1;quic=51303334
	Where multiple versions are listed, the order of the values reflects		Where multiple versions are listed, the order of the values reflects
	the server's preference (with the first value being the most		the server's preference (with the first value being the most
	preferred version). Origins SHOULD list only versions which are		preferred version). Origins SHOULD list only versions which are
	supported by the alternative, but MAY omit supported versions for any		supported by the alternative, but MAY omit supported versions for any
	reason.		reason.
	3. Connection Establishment		3. Connection Establishment
	HTTP/QUIC connections are established as described in		HTTP/QUIC connections are established as described in
	[QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support		[QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support
	is indicated by selecting the ALPN token "hq" in the crypto		is indicated by selecting the ALPN token "hq" in the crypto
	handshake.		handshake.
	While connection-level options pertaining to the core QUIC protocol		While connection-level options pertaining to the core QUIC protocol
	are set in the initial crypto handshake, HTTP-specific settings are		are set in the initial crypto handshake, HTTP-specific settings are
	conveyed in the SETTINGS frame. After the QUIC connection is		conveyed in the SETTINGS frame. After the QUIC connection is
	established, a SETTINGS frame (Section 5.2.3) MUST be sent as the		established, a SETTINGS frame (Section 5.2.3) MUST be sent as the
	initial frame of the HTTP control stream (StreamID 3, see Section 4).		initial frame of the HTTP control stream (Stream ID 1, see
	The server MUST NOT send data on any other stream until the client's		Section 4). The server MUST NOT send data on any other stream until
	SETTINGS frame has been received.		the client's SETTINGS frame has been received.
	3.1. Draft Version Identification		3.1. Draft Version Identification
	*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.
	Only implementations of the final, published RFC can identify		Only implementations of the final, published RFC can identify
	themselves as "hq". Until such an RFC exists, implementations MUST		themselves as "hq". Until such an RFC exists, implementations MUST
	NOT identify themselves using this string.		NOT identify themselves using this string.
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 37 ¶
	4. Stream Mapping and Usage		4. Stream Mapping and Usage
	A QUIC stream provides reliable in-order delivery of bytes, but makes		A QUIC stream provides reliable in-order delivery of bytes, but makes
	no guarantees about order of delivery with regard to bytes on other		no guarantees about order of delivery with regard to bytes on other
	streams. On the wire, data is framed into QUIC STREAM frames, but		streams. On the wire, data is framed into QUIC STREAM frames, but
	this framing is invisible to the HTTP framing layer. A QUIC receiver		this framing is invisible to the HTTP framing layer. A QUIC receiver
	buffers and orders received STREAM frames, exposing the data		buffers and orders received STREAM frames, exposing the data
	contained within as a reliable byte stream to the application.		contained within as a reliable byte stream to the application.
	QUIC reserves Stream 1 for crypto operations (the handshake, crypto		QUIC reserves Stream 0 for crypto operations (the handshake, crypto
	config updates). Stream 3 is reserved for sending and receiving HTTP		config updates). Stream 1 is reserved for sending and receiving HTTP
	control frames, and is analogous to HTTP/2's Stream 0. This		control frames, and is analogous to HTTP/2's Stream 0. This
	connection control stream is considered critical to the HTTP		connection control stream is considered critical to the HTTP
	connection. If the connection control stream is closed for any		connection. If the connection control stream is closed for any
	reason, this MUST be treated as a connection error of type		reason, this MUST be treated as a connection error of type
	QUIC_CLOSED_CRITICAL_STREAM.		QUIC_CLOSED_CRITICAL_STREAM.
	When HTTP headers and data are sent over QUIC, the QUIC layer handles		When HTTP headers and data are sent over QUIC, the QUIC layer handles
	most of the stream management. An HTTP request/response consumes a		most of the stream management. An HTTP request/response consumes a
	pair of streams: This means that the client's first request occurs on		pair of streams: This means that the client's first request occurs on
	QUIC streams 5 and 7, the second on stream 9 and 11, and so on. The		QUIC streams 3 and 5, the second on stream 7 and 9, and so on. The
	server's first push consumes streams 2 and 4. This amounts to the		server's first push consumes streams 2 and 4. This amounts to the
	second least-significant bit differentiating the two streams in a		second least-significant bit differentiating the two streams in a
	request.		request.
	The lower-numbered stream is called the message control stream and		The lower-numbered stream is called the message control stream and
	carries frames related to the request/response, including HEADERS.		carries frames related to the request/response, including HEADERS.
	The higher-numbered stream is the data stream and carries the		The higher-numbered stream is the data stream and carries the
	request/response body with no additional framing. Note that a		request/response body with no additional framing. Note that a
	request or response without a body will cause this stream to be half-		request or response without a body will cause this stream to be half-
	closed in the corresponding direction without transferring data.		closed in the corresponding direction without transferring data.
	skipping to change at page 6, line 39 ¶		skipping to change at page 6, line 39 ¶
	data stream is opened at the same time as the message control stream		data stream is opened at the same time as the message control stream
	is opened and is closed after transferring the body. The data stream		is opened and is closed after transferring the body. The data stream
	is closed immediately after sending the request headers if there is		is closed immediately after sending the request headers if there is
	no body.		no body.
	HTTP does not need to do any separate multiplexing when using QUIC -		HTTP does not need to do any separate multiplexing when using QUIC -
	data sent over a QUIC stream always maps to a particular HTTP		data sent over a QUIC stream always maps to a particular HTTP
	transaction. Requests and responses are considered complete when the		transaction. Requests and responses are considered complete when the
	corresponding QUIC streams are closed in the appropriate direction.		corresponding QUIC streams are closed in the appropriate direction.
	4.1. Stream 3: Connection Control Stream		4.1. Stream 1: Connection Control Stream
	Since most connection-level concerns will be managed by QUIC, the		Since most connection-level concerns will be managed by QUIC, the
	primary use of Stream 3 will be for the SETTINGS frame when the		primary use of Stream 1 will be for the SETTINGS frame when the
	connection opens and for PRIORITY frames subsequently.		connection opens and for PRIORITY frames subsequently.
	4.2. HTTP Message Exchanges		4.2. HTTP Message Exchanges
	A client sends an HTTP request on a new pair of QUIC streams. A		A client sends an HTTP request on a new pair of QUIC streams. A
	server sends an HTTP response on the same streams as the request.		server sends an HTTP response on the same streams as the request.
	An HTTP message (request or response) consists of:		An HTTP message (request or response) consists of:
	1. one header block (see Section 5.2.1) on the control stream		1. one header block (see Section 5.2.1) on the control stream
	skipping to change at page 9, line 46 ¶		skipping to change at page 9, line 46 ¶
	control stream of the dependent request, not the data stream.		control stream of the dependent request, not the data stream.
	4.4. Server Push		4.4. Server Push
	HTTP/QUIC supports server push as described in [RFC7540]. During		HTTP/QUIC supports server push as described in [RFC7540]. During
	connection establishment, the client indicates whether it is willing		connection establishment, the client indicates whether it is willing
	to receive server pushes via the SETTINGS_DISABLE_PUSH setting in the		to receive server pushes via the SETTINGS_DISABLE_PUSH setting in the
	SETTINGS frame (see Section 3), which defaults to 1 (true).		SETTINGS frame (see Section 3), which defaults to 1 (true).
	As with server push for HTTP/2, the server initiates a server push by		As with server push for HTTP/2, the server initiates a server push by
	sending a PUSH_PROMISE frame containing the StreamID of the stream to		sending a PUSH_PROMISE frame containing the Stream ID of the stream
	be pushed, as well as request header fields attributed to the		to be pushed, as well as request header fields attributed to the
	request. The PUSH_PROMISE frame is sent on the control stream of the		request. The PUSH_PROMISE frame is sent on the control stream of the
	associated (client-initiated) request, while the Promised Stream ID		associated (client-initiated) request, while the Promised Stream ID
	field specifies the Stream ID of the control stream for the server-		field specifies the Stream ID of the control stream for the server-
	initiated request.		initiated request.
	The server push response is conveyed in the same way as a non-server-		The server push response is conveyed in the same way as a non-server-
	push response, with response headers and (if present) trailers		push response, with response headers and (if present) trailers
	carried by HEADERS frames sent on the control stream, and response		carried by HEADERS frames sent on the control stream, and response
	body (if any) sent via the corresponding data stream.		body (if any) sent via the corresponding data stream.
	5. HTTP Framing Layer		5. HTTP Framing Layer
	Frames are used only on the connection (stream 3) and message		Frames are used only on the connection (stream 1) and message
	(streams 5, 9, etc.) control streams. Other streams carry data		(streams 3, 7, etc.) control streams. Other streams carry data
	payload and are not framed at the HTTP layer.		payload and are not framed at the HTTP layer.
	This section describes HTTP framing in QUIC and highlights some		This section describes HTTP framing in QUIC and highlights some
	differences from HTTP/2 framing. For more detail on differences from		differences from HTTP/2 framing. For more detail on differences from
	HTTP/2, see Section 7.1.		HTTP/2, see Section 7.1.
	5.1. Frame Layout		5.1. Frame Layout
	All frames have the following format:		All frames have the following format:
	skipping to change at page 18, line 6 ¶		skipping to change at page 18, line 6 ¶
	tree mutations): since operations on the dependency tree such as		tree mutations): since operations on the dependency tree such as
	reparenting a subtree are not commutative, both sender and receiver		reparenting a subtree are not commutative, both sender and receiver
	must apply them in the same order to ensure that both sides have a		must apply them in the same order to ensure that both sides have a
	consistent view of the stream dependency tree. HTTP/2 specifies		consistent view of the stream dependency tree. HTTP/2 specifies
	priority assignments in PRIORITY frames and (optionally) in HEADERS		priority assignments in PRIORITY frames and (optionally) in HEADERS
	frames. To achieve in-order delivery of priority changes in HTTP/		frames. To achieve in-order delivery of priority changes in HTTP/
	QUIC, PRIORITY frames are sent on the connection control stream and		QUIC, PRIORITY frames are sent on the connection control stream and
	the PRIORITY section is removed from the HEADERS frame.		the PRIORITY section is removed from the HEADERS frame.
	Other than this issue, frame type HTTP/2 extensions are typically		Other than this issue, frame type HTTP/2 extensions are typically
	portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 3		portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 1
	in HTTP/QUIC.		in HTTP/QUIC.
	Below is a listing of how each HTTP/2 frame type is mapped:		Below is a listing of how each HTTP/2 frame type is mapped:
	DATA (0x0): Instead of DATA frames, HTTP/QUIC uses a separate data		DATA (0x0): Instead of DATA frames, HTTP/QUIC uses a separate data
	stream. See Section 4.		stream. See Section 4.
	HEADERS (0x1): As described above, the PRIORITY region of HEADERS is		HEADERS (0x1): As described above, the PRIORITY region of HEADERS is
	not supported. A separate PRIORITY frame MUST be used. Padding		not supported. A separate PRIORITY frame MUST be used. Padding
	is not defined in HTTP/QUIC frames. See Section 5.2.1.		is not defined in HTTP/QUIC frames. See Section 5.2.1.
	skipping to change at page 25, line 35 ¶		skipping to change at page 25, line 35 ¶
	| | | stream was | |		| | | stream was | |
	| | | RST | |		| | | RST | |
	+------------------------------+-----+--------------+---------------+		+------------------------------+-----+--------------+---------------+
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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".		Multiplexed and Secure Transport", draft-ietf-quic-
			transport (work in progress), May 2017.
	[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,
	<http://www.rfc-editor.org/info/rfc793>.		<http://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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 26, line 45 ¶		skipping to change at page 26, line 45 ¶
	Appendix A. Contributors		Appendix A. Contributors
	The original authors of this specification were Robbie Shade and Mike		The original authors of this specification were Robbie Shade and Mike
	Warres.		Warres.
	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-01:		B.1. Since draft-ietf-quic-http-02
			o Track changes in transport draft
			B.2. Since draft-ietf-quic-http-01
	o SETTINGS changes (#181):		o SETTINGS changes (#181):
	* SETTINGS can be sent only once at the start of a connection; no		* SETTINGS can be sent only once at the start of a connection; no
	changes thereafter		changes thereafter
	* SETTINGS_ACK removed		* SETTINGS_ACK removed
	* Settings can only occur in the SETTINGS frame a single time		* Settings can only occur in the SETTINGS frame a single time
	* Boolean format updated		* Boolean format updated
	o Alt-Svc parameter changed from "v" to "quic"; format updated		o Alt-Svc parameter changed from "v" to "quic"; format updated
	(#229)		(#229)
	o Closing the connection control stream or any message control		o Closing the connection control stream or any message control
	stream is a fatal error (#176)		stream is a fatal error (#176)
	o HPACK Sequence counter can wrap (#173)		o HPACK Sequence counter can wrap (#173)
	o 0-RTT guidance added		o 0-RTT guidance added
	o Guide to differences from HTTP/2 and porting HTTP/2 extensions		o Guide to differences from HTTP/2 and porting HTTP/2 extensions
	added (#127,#242)		added (#127,#242)
	B.2. Since draft-ietf-quic-http-00:		B.3. Since draft-ietf-quic-http-00
	o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)		o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
	o Changed from using HTTP/2 framing within Stream 3 to new framing		o Changed from using HTTP/2 framing within Stream 3 to new framing
	format and two-stream-per-request model (#71,#72,#73)		format and two-stream-per-request model (#71,#72,#73)
	o Adopted SETTINGS format from draft-bishop-httpbis-extended-		o Adopted SETTINGS format from draft-bishop-httpbis-extended-
	settings-01		settings-01
	o Reworked SETTINGS_ACK to account for indeterminate inter-stream		o Reworked SETTINGS_ACK to account for indeterminate inter-stream
	order (#75)		order (#75)
	o Described CONNECT pseudo-method (#95)		o Described CONNECT pseudo-method (#95)
	o Updated ALPN token and Alt-Svc guidance (#13,#87)		o Updated ALPN token and Alt-Svc guidance (#13,#87)
	o Application-layer-defined error codes (#19,#74)		o Application-layer-defined error codes (#19,#74)
	B.3. Since draft-shade-quic-http2-mapping-00:		B.4. Since draft-shade-quic-http2-mapping-00
	o Adopted as base for draft-ietf-quic-http.		o Adopted as base for draft-ietf-quic-http
	o Updated authors/editors list.		o Updated authors/editors list
	Author's Address		Author's Address
	Mike Bishop (editor)		Mike Bishop (editor)
	Microsoft		Microsoft
	Email: Michael.Bishop@microsoft.com		Email: Michael.Bishop@microsoft.com
End of changes. 24 change blocks.
	31 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/