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>

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
*