W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: HPACK, Draft 09, Integer Representation

From: Pavel Rappo <pavel.rappo@gmail.com>
Date: Thu, 28 Aug 2014 17:00:08 +0100
Message-ID: <CAChcVunxXfsZJfGSC4OS=OyE-fBnaKqtXArwU6JvoxkAU_v8dg@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> HPACK uses little endian.

I think this difference should be mentioned explicitly.

> "I" is updated while loop:
>
>        repeat
>            B = next octet
>            I = I + (B & 127) * 2^M
>
>                      ~~~~~~~~~~~~~~~~~~~~~
>            M = M + 7
>        while B & 128 == 128
>
> So, initial "I" is not forgotten.

Thanks, Tatsuhiro! It's indeed updated. I overlooked it.

> "I" comes from next N bits as algorithm exactly says:
>
>
> decode I from the next N bits
>
> HPACK integer encoding uses specific prefix bits, which is described as N
> here in algorithm.
> So when decoding integer encoded with 7 prefix bits, decode initial "I" from
> next 7 bits.

The only thing then, the meaning of "I" is different for the encoding
and decoding parts. Isn't it?
"The algorithm to represent an integer I is as follows:" and "For
informational purpose, the algorithm to decode an integer I is as
follows:". i.e. same "I" different meanings.

On Thu, Aug 28, 2014 at 4:42 PM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com> wrote:
>
>
>
> On Fri, Aug 29, 2014 at 12:25 AM, Pavel Rappo <pavel.rappo@gmail.com> wrote:
>>
>> Hi everyone,
>>
>> I have several questions regarding Integer Representation, if you don't
>> mind.
>>
>> (1) First of all, the section "6.1. Integer Representation" contains a
>> link to Wikipedia's VLQ article. The article states that: "...The VLQ
>> octets are arranged most significant first in a stream..." (Big Endian
>> from the byte stream point of view). On the other hand (from what I
>> understand), encoding/decoding algorithms described in the HPACK draft
>> works exactly the opposite -- they assume Little Endian:
>>
>> decode I from the next N bits
>>    if I < 2^N - 1, return I
>>    else
>>        M = 0
>>        repeat
>>            B = next octet
>>            I = I + (B & 127) * 2^M (*)
>>            M = M + 7
>>        while B & 128 == 128
>>        return I
>>
>> In other words there is: I = I + (B & 127) * 2^M instead of I = I* 2^M
>> + (B & 127).
>> Either there's an error in the draft or I'm not getting it right. So
>> which one is it?
>
>
> HPACK uses little endian.
>
>
>>
>> (2) The second question is this. Does the decoding algorithm "forget"
>> to add (2^N - 1) to the result in the end?
>> ...
>>        while B & 128 == 128
>>        return I + 2^N - 1
>>
>
> "I" is updated while loop:
>
>        repeat
>            B = next octet
>            I = I + (B & 127) * 2^M
>
>                      ~~~~~~~~~~~~~~~~~~~~~
>            M = M + 7
>        while B & 128 == 128
>
> So, initial "I" is not forgotten.
>
>
>>
>> though encoding one "remembers" to do this:
>>
>> if I < 2^N - 1, encode I on N bits
>>    else
>> (*)   encode (2^N - 1) on N bits
>>        I = I - (2^N - 1)
>>        while I >= 128
>>             encode (I % 128 + 128) on 8 bits
>>             I = I / 128
>>        encode I on 8 bits
>>
>> (3) And the third question is a minor one. When decoding algorithm
>> mentions "I", which "I" exactly is that?
>>
>> decode I from the next N bits
>>    if I < 2^N - 1, return I (*)
>> ...
>
>
> "I" comes from next N bits as algorithm exactly says:
>
>
> decode I from the next N bits
>
> HPACK integer encoding uses specific prefix bits, which is described as N
> here in algorithm.
> So when decoding integer encoded with 7 prefix bits, decode initial "I" from
> next 7 bits.
>
> Best regards,
> Tatsuhiro Tsujikawa
>
>
>>
>>
>> If I'm not mistaken, we don't know it in that point. The whole purpose
>> of this code snippet is to get the "I".
>>
>> -Pavel
>>
>
Received on Thursday, 28 August 2014 16:01:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC