Subject: [quicwg/base-drafts] Extending flags (#56)

From: Martin Thomson <[email-masked]>
Date: Thu, 01 Dec 2016 15:16:02 -0800

We need to define how the public flags might be extended, or if it could be.  This has a pretty serious impact on #55.

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

---

From: Alexis La Goutte <[email-masked]>
Date: Sat, 03 Dec 2016 12:24:01 -0800

Use 0x80 bitmap flag to say, there is a another byte flag ? (like radiotap) or already change to use 2 or 4 bytes ?

-- 
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/56#issuecomment-264663213

---

From: ianswett <[email-masked]>
Date: Sat, 03 Dec 2016 12:36:27 -0800

I agree with Alexis the obvious approach is to use 0x80 to indicate another byte of flags.  If we think extended flags will be common, I think we should change to 2 bytes as a minimum, because variable length fields before the connection id are more annoying to process in some systems(ie: BPFs), particularly if the number of times one can add more flags is unbounded.(ie: IPv6 extension headers). 

I would lean towards suggesting that extended flags should come after the connection id.

-- 
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/56#issuecomment-264663855

---

From: martinduke <[email-masked]>
Date: Mon, 05 Dec 2016 17:02:13 -0800

I think a 2-byte field will be annoying in the near to medium-term, where the second byte is unused. Having the second byte after connection ID (and version?) would be annoying in the more distant future when 8+ flags are routine.

But in either case, this is a matter of taste and I see no showstoppers with having the extra flags come later. Especially since we might end up having lots of these flags.

On the other hand, I can imagine future protocol tweakers "abusing" unlimited public flags to put whole bitfields in there. I'm not sure if this is a "problem" we need to solve or 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/56#issuecomment-265029112

---

From: martinduke <[email-masked]>
Date: Mon, 05 Dec 2016 17:03:32 -0800

In any case it might be worthwhile to spell out what's acceptable in the bounds of a version. If a given version has 6 defined flags, can there be any number of public flag bytes? If so, do I simply ignore whatever's there?

-- 
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/56#issuecomment-265029323