Subject: Re: [quicwg/base-drafts] Consider making h3 frame types varint (#2253)

From: David Schinazi <[email-masked]>
Date: Thu, 03 Jan 2019 14:15:47 -0800

I agree with @kazuho that exchanging H3 settings in transport parameters has appealing benefits, there is however the downside that client transport parameters are not encrypted, and this could therefore be used for fingerprinting.

That said we may be somewhat off topic, as this issue is about 8-bit vs varint for h3 frame types. Without going into the details discussed in this thread, there seems to be interest in allowing uncoordinated extensions, and varints allow those at a very small implementation cost.

-- 
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/2253#issuecomment-451294928

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 03 Jan 2019 23:49:06 -0800

> I agree with @kazuho that exchanging H3 settings in transport parameters has appealing benefits, there is however the downside that client transport parameters are not encrypted, and this could the…

I am not sure if we need to care about the downside, considering the fact that we are sending other parameters (including the transport-level transport parameters) in clear. If we do care, we should try protecting all of them.

> That said we may be somewhat off topic, as this issue is about 8-bit vs varint for h3 frame types. Without going into the details discussed in this thread, there seems to be interest in allowing un…

Yeah my point was that people interested in doing private experiments can always negotiate the use of the extensions for all the cases the WG decided to care about, and therefore that there is not a benefit in having varint frame types, especially assuming that sending private experimental extensions to the wild without coordination is likely to be just waste of bandwidth.

-- 
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/2253#issuecomment-451373046

---

From: Mike Bishop <[email-masked]>
Date: Tue, 08 Jan 2019 11:33:45 -0800

I don't feel strongly either way.  You can always request a code point assignment from IANA without publishing an RFC, and experience suggests we're unlikely to run out of code points.  (If we do, we revive the EXTENDED frame that contains a sub-type field and a payload defined by the sub-type.)  However, there is value in being able to do some initial tests without registering a codepoint.

This can be done, as Kazuho suggests, either by advertising a setting or by allowing super-high codepoints for private use.

I suspect the technical merits of either will ultimately prove irrelevant and this will wash whichever direction "varint all the things" goes.

-- 
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/2253#issuecomment-452423823

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 12 Jan 2019 14:41:45 -0800

I think it's worth noting that the side effect of varint h3 frame types means that we would need to redesign (or abandon) the HTTP_MALFORMED_FRAME error code. It relies on the frame type being 8-bit.

-- 
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/2253#issuecomment-453786471

---

From: Mike Bishop <[email-masked]>
Date: Wed, 30 Jan 2019 21:32:27 -0800

Discussed in Tokyo; moderate support and minimal opposition.  We will do this.  HTTP_MALFORMED_FRAME will need to change.  Two proposals:
- reflect the frame type if <255, and 255 indicates "other."
- reflect the low byte of the frame type; collisions should be relatively rare.

-- 
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/2253#issuecomment-459221367