Re: [quicwg/base-drafts] Robert Wilton's QPACK Comment 3 (#4802)

[Robert Wilton <[e-mail]>]

If section 3.2.2 already imposes a limit on the length of an entry, then it would be good to referenced that text from section 7.4.

E.g. section 7.4 states:  `In
   the same way, it has to set a limit to the length it accepts for
   string literals; see Section 4.1.2.`

But I suspect that really the only limit that is needed here is the one in 3.2.2?  I.e. it seems reasonable that a receiver should accept any string up to the maximum table size?

But my other point is that it suggests that a receiver can arbitrarily choose to set a limit on the size of integers that it receives, but section 4.1.1 states: `   QPACK implementations MUST be able to decode integers up to and
   including 62 bits long.`

So, I guess that I'm really suggesting that this paragraph (in section 7.4):

`   An implementation has to set a limit for the values it accepts for
   integers, as well as for the encoded length; see Section 4.1.1.  In
   the same way, it has to set a limit to the length it accepts for
   string literals; see Section 4.1.2.`

is reworded to say something along the lines of:
- Receivers MUST accept integers up to 62 bits long section 4.1.1, but MAY choose to not handle larger integers, in which case they return QPACK_DECOMPRESSION_FAILED.
- Receivers MUST accept any strings up to maximum table length -32, or return QPACK_DECOMPRESSION_FAILED.

It wasn't clear to me whether integers bigger than 62 bits are ever likely in practice, I presume not ...


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4802#issuecomment-767744393