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

[Lucas Pardue <[e-mail]>]

Hi Mikkel,

I didn't mean to sound adversarial, rather in that httpbis thread I had raised a question about extracting common semantics out of the HTTP/2 doc; your text seems quite aligned to that idea which I had independently. To give a different example, HTTP server push could, IMO, benefit from be abstracted away from the HTTP/2 specifics in which it is defined. On that topic, I raised a few issues with push in HTTP/QUIC where I think some editorial changes could help improve its readability. There are other changes (like uni streams) that needed to be shaken out before tackling improvements, so somebody issues remain open. (I'll get around to doing a PR soon).

Fresh eyes are great for the very reason you describe. I'm sure many people wouldn't go to the effort of writing up issues or suggesting improvents, so thanks for doing so. I think I agreed with most of what you wrote up.

Regards
Lucas

Ps in my previous email I meant to say RFC 7541 (HPACK). 


________________________________________
From: Mikkel Fahnøe Jørgensen [[e-mail]]
Sent: 08 December 2017 15:39
To: Lucas Pardue; Dmitri Tikhonov
Cc: IETF QUIC WG
Subject: RE: Feedback from first read of QUIC/HTTP draft 08

On 8 December 2017 at 16.02.56, Lucas Pardue ([e-mail]<mailto:[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.