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

On 11 January 2015 at 02:58, Julian Reschke <julian.reschke@greenbytes.de>
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/