draft-ietf-httpbis-http2-07.txt		draft-ietf-httpbis-http2-08.txt
	HTTPbis Working Group M. Belshe		HTTPbis Working Group M. Belshe
	Internet-Draft Twist		Internet-Draft Twist
	Intended status: Standards Track R. Peon		Intended status: Standards Track R. Peon
	Expires: April 24, 2014 Google, Inc		Expires: May 15, 2014 Google, Inc
	M. Thomson, Ed.		M. Thomson, Ed.
	Microsoft		Microsoft
	A. Melnikov, Ed.		A. Melnikov, Ed.
	Isode Ltd		Isode Ltd
	October 21, 2013		November 11, 2013
	Hypertext Transfer Protocol version 2.0		Hypertext Transfer Protocol version 2.0
	draft-ietf-httpbis-http2-07		draft-ietf-httpbis-http2-08
	Abstract		Abstract
	This specification describes an optimized expression of the syntax of		This specification describes an optimized expression of the syntax of
	the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more		the Hypertext Transfer Protocol (HTTP). HTTP/2.0 enables a more
	efficient use of network resources and a reduced perception of		efficient use of network resources and a reduced perception of
	latency by introducing header field compression and allowing multiple		latency by introducing header field compression and allowing multiple
	concurrent messages on the same connection. It also introduces		concurrent messages on the same connection. It also introduces
	unsolicited push of representations from servers to clients.		unsolicited push of representations from servers to clients.
	This document is an alternative to, but does not obsolete, the		This document is an alternative to, but does not obsolete, the
	HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.		HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
			This version of the draft has been marked for implementation.
			Interoperability testing will occur in the HTTP/2.0 interim in
			Zurich, CH, starting 2014-01-22.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	Working Group information and related documents can be found at		Working Group information and related documents can be found at
	<http://tools.ietf.org/wg/httpbis/> (Wiki) and		<http://tools.ietf.org/wg/httpbis/> (Wiki) and
	<https://github.com/http2/http2-spec> (source code and issues		<https://github.com/http2/http2-spec> (source code and issues
	tracker).		tracker).
	The changes in this draft are summarized in Appendix A.1.		The changes in this draft are summarized in Appendix A.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 24, 2014.		This Internet-Draft will expire on May 15, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 48		skipping to change at page 3, line 4
	3.2. Starting HTTP/2.0 for "http" URIs . . . . . . . . . . . . 8		3.2. Starting HTTP/2.0 for "http" URIs . . . . . . . . . . . . 8
	3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10		3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10
	3.3. Starting HTTP/2.0 for "https" URIs . . . . . . . . . . . . 10		3.3. Starting HTTP/2.0 for "https" URIs . . . . . . . . . . . . 10
	3.4. Starting HTTP/2.0 with Prior Knowledge . . . . . . . . . . 10		3.4. Starting HTTP/2.0 with Prior Knowledge . . . . . . . . . . 10
	3.5. HTTP/2.0 Connection Header . . . . . . . . . . . . . . . . 11		3.5. HTTP/2.0 Connection Header . . . . . . . . . . . . . . . . 11
	4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 12		4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 13		4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.3. Header Compression and Decompression . . . . . . . . . . . 13		4.3. Header Compression and Decompression . . . . . . . . . . . 13
	5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14		5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . . 14
	5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14		5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 15
	5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19		5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . . 19
	5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19		5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . . 19
	5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 20		5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . . 20
	5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 20		5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 20
	5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21		5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21
	5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 22		5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 22
	5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22		5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . . 22
	5.4.1. Connection Error Handling . . . . . . . . . . . . . . 22		5.4.1. Connection Error Handling . . . . . . . . . . . . . . 22
	5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 23		5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 23
	5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23		5.4.3. Connection Termination . . . . . . . . . . . . . . . . 23
	skipping to change at page 4, line 14		skipping to change at page 4, line 19
	12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 54		12.2. Frame Type Registry . . . . . . . . . . . . . . . . . . . 54
	12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 55		12.3. Error Code Registry . . . . . . . . . . . . . . . . . . . 55
	12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 55		12.4. Settings Registry . . . . . . . . . . . . . . . . . . . . 55
	12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 56		12.5. HTTP2-Settings Header Field Registration . . . . . . . . . 56
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 56
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 57		14.1. Normative References . . . . . . . . . . . . . . . . . . . 57
	14.2. Informative References . . . . . . . . . . . . . . . . . . 58		14.2. Informative References . . . . . . . . . . . . . . . . . . 58
	Appendix A. Change Log (to be removed by RFC Editor before		Appendix A. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 59		publication) . . . . . . . . . . . . . . . . . . . . 59
	A.1. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59		A.1. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 59
	A.2. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59		A.2. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 59
	A.3. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59		A.3. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 59
	A.4. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60		A.4. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 59
	A.5. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60		A.5. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 60
	A.6. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60		A.6. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 60
	A.7. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61		A.7. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 60
	A.8. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 61		A.8. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 61
			A.9. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 61
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is a wildly successful		The Hypertext Transfer Protocol (HTTP) is a wildly successful
	protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section		protocol. However, the HTTP/1.1 message format ([HTTP-p1], Section
	3) is optimized for implementation simplicity and accessibility, not		3) is optimized for implementation simplicity and accessibility, not
	application performance. As such it has several characteristics that		application performance. As such it has several characteristics that
	have a negative overall effect on application performance.		have a negative overall effect on application performance.
	In particular, HTTP/1.0 only allows one request to be outstanding at		In particular, HTTP/1.0 only allows one request to be outstanding at
	skipping to change at page 9, line 20		skipping to change at page 9, line 20
	Upgrade: HTTP/2.0		Upgrade: HTTP/2.0
	HTTP2-Settings: <base64url encoding of HTTP/2.0 SETTINGS payload>		HTTP2-Settings: <base64url encoding of HTTP/2.0 SETTINGS payload>
	Requests that contain an entity body MUST be sent in their entirety		Requests that contain an entity body MUST be sent in their entirety
	before the client can send HTTP/2.0 frames. This means that a large		before the client can send HTTP/2.0 frames. This means that a large
	request entity can block the use of the connection until it is		request entity can block the use of the connection until it is
	completely sent.		completely sent.
	If concurrency of an initial request with subsequent requests is		If concurrency of an initial request with subsequent requests is
	important, a small request can be used to perform the upgrade to		important, a small request can be used to perform the upgrade to
	HTTP/2.0, at the cost of an additional round trip.		HTTP/2.0, at the cost of an additional round-trip.
	A server that does not support HTTP/2.0 can respond to the request as		A server that does not support HTTP/2.0 can respond to the request as
	though the Upgrade header field were absent:		though the Upgrade header field were absent:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Length: 243		Content-Length: 243
	Content-Type: text/html		Content-Type: text/html
	...		...
	skipping to change at page 12, line 18		skipping to change at page 12, line 18
	using HTTP/2.0.		using HTTP/2.0.
	4. HTTP Frames		4. HTTP Frames
	Once the HTTP/2.0 connection is established, endpoints can begin		Once the HTTP/2.0 connection is established, endpoints can begin
	exchanging frames.		exchanging frames.
	4.1. Frame Format		4.1. Frame Format
	All frames begin with an 8-octet header followed by a payload of		All frames begin with an 8-octet header followed by a payload of
	between 0 and 16383 octets.		between 0 and 16,383 octets.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| R | Length (14) | Type (8) | Flags (8) |		| R | Length (14) | Type (8) | Flags (8) |
	+-+-+-----------+---------------+-------------------------------+		+-+-+-----------+---------------+-------------------------------+
	|R| Stream Identifier (31) |		|R| Stream Identifier (31) |
	+-+-------------------------------------------------------------+		+-+-------------------------------------------------------------+
	| Frame Payload (0...) ...		| Frame Payload (0...) ...
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	skipping to change at page 13, line 46		skipping to change at page 13, line 46
	associated values. They are used within HTTP request and response		associated values. They are used within HTTP request and response
	messages as well as server push operations (see Section 8.2).		messages as well as server push operations (see Section 8.2).
	Header sets are logical collections of zero or more header fields		Header sets are logical collections of zero or more header fields
	arranged at the application layer. When transmitted over a		arranged at the application layer. When transmitted over a
	connection, the header set is serialized into a header block using		connection, the header set is serialized into a header block using
	HTTP Header Compression [COMPRESSION]. The serialized header block		HTTP Header Compression [COMPRESSION]. The serialized header block
	is then divided into one or more octet sequences, called header block		is then divided into one or more octet sequences, called header block
	fragments, and transmitted within the payload of HEADERS		fragments, and transmitted within the payload of HEADERS
	(Section 6.2), PUSH_PROMISE (Section 6.6) or CONTINUATION		(Section 6.2), PUSH_PROMISE (Section 6.6) or CONTINUATION
	(Section 6.10) frames. The receiving endpoint reassembles the header		(Section 6.10) frames.
	block by concatenating the individual fragments, then decompresses
	the block to reconstruct the header set.
	Header block fragments can only be sent as the payload of HEADERS,		A receiving endpoint reassembles the header block by concatenating
	PUSH_PROMISE or CONTINUATION frames.		the individual fragments, then decompresses the block to reconstruct
			the header set.
	A compressed and encoded header block is transmitted in a HEADERS or		A complete header block consists of either:
	PUSH_PROMISE frame, followed by zero or more CONTINUATION frames. If
	the number of octets in the block is greater than the space remaining		o a single HEADERS or PUSH_PROMISE frame each respectively with the
	in the frame, the block is divided into multiple fragments, which are		END_HEADERS or END_PUSH_PROMISE flag set, or
	then transmitted in multiple frames.
			o a HEADERS or PUSH_PROMISE frame with the END_HEADERS or
			END_PUSH_PROMISE flag cleared and one or more CONTINUATION frames,
			where the last CONTINUATION frame has the END_HEADER flag set.
	Header blocks MUST be transmitted as a contiguous sequence of frames,		Header blocks MUST be transmitted as a contiguous sequence of frames,
	with no interleaved frames of any other type, or from any other		with no interleaved frames of any other type, or from any other
	stream. The last frame in a sequence of HEADERS/CONTINUATION frames		stream. The last frame in a sequence of HEADERS or CONTINUATION
	MUST have the END_HEADERS flag set. The last frame in a sequence of		frames MUST have the END_HEADERS flag set. The last frame in a
	PUSH_PROMISE/CONTINUATION frames MUST have the END_PUSH_PROMISE/		sequence of PUSH_PROMISEor CONTINUATION frames MUST have the
	END_HEADERS flag set (respectively).		END_PUSH_PROMISE or END_HEADERS flag set (respectively).
	HEADERS, PUSH_PROMISE and CONTINUATION frames carry data that can		Header block fragments can only be sent as the payload of HEADERS,
	modify the compression context maintained by a receiver. An endpoint		PUSH_PROMISE or CONTINUATION frames. HEADERS, PUSH_PROMISE and
	receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST		CONTINUATION frames carry data that can modify the compression
	reassemble header blocks and perform decompression even if the frames		context maintained by a receiver. An endpoint receiving HEADERS,
	are to be discarded. A receiver MUST terminate the connection with a		PUSH_PROMISE or CONTINUATION frames MUST reassemble header blocks and
	connection error (Section 5.4.1) of type COMPRESSION_ERROR, if it		perform decompression even if the frames are to be discarded. A
	does not decompress a header block.		receiver MUST terminate the connection with a connection error
			(Section 5.4.1) of type COMPRESSION_ERROR, if it does not decompress
			a header block.
	5. Streams and Multiplexing		5. Streams and Multiplexing
	A "stream" is an independent, bi-directional sequence of HEADERS and		A "stream" is an independent, bi-directional sequence of HEADERS and
	DATA frames exchanged between the client and server within an		DATA frames exchanged between the client and server within an
	HTTP/2.0 connection. Streams have several important characteristics:		HTTP/2.0 connection. Streams have several important characteristics:
	o A single HTTP/2.0 connection can contain multiple concurrently		o A single HTTP/2.0 connection can contain multiple concurrently
	open streams, with either endpoint interleaving frames from		open streams, with either endpoint interleaving frames from
	multiple streams.		multiple streams.
	skipping to change at page 23, line 38		skipping to change at page 23, line 38
	A RST_STREAM is the last frame that an endpoint can send on a stream.		A RST_STREAM is the last frame that an endpoint can send on a stream.
	The peer that sends the RST_STREAM frame MUST be prepared to receive		The peer that sends the RST_STREAM frame MUST be prepared to receive
	any frames that were sent or enqueued for sending by the remote peer.		any frames that were sent or enqueued for sending by the remote peer.
	These frames can be ignored, except where they modify connection		These frames can be ignored, except where they modify connection
	state (such as the state maintained for header compression		state (such as the state maintained for header compression
	(Section 4.3)).		(Section 4.3)).
	Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame		Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
	for any stream. However, an endpoint MAY send additional RST_STREAM		for any stream. However, an endpoint MAY send additional RST_STREAM
	frames if it receives frames on a closed stream after more than a		frames if it receives frames on a closed stream after more than a
	round trip time. This behavior is permitted to deal with misbehaving		round-trip time. This behavior is permitted to deal with misbehaving
	implementations.		implementations.
	An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM		An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM
	frame, to avoid looping.		frame, to avoid looping.
	5.4.3. Connection Termination		5.4.3. Connection Termination
	If the TCP connection is torn down while streams remain in open or		If the TCP connection is torn down while streams remain in open or
	half closed states, then the endpoint MUST assume that the stream was		half closed states, then the endpoint MUST assume that the stream was
	abnormally interrupted and could be incomplete.		abnormally interrupted and could be incomplete.
	skipping to change at page 24, line 31		skipping to change at page 24, line 31
	6.1. DATA		6.1. DATA
	DATA frames (type=0x0) convey arbitrary, variable-length sequences of		DATA frames (type=0x0) convey arbitrary, variable-length sequences of
	octets associated with a stream. One or more DATA frames are used,		octets associated with a stream. One or more DATA frames are used,
	for instance, to carry HTTP request or response payloads.		for instance, to carry HTTP request or response payloads.
	The DATA frame defines the following flags:		The DATA frame defines the following flags:
	END_STREAM (0x1): Bit 1 being set indicates that this frame is the		END_STREAM (0x1): Bit 1 being set indicates that this frame is the
	last that the endpoint will send for the identified stream.		last that the endpoint will send for the identified stream.
	Setting this flag causes the stream to enter a "half closed" or		Setting this flag causes the stream to enter one of "half closed"
	"closed" state (Section 5.1).		states or "closed" state (Section 5.1).
	RESERVED (0x2): Bit 2 is reserved for future use.		RESERVED (0x2): Bit 2 is reserved for future use.
	DATA frames MUST be associated with a stream. If a DATA frame is		DATA frames MUST be associated with a stream. If a DATA frame is
	received whose stream identifier field is 0x0, the recipient MUST		received whose stream identifier field is 0x0, the recipient MUST
	respond with a connection error (Section 5.4.1) of type		respond with a connection error (Section 5.4.1) of type
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	DATA frames are subject to flow control and can only be sent when a		DATA frames are subject to flow control and can only be sent when a
	stream is in the "open" or "half closed (remote)" states.		stream is in the "open" or "half closed (remote)" states. If a DATA
			frame is received whose stream is not in "open" or "half closed
			(local)" state, the recipient MUST respond with a connection error
			(Section 5.4.1) of type PROTOCOL_ERROR.
	6.2. HEADERS		6.2. HEADERS
	The HEADERS frame (type=0x1) carries name-value pairs. It is used to		The HEADERS frame (type=0x1) carries name-value pairs. It is used to
	open a stream (Section 5.1). HEADERS frames can be sent on a stream		open a stream (Section 5.1). HEADERS frames can be sent on a stream
	in the "open" or "half closed (remote)" states.		in the "open" or "half closed (remote)" states.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|X| Priority (31) |		|X| Priority (31) |
	+-+-------------------------------------------------------------+		+-+-------------------------------------------------------------+
	| Header Block Fragment (*) ...		| Header Block Fragment (*) ...
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	HEADERS Frame Payload		HEADERS Frame Payload
	The HEADERS frame defines the following flags:		The HEADERS frame defines the following flags:
	END_STREAM (0x1): Bit 1 being set indicates that this frame is the		END_STREAM (0x1): Bit 1 being set indicates that the header block
	last that the endpoint will send for the identified stream.		(Section 4.3) is the last that the endpoint will send for the
	Setting this flag causes the stream to enter a "half closed" state		identified stream. Setting this flag causes the stream to enter
	(Section 5.1).		one of "half closed" states (Section 5.1).
	A HEADERS frame that is followed by CONTINUATION frames carries		A HEADERS frame that is followed by CONTINUATION frames carries
	the flag that signals the end of a stream. A CONTINUATION frame		the END_STREAM flag that signals the end of a stream. A
	cannot be used to terminate a stream.		CONTINUATION frame cannot be used to terminate a stream.
	RESERVED (0x2): Bit 2 is reserved for future use.		RESERVED (0x2): Bit 2 is reserved for future use.
	END_HEADERS (0x4): Bit 3 being set indicates that this frame ends		END_HEADERS (0x4): Bit 3 being set indicates that this frame
	the sequence of header block fragments necessary to provide a		contains an entire header block (Section 4.3) and is not followed
	complete set of header fields.		by any CONTINUATION frames.
	The payload for a complete header block is provided by a sequence
	of that starts with a HEADERS frame, followed by zero or more
	CONTINUATION frames. The sequence is terminated by a frame with
	the END_HEADERS flag set. Once the sequence terminates, the
	payload of all HEADERS and CONTINUATION frames are concatenated
	and interpreted as a single block.
	A HEADERS frame without the END_HEADERS flag set MUST be followed		A HEADERS frame without the END_HEADERS flag set MUST be followed
	by a CONTINUATION frame for the same stream. A receiver MUST		by a CONTINUATION frame for the same stream. A receiver MUST
	treat the receipt of any other type of frame or a frame on a		treat the receipt of any other type of frame or a frame on a
	different stream as a connection error (Section 5.4.1) of type		different stream as a connection error (Section 5.4.1) of type
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	PRIORITY (0x8): Bit 4 being set indicates that the first four octets		PRIORITY (0x8): Bit 4 being set indicates that the first four octets
	of this frame contain a single reserved bit and a 31-bit priority;		of this frame contain a single reserved bit and a 31-bit priority;
	see Section 5.3. If this bit is not set, the four bytes do not		see Section 5.3. If this bit is not set, the four bytes do not
	skipping to change at page 27, line 44		skipping to change at page 27, line 38
	If a RST_STREAM frame identifying an idle stream is received, the		If a RST_STREAM frame identifying an idle stream is received, the
	recipient MUST treat this as a connection error (Section 5.4.1) of		recipient MUST treat this as a connection error (Section 5.4.1) of
	type PROTOCOL_ERROR.		type PROTOCOL_ERROR.
	6.5. SETTINGS		6.5. SETTINGS
	The SETTINGS frame (type=0x4) conveys configuration parameters that		The SETTINGS frame (type=0x4) conveys configuration parameters that
	affect how endpoints communicate. The parameters are either		affect how endpoints communicate. The parameters are either
	constraints on peer behavior or preferences.		constraints on peer behavior or preferences.
			Settings are not negotiated. Settings describe characteristics of
			the sending peer, which are used by the receiving peer. Different
			values for the same setting can be advertised by each peer. For
			example, a client might set a high initial flow control window,
			whereas a server might set a lower value to conserve resources.
	SETTINGS frames MUST be sent at the start of a connection, and MAY be		SETTINGS frames MUST be sent at the start of a connection, and MAY be
	sent at any other time by either endpoint over the lifetime of the		sent at any other time by either endpoint over the lifetime of the
	connection.		connection.
	Implementations MUST support all of the settings defined by this		Implementations MUST support all of the settings defined by this
	specification and MAY support additional settings defined by		specification and MAY support additional settings defined by
	extensions. Unsupported or unrecognized settings MUST be ignored.		extensions. Unsupported or unrecognized settings MUST be ignored.
	New settings MUST NOT be defined or implemented in a way that		New settings MUST NOT be defined or implemented in a way that
	requires endpoints to understand them in order to communicate		requires endpoints to understand them in order to communicate
	successfully.		successfully.
	skipping to change at page 29, line 11		skipping to change at page 29, line 11
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	Setting Format		Setting Format
	6.5.2. Defined Settings		6.5.2. Defined Settings
	The following settings are defined:		The following settings are defined:
	SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the		SETTINGS_HEADER_TABLE_SIZE (1): Allows the sender to inform the
	remote endpoint of the size of the header compression table used		remote endpoint of the size of the header compression table used
	to decode header blocks. The default value is 4096 bytes.		to decode header blocks. The space available for encoding cannot
			be changed; it is determined by the setting sent by the peer that
			receives the header blocks. The initial value is 4096 bytes.
	SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server		SETTINGS_ENABLE_PUSH (2): This setting can be use to disable server
	push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE		push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE
	frame if it receives this setting set to a value of 0. The		frame if it receives this setting set to a value of 0. The
	default value is 1, which indicates that push is permitted.		initial value is 1, which indicates that push is permitted.
	SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of		SETTINGS_MAX_CONCURRENT_STREAMS (4): Indicates the maximum number of
	concurrent streams that the sender will allow. This limit is		concurrent streams that the sender will allow. This limit is
	directional: it applies to the number of streams that the sender		directional: it applies to the number of streams that the sender
	permits the receiver to create. By default there is no limit. It		permits the receiver to create. Initially there is no limit to
	is recommended that this value be no smaller than 100, so as to		this value. It is recommended that this value be no smaller than
	not unnecessarily limit parallelism.		100, so as to not unnecessarily limit parallelism.
	SETTINGS_INITIAL_WINDOW_SIZE (7): Indicates the sender's initial		SETTINGS_INITIAL_WINDOW_SIZE (7): Indicates the sender's initial
	window size (in bytes) for stream level flow control.		window size (in bytes) for stream level flow control.
	This settings affects the window size of all streams, including		This settings affects the window size of all streams, including
	existing streams, see Section 6.9.2.		existing streams, see Section 6.9.2.
	SETTINGS_FLOW_CONTROL_OPTIONS (10): Indicates flow control options.		SETTINGS_FLOW_CONTROL_OPTIONS (10): Indicates flow control options.
	The least significant bit (0x1) of the value is set to indicate		The least significant bit (0x1) of the value is set to indicate
	that the sender has disabled all flow control. This bit cannot be		that the sender has disabled all flow control. This bit cannot be
	skipping to change at page 29, line 46		skipping to change at page 29, line 48
	All bits other than the least significant are reserved.		All bits other than the least significant are reserved.
	6.5.3. Settings Synchronization		6.5.3. Settings Synchronization
	Most values in SETTINGS benefit from or require an understanding of		Most values in SETTINGS benefit from or require an understanding of
	when the peer has received and applied the changed setting values.		when the peer has received and applied the changed setting values.
	In order to provide such synchronization timepoints, the recipient of		In order to provide such synchronization timepoints, the recipient of
	a SETTINGS frame in which the ACK flag is not set MUST apply the		a SETTINGS frame in which the ACK flag is not set MUST apply the
	updated settings as soon as possible upon receipt.		updated settings as soon as possible upon receipt.
	The values in the SETTINGS frame MUST be applied in sequence, with no		The values in the SETTINGS frame MUST be applied in the order they
	other frame processing between values. Once all values have been		appear, with no other frame processing between values. Once all
	applied, the recipient MUST immediately emit a SETTINGS frame with		values have been applied, the recipient MUST immediately emit a
	the ACK flag set.		SETTINGS frame with the ACK flag set. The sender of altered settings
			applies changes upon receiving a SETTINGS frame with the ACK flag
			set.
	If the sender of a SETTINGS frame does not receive an acknowledgement		If the sender of a SETTINGS frame does not receive an acknowledgement
	within a reasonable amount of time, it MAY issue a connection error		within a reasonable amount of time, it MAY issue a connection error
	(Section 5.4.1) of type SETTINGS_TIMEOUT.		(Section 5.4.1) of type SETTINGS_TIMEOUT.
	6.6. PUSH_PROMISE		6.6. PUSH_PROMISE
	The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint		The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint
	in advance of streams the sender intends to initiate. The		in advance of streams the sender intends to initiate. The
	PUSH_PROMISE frame includes the unsigned 31-bit identifier of the		PUSH_PROMISE frame includes the unsigned 31-bit identifier of the
	stream the endpoint plans to create along with a minimal set of		stream the endpoint plans to create along with a set of headers that
	headers that provide additional context for the stream. Section 8.2		provide additional context for the stream. Section 8.2 contains a
	contains a thorough description of the use of PUSH_PROMISE frames.		thorough description of the use of PUSH_PROMISE frames.
	PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of		PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of
	the peer endpoint is set to 0.		the peer endpoint is set to 0.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|X| Promised-Stream-ID (31) |		|X| Promised-Stream-ID (31) |
	+-+-------------------------------------------------------------+		+-+-------------------------------------------------------------+
	| Header Block Fragment (*) ...		| Header Block Fragment (*) ...
	skipping to change at page 30, line 44		skipping to change at page 30, line 48
	Following the "Promised-Stream-ID" is a header block fragment		Following the "Promised-Stream-ID" is a header block fragment
	(Section 4.3).		(Section 4.3).
	PUSH_PROMISE frames MUST be associated with an existing, peer-		PUSH_PROMISE frames MUST be associated with an existing, peer-
	initiated stream. If the stream identifier field specifies the value		initiated stream. If the stream identifier field specifies the value
	0x0, a recipient MUST respond with a connection error (Section 5.4.1)		0x0, a recipient MUST respond with a connection error (Section 5.4.1)
	of type PROTOCOL_ERROR.		of type PROTOCOL_ERROR.
	The PUSH_PROMISE frame defines the following flags:		The PUSH_PROMISE frame defines the following flags:
	END_PUSH_PROMISE (0x4): The END_PUSH_PROMISE bit indicates that this		END_PUSH_PROMISE (0x4): Bit 3 being set indicates that this frame
	frame ends the sequence of header block fragments necessary to		contains an entire header block (Section 4.3) and is not followed
	provide a complete set of headers.		by any CONTINUATION frames.
	The payload for a complete header block is provided by a sequence
	of frames that starts with a PUSH_PROMISE frame, followed by zero
	or more CONTINUATION frames. The sequence terminates by a
	PUSH_PROMISE frame with the END_PUSH_PROMISE flag set or a
	CONTINUATION frame with the END_HEADERS flag set. Once the
	sequence terminates, the payload of all frames in the sequence are
	concatenated and interpreted as a single block.
	A PUSH_PROMISE frame without the END_PUSH_PROMISE flag set MUST be		A PUSH_PROMISE frame without the END_PUSH_PROMISE flag set MUST be
	followed by a CONTINUATION frame for the same stream. A receiver		followed by a CONTINUATION frame for the same stream. A receiver
	MUST treat the receipt of any other type of frame or a frame on a		MUST treat the receipt of any other type of frame or a frame on a
	different stream as a connection error (Section 5.4.1) of type		different stream as a connection error (Section 5.4.1) of type
	PROTOCOL_ERROR.		PROTOCOL_ERROR.
	Promised streams are not required to be used in order promised. The		Promised streams are not required to be used in order promised. The
	PUSH_PROMISE only reserves stream identifiers for later use.		PUSH_PROMISE only reserves stream identifiers for later use.
	skipping to change at page 38, line 21		skipping to change at page 38, line 21
	re-enable flow control - by sending a WINDOW_UPDATE or by clearing		re-enable flow control - by sending a WINDOW_UPDATE or by clearing
	the bits on the SETTINGS_FLOW_CONTROL_OPTIONS setting - MUST be		the bits on the SETTINGS_FLOW_CONTROL_OPTIONS setting - MUST be
	rejected with a FLOW_CONTROL_ERROR error code.		rejected with a FLOW_CONTROL_ERROR error code.
	6.10. CONTINUATION		6.10. CONTINUATION
	The CONTINUATION frame (type=0xA) is used to continue a sequence of		The CONTINUATION frame (type=0xA) is used to continue a sequence of
	header block fragments (Section 4.3). Any number of CONTINUATION		header block fragments (Section 4.3). Any number of CONTINUATION
	frames can be sent on an existing stream, as long as the preceding		frames can be sent on an existing stream, as long as the preceding
	frame on the same stream is one of HEADERS, PUSH_PROMISE or		frame on the same stream is one of HEADERS, PUSH_PROMISE or
	CONTINUATION.		CONTINUATION without the END_HEADERS or END_PUSH_PROMISE flag set.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Header Block Fragment (*) ...		| Header Block Fragment (*) ...
	+---------------------------------------------------------------+		+---------------------------------------------------------------+
	CONTINUATION Frame Payload		CONTINUATION Frame Payload
	The CONTINUATION frame defines the following flags:		The CONTINUATION frame defines the following flags:
	END_HEADERS (0x4): The END_HEADERS bit indicates that this frame		END_HEADERS (0x4): Bit 3 being set indicates that this frame ends a
	ends the sequence of header block fragments necessary to provide a		header block (Section 4.3).
	complete set of header fields.
	The payload for a complete header block is provided by a sequence
	that starts with a HEADERS or PUSH_PROMISE frame and zero or more
	CONTINUATION frames, terminated by a HEADERS or CONTINUATION frame
	with the END_HEADERS flag set, or PUSH_PROMISE frame with the
	END_PUSH_PROMISE flag set. Once the sequence terminates, the
	payload of all frames in the sequence are concatenated and
	interpreted as a single block.
	A HEADERS, PUSH_PROMISE, or CONTINUATION frame without the		If the END_HEADERS bit is not set, this frame MUST be followed by
	END_HEADERS flag set MUST be followed by a CONTINUATION frame for		another CONTINUATION frame. A receiver MUST treat the receipt of
	the same stream. A receiver MUST treat the receipt of any other		any other type of frame or a frame on a different stream as a
	type of frame or a frame on a different stream as a connection		connection error (Section 5.4.1) of type PROTOCOL_ERROR.
	error (Section 5.4.1) of type PROTOCOL_ERROR.
	The payload of a CONTINUATION frame contains a header block fragment		The payload of a CONTINUATION frame contains a header block fragment
	(Section 4.3).		(Section 4.3).
	The CONTINUATION frame changes the connection state as defined in		The CONTINUATION frame changes the connection state as defined in
	Section 4.3.		Section 4.3.
	CONTINUATION frames MUST be associated with a stream. If a		CONTINUATION frames MUST be associated with a stream. If a
	CONTINUATION frame is received whose stream identifier field is 0x0,		CONTINUATION frame is received whose stream identifier field is 0x0,
	the recipient MUST respond with a connection error (Section 5.4.1) of		the recipient MUST respond with a connection error (Section 5.4.1) of
	type PROTOCOL_ERROR.		type PROTOCOL_ERROR.
	A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or		A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or
	CONTINUATION frame. A recipient that observes violation of this rule		CONTINUATION frame without the END_HEADERS flag set. A recipient
	MUST respond with a connection error (Section 5.4.1) of type		that observes violation of this rule MUST respond with a connection
	PROTOCOL_ERROR.		error (Section 5.4.1) of type PROTOCOL_ERROR.
	7. Error Codes		7. Error Codes
	Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY		Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY
	frames to convey the reasons for the stream or connection error.		frames to convey the reasons for the stream or connection error.
	Error codes share a common code space. Some error codes only apply		Error codes share a common code space. Some error codes only apply
	to specific conditions and have no defined semantics in certain frame		to specific conditions and have no defined semantics in certain frame
	types.		types.
	skipping to change at page 45, line 37		skipping to change at page 45, line 35
	A malformed request or response is one that uses a valid sequence of		A malformed request or response is one that uses a valid sequence of
	HTTP/2.0 frames, but is otherwise invalid due to the presence of		HTTP/2.0 frames, but is otherwise invalid due to the presence of
	prohibited header fields, the absence of mandatory header fields, or		prohibited header fields, the absence of mandatory header fields, or
	the inclusion of uppercase header field names.		the inclusion of uppercase header field names.
	A request or response that includes an entity body can include a		A request or response that includes an entity body can include a
	"content-length" header field. A request or response is also		"content-length" header field. A request or response is also
	malformed if the value of a "content-length" header field does not		malformed if the value of a "content-length" header field does not
	equal the sum of the DATA frame payload lengths that form the body.		equal the sum of the DATA frame payload lengths that form the body.
	Intermediaries MAY forward a malformed request or response, but only		Intermediaries that process HTTP requests or responses (i.e., all
	if the frames are forwarded without inspection of header fields.		intermediaries other than those acting as tunnels) MUST NOT forward a
			malformed request or response.
	Implementations that detect malformed requests or responses need to		Implementations that detect malformed requests or responses need to
	ensure that the stream ends. For malformed requests, a server MAY		ensure that the stream ends. For malformed requests, a server MAY
	send an HTTP response to prior to closing or resetting the stream.		send an HTTP response to prior to closing or resetting the stream.
	Clients MUST NOT accept a malformed response.		Clients MUST NOT accept a malformed response.
	8.1.4. Request Reliability Mechanisms in HTTP/2.0		8.1.4. Request Reliability Mechanisms in HTTP/2.0
	In HTTP/1.1, an HTTP client is unable to retry a non-idempotent		In HTTP/1.1, an HTTP client is unable to retry a non-idempotent
	request when an error occurs, because there is no means to determine		request when an error occurs, because there is no means to determine
	skipping to change at page 52, line 23		skipping to change at page 52, line 23
	to HTTP/2.0 MUST remove any instances of the "obs-fold" production		to HTTP/2.0 MUST remove any instances of the "obs-fold" production
	from header field values.		from header field values.
	10.4. Cacheability of Pushed Resources		10.4. Cacheability of Pushed Resources
	Pushed resources are responses without an explicit request; the		Pushed resources are responses without an explicit request; the
	request for a pushed resource is synthesized from the request that		request for a pushed resource is synthesized from the request that
	triggered the push, plus resource identification information provided		triggered the push, plus resource identification information provided
	by the server. Request header fields are necessary for HTTP cache		by the server. Request header fields are necessary for HTTP cache
	control validations (such as the Vary header field) to work. For		control validations (such as the Vary header field) to work. For
	this reason, caches MUST inherit request header fields from the		this reason, caches MUST associate the request header fields from the
	associated stream for the push. This includes the Cookie header		PUSH_PROMISE frame with the response headers and content delivered on
	field.		the pushed stream. This includes the Cookie header field.
	Caching resources that are pushed is possible, based on the guidance		Caching resources that are pushed is possible, based on the guidance
	provided by the origin server in the Cache-Control header field.		provided by the origin server in the Cache-Control header field.
	However, this can cause issues if a single server hosts more than one		However, this can cause issues if a single server hosts more than one
	tenant. For example, a server might offer multiple users each a		tenant. For example, a server might offer multiple users each a
	small portion of its URI space.		small portion of its URI space.
	Where multiple tenants share space on the same server, that server		Where multiple tenants share space on the same server, that server
	MUST ensure that tenants are not able to push representations of		MUST ensure that tenants are not able to push representations of
	resources that they do not have authority over. Failure to enforce		resources that they do not have authority over. Failure to enforce
	skipping to change at page 59, line 8		skipping to change at page 59, line 8
	[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP		[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP
	Extensions for High Performance", RFC 1323, May 1992.		Extensions for High Performance", RFC 1323, May 1992.
	[TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.		[TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C.
	Jackson, "Talking to Yourself for Fun and Profit",		Jackson, "Talking to Yourself for Fun and Profit",
	2011, <http://w2spconf.com/2011/papers/websocket.pdf>.		2011, <http://w2spconf.com/2011/papers/websocket.pdf>.
	Appendix A. Change Log (to be removed by RFC Editor before publication)		Appendix A. Change Log (to be removed by RFC Editor before publication)
	A.1. Since draft-ietf-httpbis-http2-06		A.1. Since draft-ietf-httpbis-http2-07
			Marked draft for implementation.
			A.2. Since draft-ietf-httpbis-http2-06
	Adding definition for CONNECT method.		Adding definition for CONNECT method.
	Constraining the use of push to safe, cacheable methods with no		Constraining the use of push to safe, cacheable methods with no
	request body.		request body.
	Changing from :host to :authority to remove any potential confusion.		Changing from :host to :authority to remove any potential confusion.
	Adding setting for header compression table size.		Adding setting for header compression table size.
	Adding settings acknowledgement.		Adding settings acknowledgement.
	Removing unnecessary and potentially problematic flags from		Removing unnecessary and potentially problematic flags from
	CONTINUATION.		CONTINUATION.
	Added denial of service considerations.		Added denial of service considerations.
	A.2. Since draft-ietf-httpbis-http2-05		A.3. Since draft-ietf-httpbis-http2-05
	Marking the draft ready for implementation.		Marking the draft ready for implementation.
	Renumbering END_PUSH_PROMISE flag.		Renumbering END_PUSH_PROMISE flag.
	Editorial clarifications and changes.		Editorial clarifications and changes.
	A.3. Since draft-ietf-httpbis-http2-04		A.4. Since draft-ietf-httpbis-http2-04
	Added CONTINUATION frame for HEADERS and PUSH_PROMISE.		Added CONTINUATION frame for HEADERS and PUSH_PROMISE.
	PUSH_PROMISE is no longer implicitly prohibited if		PUSH_PROMISE is no longer implicitly prohibited if
	SETTINGS_MAX_CONCURRENT_STREAMS is zero.		SETTINGS_MAX_CONCURRENT_STREAMS is zero.
	Push expanded to allow all safe methods without a request body.		Push expanded to allow all safe methods without a request body.
	Clarified the use of HTTP header fields in requests and responses.		Clarified the use of HTTP header fields in requests and responses.
	Prohibited HTTP/1.1 hop-by-hop header fields.		Prohibited HTTP/1.1 hop-by-hop header fields.
	skipping to change at page 60, line 12		skipping to change at page 60, line 15
	Clarified requirements around handling different frames after stream		Clarified requirements around handling different frames after stream
	close, stream reset and GOAWAY.		close, stream reset and GOAWAY.
	Added more specific prohibitions for sending of different frame types		Added more specific prohibitions for sending of different frame types
	in various stream states.		in various stream states.
	Making the last received setting value the effective value.		Making the last received setting value the effective value.
	Clarified requirements on TLS version, extension and ciphers.		Clarified requirements on TLS version, extension and ciphers.
	A.4. Since draft-ietf-httpbis-http2-03		A.5. Since draft-ietf-httpbis-http2-03
	Committed major restructuring atrocities.		Committed major restructuring atrocities.
	Added reference to first header compression draft.		Added reference to first header compression draft.
	Added more formal description of frame lifecycle.		Added more formal description of frame lifecycle.
	Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA.		Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA.
	Removed HEADERS+PRIORITY, added optional priority to HEADERS frame.		Removed HEADERS+PRIORITY, added optional priority to HEADERS frame.
	Added PRIORITY frame.		Added PRIORITY frame.
	A.5. Since draft-ietf-httpbis-http2-02		A.6. Since draft-ietf-httpbis-http2-02
	Added continuations to frames carrying header blocks.		Added continuations to frames carrying header blocks.
	Replaced use of "session" with "connection" to avoid confusion with		Replaced use of "session" with "connection" to avoid confusion with
	other HTTP stateful concepts, like cookies.		other HTTP stateful concepts, like cookies.
	Removed "message".		Removed "message".
	Switched to TLS ALPN from NPN.		Switched to TLS ALPN from NPN.
	Editorial changes.		Editorial changes.
	A.6. Since draft-ietf-httpbis-http2-01		A.7. Since draft-ietf-httpbis-http2-01
	Added IANA considerations section for frame types, error codes and		Added IANA considerations section for frame types, error codes and
	settings.		settings.
	Removed data frame compression.		Removed data frame compression.
	Added PUSH_PROMISE.		Added PUSH_PROMISE.
	Added globally applicable flags to framing.		Added globally applicable flags to framing.
	skipping to change at page 61, line 23		skipping to change at page 61, line 27
	Restructured frame header. Removed distinction between data and		Restructured frame header. Removed distinction between data and
	control frames.		control frames.
	Altered flow control properties to include session-level limits.		Altered flow control properties to include session-level limits.
	Added note on cacheability of pushed resources and multiple tenant		Added note on cacheability of pushed resources and multiple tenant
	servers.		servers.
	Changed protocol label form based on discussions.		Changed protocol label form based on discussions.
	A.7. Since draft-ietf-httpbis-http2-00		A.8. Since draft-ietf-httpbis-http2-00
	Changed title throughout.		Changed title throughout.
	Removed section on Incompatibilities with SPDY draft#2.		Removed section on Incompatibilities with SPDY draft#2.
	Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <https://		Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <https://
	groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU>.		groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU>.
	Replaced abstract and introduction.		Replaced abstract and introduction.
	Added section on starting HTTP/2.0, including upgrade mechanism.		Added section on starting HTTP/2.0, including upgrade mechanism.
	Removed unused references.		Removed unused references.
	Added flow control principles (Section 5.2.1) based on <http://		Added flow control principles (Section 5.2.1) based on <http://
	tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01>.		tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01>.
	A.8. Since draft-mbelshe-httpbis-spdy-00		A.9. Since draft-mbelshe-httpbis-spdy-00
	Adopted as base for draft-ietf-httpbis-http2.		Adopted as base for draft-ietf-httpbis-http2.
	Updated authors/editors list.		Updated authors/editors list.
	Added status note.		Added status note.
	Authors' Addresses		Authors' Addresses
	Mike Belshe		Mike Belshe
	skipping to change at page 62, line 23		skipping to change at page 62, line 23
	Google, Inc		Google, Inc
	EMail: fenix@google.com		EMail: fenix@google.com
	Martin Thomson (editor)		Martin Thomson (editor)
	Microsoft		Microsoft
	3210 Porter Drive		3210 Porter Drive
	Palo Alto 94304		Palo Alto 94304
	US		US
	EMail: martin.thomson@skype.net		EMail: martin.thomson@gmail.com
	Alexey Melnikov (editor)		Alexey Melnikov (editor)
	Isode Ltd		Isode Ltd
	5 Castle Business Village		5 Castle Business Village
	36 Station Road		36 Station Road
	Hampton, Middlesex TW12 2BX		Hampton, Middlesex TW12 2BX
	UK		UK
	EMail: Alexey.Melnikov@isode.com		EMail: Alexey.Melnikov@isode.com
End of changes. 43 change blocks.
	114 lines changed or deleted		116 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/