Original text:
1. <del> This document describes HPACK, a format adapted to efficiently represent HTTP header fields in the context of HTTP/2 (see HTTP2). </del>  2. <del> In HTTP (see HTTP-p1), header fields are sent without any form of </del>  compression.  As web pages have grown to include dozens to hundreds <del> of requests, the redundant header fields in these requests now pose a problem of measurable latency and unnecessary bandwidth (see PERF1 and PERF2). </del>  SPDY initially addressed this redundancy by compressing header fields <del> with Deflate, which proved very effective at eliminating the redundant header fields.  However, that approach exposed a security risk as demonstrated by the CRIME. </del>  This document describes HPACK, a new compressor for header fields which eliminates redundant header fields, is not vulnerable to known <del> security attacks, and which also has a bounded memory cost for use in constrained environments. </del>  2.1. <del> The HTTP header field encoding described in this document is based on a header table that map name-value pairs to index values.  Header tables are incrementally updated during the HTTP/2 session. </del>  <del> The encoder is responsible for deciding which header fields to insert as new entries in the header table.  The decoder then does exactly what the encoder prescribes, ending in a state that exactly matches the encoder's state.  This enables decoders to remain simple and understand a wide variety of encoders. </del>  As two consecutive sets of header fields often have header fields in <del> common, each set of header fields is coded as a difference from the previous set of header fields.  The goal is to only encode the changes (header fields present in one of the set and not in the other) between the two sets of header fields. HTTP header field compression treats a set of header fields as an unordered collection of name-value pairs.  Names and values are opaque sequences of octets.  The order of header fields is not guaranteed to be preserved after being compressed and decompressed. </del>  Examples illustrating the use of these different mechanisms to represent header fields are available in examples.

Reviewer comments:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Revised text:
1.  <ins> This specification defines HPACK, a compression format for efficiently representing HTTP header fields in the context of HTTP/2 (see HTTP2). </ins> 2.  <ins> In HTTP (see HTTP-p1), header fields are encoded without any form of </ins> compression.  As web pages have grown to include dozens to hundreds  <ins> of requests, the redundant header fields in these requests now measurably increase latency and unnecessarily consume bandwidth (see PERF1 and PERF2). </ins> SPDY initially addressed this redundancy by compressing header fields  <ins> using the "deflate" format DEFLATE, which proved very effective at efficiently representing the redundant header fields.  However, that approach exposed a security risk as demonstrated by the CRIME attack. </ins> This document describes HPACK, a new compressor for header fields which eliminates redundant header fields, is not vulnerable to known  <ins> security attacks, and which also has a bounded memory requirement for use in constrained environments. </ins> 2.1.  <ins> The HTTP header field encoding defined in this document is based on a header table that maps name-value pairs to index values.  The header table is incrementally updated during the HTTP/2 connection. </ins>  <ins> A set of header fields is treated as an unordered collection of name- value pairs.  Names and values are considered to be opaque sequences of octets.  The order of header fields is not guaranteed to be perserved after being compressed and decompressed. </ins> As two consecutive sets of header fields often have header fields in  <ins> common, each set is coded as a difference from the previous set.  The goal is to only encoded the changes (header fields present in one of the sets that are absent from the other) between the two sets of header fields. The encoder represents a header field either literally or with a reference to a name-value pair in the header table.  A set of header fields is stored as a set of references to entries in the header table.  Differences between consecutive sets of header fields are encoded as changes to the set of references.  The encoder is responsible for deciding which header fields to insert as new entries in the header table.  The decoder executes the modifications to the header table and reference set perscribed by the encoder, reconstructing the set of header fields in the process.  This enables decoders to remain simple and understand a wide variety of encoders. </ins> Examples illustrating the use of these different mechanisms to represent header fields are available in examples.