feedback for draft-ietf-httpbis-header-compression-01

Feedback for draft-ietf-httpbis-header-compression-01

Questions

"4.2.1 Integer representation

Integers are used to represent name indexes, pair indexes or string 
lengths. The integer representation keeps byte-alignment as much as 
possible as this allows various processing optimizations as well as 
efficient use of DEFLATE. For that purpose, an integer representation 
always finishes at the end of a byte."

The mention of DEFLATE is kind of surprising here.


"4.2.2 String literal representation

Literal strings can represent header names or header values. They are 
encoded in two parts:

     The string length, defined as the number of bytes needed to store 
its UTF-8 representation, is represented as an integer with a zero bits 
prefix. If the string length is strictly less than 128, it is 
represented as one byte.
     The string value represented as a list of UTF-8 characters."

By "list of UTF-8 characters" I assume you mean "octet sequence 
representing the UTF-8 encoding of the string"?

A more general question: the proposal handles header field values as 
character sequences, whereas in HTTP/1.1 they are really octet sequences 
with an unknown character encoding scheme. That is, if you see octets >= 
0x80 you really can't tell in general what they mean.

At some point we'll have to decide how to handle this problem.


"A. Initial header names"

These need review, even without real-world data. In particular, we 
shouldn't have deprecated fields such as Keep-Alive or Content-MD5 here.


Editorial

HTTP header -> HTTP header field

References: we really don't have any normative references???

Appendix B: avoid use of "X-" prefix; just call the header field 
"Example-Extension" or something like that.

Finally, shouldn't this draft be in SVN or github?

Best regards, Julian

Received on Wednesday, 31 July 2013 08:19:27 UTC