draft-ietf-quic-qpack-14.txt		draft-ietf-quic-qpack-latest.txt
	QUIC Working Group C. Krasic		QUIC Working Group C. Krasic
	Internet-Draft Netflix		Internet-Draft Netflix
	Intended status: Standards Track M. Bishop		Intended status: Standards Track M. Bishop
	Expires: August 24, 2020 Akamai Technologies		Expires: October 3, 2020 Akamai Technologies
	A. Frindell, Ed.		A. Frindell, Ed.
	Facebook		Facebook
	February 21, 2020		April 1, 2020
	QPACK: Header Compression for HTTP/3		QPACK: Header Compression for HTTP/3
	draft-ietf-quic-qpack-14		draft-ietf-quic-qpack-latest
	Abstract		Abstract
	This specification defines QPACK, a compression format for		This specification defines QPACK, a compression format for
	efficiently representing HTTP header fields, to be used in HTTP/3.		efficiently representing HTTP header fields, to be used in HTTP/3.
	This is a variation of HPACK header compression that seeks to reduce		This is a variation of HPACK header compression that seeks to reduce
	head-of-line blocking.		head-of-line blocking.
	Note to Readers		Note to Readers
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 August 24, 2020.		This Internet-Draft will expire on October 3, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4		1.1. Conventions and Definitions . . . . . . . . . . . . . . . 4
	1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5		1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5
	2. Compression Process Overview . . . . . . . . . . . . . . . . 5		2. Compression Process Overview . . . . . . . . . . . . . . . . 5
	2.1. Encoder . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Encoder . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.1. Reference Tracking . . . . . . . . . . . . . . . . . 6		2.1.1. Limits on Dynamic Table Insertions . . . . . . . . . 6
	2.1.2. Limits on Dynamic Table Insertions . . . . . . . . . 6		2.1.2. Blocked Streams . . . . . . . . . . . . . . . . . . . 7
	2.1.3. Blocked Streams . . . . . . . . . . . . . . . . . . . 7		2.1.3. Avoiding Flow Control Deadlocks . . . . . . . . . . . 8
	2.1.4. Avoiding Flow Control Deadlocks . . . . . . . . . . . 8		2.1.4. Known Received Count . . . . . . . . . . . . . . . . 8
	2.1.5. Known Received Count . . . . . . . . . . . . . . . . 8		2.2. Decoder . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.2. Decoder . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.2.1. Blocked Decoding . . . . . . . . . . . . . . . . . . 9		2.2.1. Blocked Decoding . . . . . . . . . . . . . . . . . . 9
	2.2.2. State Synchronization . . . . . . . . . . . . . . . . 9		2.2.2. State Synchronization . . . . . . . . . . . . . . . . 9
	2.2.3. Invalid References . . . . . . . . . . . . . . . . . 10		2.2.3. Invalid References . . . . . . . . . . . . . . . . . 10
	3. Header Tables . . . . . . . . . . . . . . . . . . . . . . . . 11		3. Header Tables . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.1. Static Table . . . . . . . . . . . . . . . . . . . . . . 11		3.1. Static Table . . . . . . . . . . . . . . . . . . . . . . 11
	3.2. Dynamic Table . . . . . . . . . . . . . . . . . . . . . . 11		3.2. Dynamic Table . . . . . . . . . . . . . . . . . . . . . . 11
	3.2.1. Dynamic Table Size . . . . . . . . . . . . . . . . . 11		3.2.1. Dynamic Table Size . . . . . . . . . . . . . . . . . 11
	3.2.2. Dynamic Table Capacity and Eviction . . . . . . . . . 12		3.2.2. Dynamic Table Capacity and Eviction . . . . . . . . . 12
	3.2.3. Maximum Dynamic Table Capacity . . . . . . . . . . . 12		3.2.3. Maximum Dynamic Table Capacity . . . . . . . . . . . 12
	3.2.4. Absolute Indexing . . . . . . . . . . . . . . . . . . 13		3.2.4. Absolute Indexing . . . . . . . . . . . . . . . . . . 13
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 5 ¶
	An encoder MAY insert any entry in the dynamic table it chooses; it		An encoder MAY insert any entry in the dynamic table it chooses; it
	is not limited to header fields it is compressing.		is not limited to header fields it is compressing.
	QPACK preserves the ordering of header fields within each header		QPACK preserves the ordering of header fields within each header
	list. An encoder MUST emit header field representations in the order		list. An encoder MUST emit header field representations in the order
	they appear in the input header list.		they appear in the input header list.
	QPACK is designed to contain the more complex state tracking to the		QPACK is designed to contain the more complex state tracking to the
	encoder, while the decoder is relatively simple.		encoder, while the decoder is relatively simple.
	2.1.1. Reference Tracking		2.1.1. Limits on Dynamic Table Insertions
	An encoder MUST ensure that a header block which references a dynamic
	table entry is not processed by the decoder after the referenced
	entry has been evicted. Hence the encoder needs to retain
	information about each compressed header block that references the
	dynamic table until that header block is acknowledged by the decoder;
	see Section 4.4.1.
	2.1.2. Limits on Dynamic Table Insertions
	Inserting entries into the dynamic table might not be possible if the		Inserting entries into the dynamic table might not be possible if the
	table contains entries which cannot be evicted.		table contains entries which cannot be evicted.
	A dynamic table entry cannot be evicted immediately after insertion,		A dynamic table entry cannot be evicted immediately after insertion,
	even if it has never been referenced. Once the insertion of a		even if it has never been referenced. Once the insertion of a
	dynamic table entry has been acknowledged and there are no		dynamic table entry has been acknowledged and there are no
	outstanding unacknowledged references to the entry, the entry becomes		outstanding references to the entry in unacknowledged header blocks,
	evictable.		the entry becomes evictable. Note that references on the encoder
			stream never preclude the eviction of an entry, because those
			references are guaranteed to be processed before the instruction
			evicting the entry.
	If the dynamic table does not contain enough room for a new entry		If the dynamic table does not contain enough room for a new entry
	without evicting other entries, and the entries which would be		without evicting other entries, and the entries which would be
	evicted are not evictable, the encoder MUST NOT insert that entry		evicted are not evictable, the encoder MUST NOT insert that entry
	into the dynamic table (including duplicates of existing entries).		into the dynamic table (including duplicates of existing entries).
	In order to avoid this, an encoder that uses the dynamic table has to		In order to avoid this, an encoder that uses the dynamic table has to
	keep track of whether each entry is currently evictable or not.		keep track of each dynamic table entry referenced by each header
			block until that header block is acknowledged by the decoder (see
			Section 4.4.1).
	2.1.2.1. Avoiding Prohibited Insertions		2.1.1.1. Avoiding Prohibited Insertions
	To ensure that the encoder is not prevented from adding new entries,		To ensure that the encoder is not prevented from adding new entries,
	the encoder can avoid referencing entries that are close to eviction.		the encoder can avoid referencing entries that are close to eviction.
	Rather than reference such an entry, the encoder can emit a Duplicate		Rather than reference such an entry, the encoder can emit a Duplicate
	instruction (Section 4.3.4), and reference the duplicate instead.		instruction (Section 4.3.4), and reference the duplicate instead.
	Determining which entries are too close to eviction to reference is		Determining which entries are too close to eviction to reference is
	an encoder preference. One heuristic is to target a fixed amount of		an encoder preference. One heuristic is to target a fixed amount of
	available space in the dynamic table: either unused space or space		available space in the dynamic table: either unused space or space
	that can be reclaimed by evicting non-blocking entries. To achieve		that can be reclaimed by evicting non-blocking entries. To achieve
	skipping to change at page 7, line 21 ¶		skipping to change at page 7, line 16 ¶
	| Draining | Referenceable | Unused |		| Draining | Referenceable | Unused |
	| Entries | Entries | Space |		| Entries | Entries | Space |
	+----------+---------------------------------+--------+		+----------+---------------------------------+--------+
	^ ^ ^		^ ^ ^
	| | |		| | |
	Dropping Draining Index Insertion Point		Dropping Draining Index Insertion Point
	Point		Point
	Figure 1: Draining Dynamic Table Entries		Figure 1: Draining Dynamic Table Entries
	2.1.3. Blocked Streams		2.1.2. Blocked Streams
	Because QUIC does not guarantee order between data on different		Because QUIC does not guarantee order between data on different
	streams, a decoder might encounter a header block that references a		streams, a decoder might encounter a header block that references a
	dynamic table entry that it has not yet received.		dynamic table entry that it has not yet received.
	Each header block contains a Required Insert Count (Section 4.5.1),		Each header block contains a Required Insert Count (Section 4.5.1),
	the lowest possible value for the Insert Count with which the header		the lowest possible value for the Insert Count with which the header
	block can be decoded. For a header block with references to the		block can be decoded. For a header block with references to the
	dynamic table, the Required Insert Count is one larger than the		dynamic table, the Required Insert Count is one larger than the
	largest absolute index of all referenced dynamic table entries. For		largest absolute index of all referenced dynamic table entries. For
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 7 ¶
	If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS,		If permitted by the value of SETTINGS_QPACK_BLOCKED_STREAMS,
	compression efficiency can often be improved by referencing dynamic		compression efficiency can often be improved by referencing dynamic
	table entries that are still in transit, but if there is loss or		table entries that are still in transit, but if there is loss or
	reordering the stream can become blocked at the decoder. An encoder		reordering the stream can become blocked at the decoder. An encoder
	can avoid the risk of blocking by only referencing dynamic table		can avoid the risk of blocking by only referencing dynamic table
	entries which have been acknowledged, but this could mean using		entries which have been acknowledged, but this could mean using
	literals. Since literals make the header block larger, this can		literals. Since literals make the header block larger, this can
	result in the encoder becoming blocked on congestion or flow control		result in the encoder becoming blocked on congestion or flow control
	limits.		limits.
	2.1.4. Avoiding Flow Control Deadlocks		2.1.3. Avoiding Flow Control Deadlocks
	Writing instructions on streams that are limited by flow control can		Writing instructions on streams that are limited by flow control can
	produce deadlocks.		produce deadlocks.
	A decoder might stop issuing flow control credit on the stream that		A decoder might stop issuing flow control credit on the stream that
	carries a header block until the necessary updates are received on		carries a header block until the necessary updates are received on
	the encoder stream. If the granting of flow control credit on the		the encoder stream. If the granting of flow control credit on the
	encoder stream (or the connection as a whole) depends on the		encoder stream (or the connection as a whole) depends on the
	consumption and release of data on the stream carrying the header		consumption and release of data on the stream carrying the header
	block, a deadlock might result.		block, a deadlock might result.
	More generally, a stream containing a large instruction can become		More generally, a stream containing a large instruction can become
	deadlocked if the decoder withholds flow control credit until the		deadlocked if the decoder withholds flow control credit until the
	instruction is completely received.		instruction is completely received.
	To avoid these deadlocks, an encoder SHOULD avoid writing an		To avoid these deadlocks, an encoder SHOULD avoid writing an
	instruction unless sufficient stream and connection flow control		instruction unless sufficient stream and connection flow control
	credit is available for the entire instruction.		credit is available for the entire instruction.
	2.1.5. Known Received Count		2.1.4. Known Received Count
	The Known Received Count is the total number of dynamic table		The Known Received Count is the total number of dynamic table
	insertions and duplications acknowledged by the decoder. The encoder		insertions and duplications acknowledged by the decoder. The encoder
	tracks the Known Received Count in order to identify which dynamic		tracks the Known Received Count in order to identify which dynamic
	table entries can be referenced without potentially blocking a		table entries can be referenced without potentially blocking a
	stream. The decoder tracks the Known Received Count in order to be		stream. The decoder tracks the Known Received Count in order to be
	able to send Insert Count Increment instructions.		able to send Insert Count Increment instructions.
	A Header Acknowledgement instruction (Section 4.4.1) implies that the		A Header Acknowledgement instruction (Section 4.4.1) implies that the
	decoder has received all dynamic table state necessary to process		decoder has received all dynamic table state necessary to process
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 27 ¶
	immediately. Otherwise, the stream on which the header block was		immediately. Otherwise, the stream on which the header block was
	received becomes blocked.		received becomes blocked.
	While blocked, header block data SHOULD remain in the blocked		While blocked, header block data SHOULD remain in the blocked
	stream's flow control window. A stream becomes unblocked when the		stream's flow control window. A stream becomes unblocked when the
	Insert Count becomes greater than or equal to the Required Insert		Insert Count becomes greater than or equal to the Required Insert
	Count for all header blocks the decoder has started reading from the		Count for all header blocks the decoder has started reading from the
	stream.		stream.
	When processing header blocks, the decoder expects the Required		When processing header blocks, the decoder expects the Required
	Insert Count to exactly match the value defined in Section 2.1.3. If		Insert Count to equal the lowest possible value for the Insert Count
	it encounters a smaller value than expected, it MUST treat this as a		with which the header block can be decoded, as prescribed in
	connection error of type QPACK_DECOMPRESSION_FAILED; see		Section 2.1.2. If it encounters a Required Insert Count smaller than
	Section 2.2.3. If it encounters a larger value than expected, it MAY		expected, it MUST treat this as a connection error of type
	treat this as a connection error of type QPACK_DECOMPRESSION_FAILED.		QPACK_DECOMPRESSION_FAILED; see Section 2.2.3. If it encounters a
			Required Insert Count larger than expected, it MAY treat this as a
			connection error of type QPACK_DECOMPRESSION_FAILED.
	2.2.2. State Synchronization		2.2.2. State Synchronization
	The decoder signals the following events by emitting decoder		The decoder signals the following events by emitting decoder
	instructions (Section 4.4) on the decoder stream.		instructions (Section 4.4) on the decoder stream.
	2.2.2.1. Completed Processing of a Header Block		2.2.2.1. Completed Processing of a Header Block
	After the decoder finishes decoding a header block containing dynamic		After the decoder finishes decoding a header block containing dynamic
	table references, it MUST emit a Header Acknowledgement instruction		table references, it MUST emit a Header Acknowledgement instruction
	skipping to change at page 10, line 22 ¶		skipping to change at page 10, line 22 ¶
	outstanding. A decoder with a maximum dynamic table capacity		outstanding. A decoder with a maximum dynamic table capacity
	(Section 3.2.3) equal to zero MAY omit sending Stream Cancellations,		(Section 3.2.3) equal to zero MAY omit sending Stream Cancellations,
	because the encoder cannot have any dynamic table references. An		because the encoder cannot have any dynamic table references. An
	encoder cannot infer from this instruction that any updates to the		encoder cannot infer from this instruction that any updates to the
	dynamic table have been received.		dynamic table have been received.
	The Header Acknowledgement and Stream Cancellation instructions		The Header Acknowledgement and Stream Cancellation instructions
	permit the encoder to remove references to entries in the dynamic		permit the encoder to remove references to entries in the dynamic
	table. When an entry with absolute index lower than the Known		table. When an entry with absolute index lower than the Known
	Received Count has zero references, then it is considered evictable;		Received Count has zero references, then it is considered evictable;
	see Section 2.1.2.		see Section 2.1.1.
	2.2.2.3. New Table Entries		2.2.2.3. New Table Entries
	After receiving new table entries on the encoder stream, the decoder		After receiving new table entries on the encoder stream, the decoder
	chooses when to emit Insert Count Increment instructions; see		chooses when to emit Insert Count Increment instructions; see
	Section 4.4.3. Emitting this instruction after adding each new		Section 4.4.3. Emitting this instruction after adding each new
	dynamic table entry will provide the timeliest feedback to the		dynamic table entry will provide the timeliest feedback to the
	encoder, but could be redundant with other decoder feedback. By		encoder, but could be redundant with other decoder feedback. By
	delaying an Insert Count Increment instruction, the decoder might be		delaying an Insert Count Increment instruction, the decoder might be
	able to coalesce multiple Insert Count Increment instructions, or		able to coalesce multiple Insert Count Increment instructions, or
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 17 ¶
	The encoder sets the capacity of the dynamic table, which serves as		The encoder sets the capacity of the dynamic table, which serves as
	the upper limit on its size. The initial capacity of the dynamic		the upper limit on its size. The initial capacity of the dynamic
	table is zero. The encoder sends a Set Dynamic Table Capacity		table is zero. The encoder sends a Set Dynamic Table Capacity
	instruction (Section 4.3.1) with a non-zero capacity to begin using		instruction (Section 4.3.1) with a non-zero capacity to begin using
	the dynamic table.		the dynamic table.
	Before a new entry is added to the dynamic table, entries are evicted		Before a new entry is added to the dynamic table, entries are evicted
	from the end of the dynamic table until the size of the dynamic table		from the end of the dynamic table until the size of the dynamic table
	is less than or equal to (table capacity - size of new entry). The		is less than or equal to (table capacity - size of new entry). The
	encoder MUST NOT cause a dynamic table entry to be evicted unless		encoder MUST NOT cause a dynamic table entry to be evicted unless
	that entry is evictable; see Section 2.1.2. The new entry is then		that entry is evictable; see Section 2.1.1. The new entry is then
	added to the table. It is an error if the encoder attempts to add an		added to the table. It is an error if the encoder attempts to add an
	entry that is larger than the dynamic table capacity; the decoder		entry that is larger than the dynamic table capacity; the decoder
	MUST treat this as a connection error of type		MUST treat this as a connection error of type
	QPACK_ENCODER_STREAM_ERROR.		QPACK_ENCODER_STREAM_ERROR.
	A new entry can reference an entry in the dynamic table that will be		A new entry can reference an entry in the dynamic table that will be
	evicted when adding this new entry into the dynamic table.		evicted when adding this new entry into the dynamic table.
	Implementations are cautioned to avoid deleting the referenced name		Implementations are cautioned to avoid deleting the referenced name
	or value if the referenced entry is evicted from the dynamic table		or value if the referenced entry is evicted from the dynamic table
	prior to inserting the new entry.		prior to inserting the new entry.
	skipping to change at page 16, line 8 ¶		skipping to change at page 16, line 8 ¶
	carries an unframed sequence of encoder instructions from encoder		carries an unframed sequence of encoder instructions from encoder
	to decoder.		to decoder.
	o A decoder stream is a unidirectional stream of type "0x03". It		o A decoder stream is a unidirectional stream of type "0x03". It
	carries an unframed sequence of decoder instructions from decoder		carries an unframed sequence of decoder instructions from decoder
	to encoder.		to encoder.
	HTTP/3 endpoints contain a QPACK encoder and decoder. Each endpoint		HTTP/3 endpoints contain a QPACK encoder and decoder. Each endpoint
	MUST initiate at most one encoder stream and at most one decoder		MUST initiate at most one encoder stream and at most one decoder
	stream. Receipt of a second instance of either stream type MUST be		stream. Receipt of a second instance of either stream type MUST be
	treated as a connection error of type HTTP_STREAM_CREATION_ERROR.		treated as a connection error of type H3_STREAM_CREATION_ERROR.
	These streams MUST NOT be closed. Closure of either unidirectional		These streams MUST NOT be closed. Closure of either unidirectional
	stream type MUST be treated as a connection error of type		stream type MUST be treated as a connection error of type
	HTTP_CLOSED_CRITICAL_STREAM.		H3_CLOSED_CRITICAL_STREAM.
	An endpoint MAY avoid creating an encoder stream if it's not going to		An endpoint MAY avoid creating an encoder stream if it's not going to
	be used (for example if its encoder doesn't wish to use the dynamic		be used (for example if its encoder doesn't wish to use the dynamic
	table, or if the maximum size of the dynamic table permitted by the		table, or if the maximum size of the dynamic table permitted by the
	peer is zero).		peer is zero).
	An endpoint MAY avoid creating a decoder stream if its decoder sets		An endpoint MAY avoid creating a decoder stream if its decoder sets
	the maximum capacity of the dynamic table to zero.		the maximum capacity of the dynamic table to zero.
	An endpoint MUST allow its peer to create an encoder stream and a		An endpoint MUST allow its peer to create an encoder stream and a
	skipping to change at page 17, line 11 ¶		skipping to change at page 17, line 11 ¶
	The new capacity MUST be lower than or equal to the limit described		The new capacity MUST be lower than or equal to the limit described
	in Section 3.2.3. In HTTP/3, this limit is the value of the		in Section 3.2.3. In HTTP/3, this limit is the value of the
	SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter (Section 5) received from		SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter (Section 5) received from
	the decoder. The decoder MUST treat a new dynamic table capacity		the decoder. The decoder MUST treat a new dynamic table capacity
	value that exceeds this limit as a connection error of type		value that exceeds this limit as a connection error of type
	QPACK_ENCODER_STREAM_ERROR.		QPACK_ENCODER_STREAM_ERROR.
	Reducing the dynamic table capacity can cause entries to be evicted;		Reducing the dynamic table capacity can cause entries to be evicted;
	see Section 3.2.2. This MUST NOT cause the eviction of entries which		see Section 3.2.2. This MUST NOT cause the eviction of entries which
	are not evictable; see Section 2.1.2. Changing the capacity of the		are not evictable; see Section 2.1.1. Changing the capacity of the
	dynamic table is not acknowledged as this instruction does not insert		dynamic table is not acknowledged as this instruction does not insert
	an entry.		an entry.
	4.3.2. Insert With Name Reference		4.3.2. Insert With Name Reference
	An encoder adds an entry to the dynamic table where the header field		An encoder adds an entry to the dynamic table where the header field
	name matches the header field name of an entry stored in the static		name matches the header field name of an entry stored in the static
	or the dynamic table using an instruction that starts with the '1'		or the dynamic table using an instruction that starts with the '1'
	one-bit pattern. The second ('T') bit indicates whether the		one-bit pattern. The second ('T') bit indicates whether the
	reference is to the static or dynamic table. The 6-bit prefix		reference is to the static or dynamic table. The 6-bit prefix
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 5 ¶
	This section specifies the following decoder instructions.		This section specifies the following decoder instructions.
	4.4.1. Header Acknowledgement		4.4.1. Header Acknowledgement
	After processing a header block whose declared Required Insert Count		After processing a header block whose declared Required Insert Count
	is not zero, the decoder emits a Header Acknowledgement instruction.		is not zero, the decoder emits a Header Acknowledgement instruction.
	The instruction begins with the '1' one-bit pattern which is followed		The instruction begins with the '1' one-bit pattern which is followed
	by the header block's associated stream ID encoded as a 7-bit prefix		by the header block's associated stream ID encoded as a 7-bit prefix
	integer; see Section 4.1.1.		integer; see Section 4.1.1.
	This instruction is used as described in Section 2.1.5 and in		This instruction is used as described in Section 2.1.4 and in
	Section 2.2.2.		Section 2.2.2.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| 1 | Stream ID (7+) |		| 1 | Stream ID (7+) |
	+---+---------------------------+		+---+---------------------------+
	Figure 4: Header Acknowledgement		Figure 4: Header Acknowledgement
	If an encoder receives a Header Acknowledgement instruction referring		If an encoder receives a Header Acknowledgement instruction referring
	to a stream on which every header block with a non-zero Required		to a stream on which every header block with a non-zero Required
	Insert Count has already been acknowledged, that MUST be treated as a		Insert Count has already been acknowledged, that MUST be treated as a
	connection error of type QPACK_DECODER_STREAM_ERROR.		connection error of type QPACK_DECODER_STREAM_ERROR.
	The Header Acknowledgement instruction might increase the Known		The Header Acknowledgement instruction might increase the Known
	Received Count; see Section 2.1.5.		Received Count; see Section 2.1.4.
	4.4.2. Stream Cancellation		4.4.2. Stream Cancellation
	When a stream is reset or reading is abandoned, the decoder emits a		When a stream is reset or reading is abandoned, the decoder emits a
	Stream Cancellation instruction. The instruction begins with the		Stream Cancellation instruction. The instruction begins with the
	'01' two-bit pattern, which is followed by the stream ID of the		'01' two-bit pattern, which is followed by the stream ID of the
	affected stream encoded as a 6-bit prefix integer.		affected stream encoded as a 6-bit prefix integer.
	This instruction is used as described in Section 2.2.2.		This instruction is used as described in Section 2.2.2.
	skipping to change at page 19, line 43 ¶		skipping to change at page 19, line 43 ¶
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| 0 | 1 | Stream ID (6+) |		| 0 | 1 | Stream ID (6+) |
	+---+---+-----------------------+		+---+---+-----------------------+
	Figure 5: Stream Cancellation		Figure 5: Stream Cancellation
	4.4.3. Insert Count Increment		4.4.3. Insert Count Increment
	The Insert Count Increment instruction begins with the '00' two-bit		The Insert Count Increment instruction begins with the '00' two-bit
	pattern, followed by the Increment encoded as a 6-bit prefix integer.		pattern, followed by the Increment encoded as a 6-bit prefix integer.
	This instruction increases the Known Received Count (Section 2.1.5)		This instruction increases the Known Received Count (Section 2.1.4)
	by the value of the Increment parameter. The decoder should send an		by the value of the Increment parameter. The decoder should send an
	Increment value that increases the Known Received Count to the total		Increment value that increases the Known Received Count to the total
	number of dynamic table insertions and duplications processed so far.		number of dynamic table insertions and duplications processed so far.
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+
	| 0 | 0 | Increment (6+) |		| 0 | 0 | Increment (6+) |
	+---+---+-----------------------+		+---+---+-----------------------+
	Figure 6: Insert Count Increment		Figure 6: Insert Count Increment
	skipping to change at page 26, line 34 ¶		skipping to change at page 26, line 34 ¶
	5. Configuration		5. Configuration
	QPACK defines two settings which are included in the HTTP/3 SETTINGS		QPACK defines two settings which are included in the HTTP/3 SETTINGS
	frame.		frame.
	SETTINGS_QPACK_MAX_TABLE_CAPACITY (0x1): The default value is zero.		SETTINGS_QPACK_MAX_TABLE_CAPACITY (0x1): The default value is zero.
	See Section 3.2 for usage. This is the equivalent of the		See Section 3.2 for usage. This is the equivalent of the
	SETTINGS_HEADER_TABLE_SIZE from HTTP/2.		SETTINGS_HEADER_TABLE_SIZE from HTTP/2.
	SETTINGS_QPACK_BLOCKED_STREAMS (0x7): The default value is zero.		SETTINGS_QPACK_BLOCKED_STREAMS (0x7): The default value is zero.
	See Section 2.1.3.		See Section 2.1.2.
	6. Error Handling		6. Error Handling
	The following error codes are defined for HTTP/3 to indicate failures		The following error codes are defined for HTTP/3 to indicate failures
	of QPACK which prevent the connection from continuing:		of QPACK which prevent the connection from continuing:
	QPACK_DECOMPRESSION_FAILED (0x200): The decoder failed to interpret		QPACK_DECOMPRESSION_FAILED (0x200): The decoder failed to interpret
	a header block and is not able to continue decoding that header		a header block and is not able to continue decoding that header
	block.		block.
	skipping to change at page 28, line 32 ¶		skipping to change at page 28, line 32 ¶
	| QPACK_DECODER_STREAM_ERRO | 0x202 | Error on the | Section 6 |		| QPACK_DECODER_STREAM_ERRO | 0x202 | Error on the | Section 6 |
	| R | | decoder | |		| R | | decoder | |
	| | | stream | |		| | | stream | |
	+---------------------------+-------+---------------+---------------+		+---------------------------+-------+---------------+---------------+
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3		[HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
	(HTTP/3)", draft-ietf-quic-http-27 (work in progress).		(HTTP/3)", draft-ietf-quic-http-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-27 (work in progress).		transport-latest (work in progress).
	[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>.
	[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for		[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
	HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,		HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
	<https://www.rfc-editor.org/info/rfc7541>.		<https://www.rfc-editor.org/info/rfc7541>.
End of changes. 25 change blocks.
	44 lines changed or deleted		41 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/