RE: Feedback from first read of QUIC/HTTP draft 08

[Mikkel Fahnøe Jørgensen <[e-mail]>]

On 8 December 2017 at 16.02.56, Lucas Pardue ([e-mail]) wrote:

Hi Mikkel,

There was a recent thread on httpbis mailing list where we touched on the
idea of HTTP header compression independent of version mapping. HPACK is
quite a generic thing really - there's not much that is specific to HTTP/2.

Your proposed text seems related to that thread, where do you see that
belonginging? Do you think that RFC 7838 does not already explain it in an
appropriate form?


Hi Lucas,

My original text was really on the first impressions of QUIC/HTTP and not
on HPACK as such and hence the HTTP/2 reference. HPACK was just a single
bullet noting that my initial impression of the HPACK text (admittedly
quite late) was a fair bit more confusing than I would have expected. When
asked to provide more details on why I found HPACK a bit complicated, I
opted to suggest a simpler text as an example based on my overall
understanding - just a quick write down. However, I cannot say if the HPACK
has a good reason to be as it is without reading the document very
carefully and understanding all the details. So my input should be taken
from a naive first readers perspective. Those with more experience can
better judge if the text can be used a guideline to simplify future packing
algorithms, but as I stated in the beginning, take it for what it is.

On the actual packing algorithms, I could have an opinion, but right now
that is fairly low on my list of things to focus on. I’m sure someone has
thought long and hard over async complications. I can say though, is that
overall ZSTD looks like a promising general purpose compression library
that does support pre-registered dictionaries and now has a more liberal
license than it used to have.

As to QUIC/HTTP itself, I was a bit put off a bit about HTTP/2 prose. It is
not necessarily bad or unwarranted, but from my perspective I didn’t feel
the need to dig into HTTP/2 unless there was a very specific reason such
as: this is the list of permitted pseudoheaders and defined in HTTP/2
section x.

And finally this wasn’t meant to put down the efforts placed on either
document. But I consider the initial uninformed impressions valuable
because once you understand a problem, you can no longer see where others
struggle and this is why I shared this.