Re: IETF LC comments on draft-ietf-httpbis-header-compression-10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 11 January 2015 at 02:58, Julian Reschke <julian.reschke@xxxxxxxxxxxxx> wrote:

5.1.  Integer Representation


We have bad experience with making indentation in artwork significant; maybe introducing brackets would be a good idea.


(And all the Python advocates cry)



​​
   This integer representation allows for values of indefinite size.  It
   is also possible for an encoder to send a large number of zero
   values, which can waste octets and could be used to overflow integer
   values.  Excessively large integer encodings - in value or octet
   length - MUST be treated as a decoding error.  Different limits can
   be set for each of the different uses of integers, based on
   implementation constraints.

Having a MUST here when we don't say what "excessive" is seems like a bad idea.


This seems like a MAY -- explaining the error you receive, rather than telling you when to raise one.



5.2.  String Literal Representation

The figure could be interpreted as if the string length is always expressed in 7 bits, which I believe is not true.

6.2.1.  Literal Header Field with Incremental Indexing


See above. One can read this as "H" being bit 0 in the second octet; but that's not always the case. I think it would be good to revise the figure format.


It could help to add a line of just:   | ... |  below any (N+) element. Maybe.



--
  Matthew Kerwin
  http://matthew.kerwin.net.au/

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]