HPACK: Header Compression for HTTP/2
RFC 7541

Note: This ballot was opened for revision 10 and is now closed.

(Jari Arkko) Yes

Comment (2015-01-22 for -10)
No email
send info
David Black's Gen-ART review raised the issue of never-indexed fields, and whether guidance or a list of header fields should be in the document to describe when this option should be used. Has the WG discussed this in the past, and what conclusion did it came to? Are there standardised header fields that would clearly be on such a list, if it were given in the document?

(Richard Barnes) Yes

Comment (2015-01-21 for -10)
No email
send info
Section 2.3.3: "Indices between 1 and the length of the static table..."
The use of 1-based indexing here seems likely to lead to incompatibilities.

Section 3:
Currently, you never say explicitly that a header block is the concatenation of encoded header fields, where each field is encoded according to Section 6.  This would be a good spot to do that.

Section 5.1: "... always finishes at the end of an octet"
It was not immediately clear to me that the "?" bits indicated that an integer need not *begin* at an octet boundary.  It would be helpful to note that here.

(Stephen Farrell) Yes

Comment (2015-01-22 for -10)
No email
send info

Excellent stuff! A well-written clear description of a 
reasonably complex thing.

Barry Leiba Yes

(Kathleen Moriarty) Yes

Comment (2015-01-21 for -10)
No email
send info
Thank you for your work on this draft and for the thorough security considerations section.  I do agree with the SecDir reviewer that an early reference to the security considerations section would be useful, please consider adding that.

http://www.ietf.org/mail-archive/web/secdir/current/msg05406.html

Another good point is that while this draft addresses current threats (CRIME), the WG should keep in mind that the attacks could evolve.  This is really just to think ahead with options since HPACK is a relatively new algorithm, and since encryption of compressed headers is known to be somewhat perilous.  It is possible that a clever attacker will develop a new attack in the future (i.e., CRIME++ ) that works against HPACK-compressed header fields.

(Alia Atlas) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2015-01-22 for -10)
No email
send info
Similar to Jari's COMMENT.
David Black, part of the combined OPS/GEN-ART review (http://www.ietf.org/mail-archive/web/gen-art/current/msg11197.html) mentions:

The second major issue looks serious - one of the major motivations
for HPACK is to mitigate attacks on DEFLATE (e.g., CRIME) via use of never
indexed fields wrt compression.  The absence of a list of header fields
that MUST use that never indexed functionality appears to be a serious
oversight.

This point was discussed during the IESG telechat and, according to the Sec ADs, this is not an issue: list of header that should never be compressed, will change in response to the attach. Stephen and Kathleen will follow up on the list.

Alissa Cooper No Objection

Comment (2015-01-21 for -10)
No email
send info
My one question about this was about lack of extensibility of the static table, but I see that some intro text has been added to the editor's copy of the document <http://http2.github.io/http2-spec/compression.html> that speaks to this. Keeping that text would be good imo.

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Ted Lemon) No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

Comment (2015-01-21 for -10)
No email
send info
I just wonder if there is a second implementation, the shepherd report is pointing out one.