Subject: [quicwg/base-drafts] QUIC/HTTP clarifications (#1001)

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Dec 2017 00:31:58 +0000 (UTC)

Reading through the QUIC/HTTP-draft-08 a few things appeared unclear. This is just a summary based on my first pass over the document, so take it for what it is. I have only superficial knowledge of HTTP/2 in advance.

1. A bit too much discussion of HTTP/2 instead of leaving that for section 8. It does not help understanding QUIC/HTTP from scratch. And perhaps a bit too much assumption about HTTP/2 knowledge while implementers might have skipped that step in their evolution.
2. No explanation of how methods are communicated. Header fields reference HTTP 1.1 draft, but from skimming HTTP/2 doc, it is clear that these (as suspected) are transfered via special headers known as pseudo headers).
3. Lots of frame type flags, none used, and only a few types. Why not either remove flags and have more types, or have a type bit encoding for flags presence (this may be due to early state of draft, just mentioning).
4. Why are settings 16 bits instead of varints, and why is the space so large. A 256 or even 2K space would be easy to have in a table, 64K requires a map or switching logic. A settings space still requires that both ends understands a signficant portion of settings to make any real sense. Who decides to add more settings. Is this to have space for the next century, or just until the next QUIC version?
5. There is an End Header Block something, but it is unclear what it is. Is it a flag to be defined, or some pseudo header?
6. The GOWAY discussion could probably be shortened and made it bit clearer - it takes a few readings to understand the point of multiple GOWAY frames and why the ID can decrease (not sure I do fully understand).
7. A basic example of a short HTTP 1.1 request and how it looks in the protocol would be helpful.
8. The HPACK, to be replaced, doc is hard to parse, and it doesn't sound like it is as complicated as it reads. Hopefully a future QUIC equivalent would be a bit easier to digest.
9. The entire push hierarchy sounds very complex - I wonder what the takeaway from HTTP/2 is - is it really worthwhile, or is no-one using it yet, but in 10 years it will be huge?

-- 
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/1001

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 Dec 2017 17:11:44 -0800

Closed #1001.

-- 
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/1001#event-1378050817

---

From: Martin Thomson <[email-masked]>
Date: Fri, 08 Dec 2017 01:11:44 +0000 (UTC)

@mikkelfj, it's better to create short, focused issues.  If you want to submit a review like this, the list is a better venue.

-- 
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/1001#issuecomment-350143002

---

From: MikkelFJ <[email-masked]>
Date: Fri, 08 Dec 2017 08:42:37 +0000 (UTC)

Yes, I was wondering - the list is a bit harder to track, but so many vague points are also hard to handle as an issue. I will repost on list.

-- 
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/1001#issuecomment-350206664

---

From: Mike Bishop <[email-masked]>
Date: Mon, 18 Dec 2017 18:18:41 +0000 (UTC)

Just to be clear, though, these are valid editorial issues.  I'm planning to go through these and either modify the spec directly (for small things) or generate editorial PRs, even though this issue is closed.

-- 
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/1001#issuecomment-352513855