Subject: [quicwg/base-drafts] Consider adding flags transport parameter for extension, frame, or feature negotiation (#2839)

From: Christopher Wood <[email-masked]>
Date: Mon, 24 Jun 2019 15:07:24 -0700

`disable_migration`, for example, is a boolean parameter that conveys one bit of information with a zero length value. There are likely to be more parameters like this in the future. There's currently an I-D in TLS that describes an extension for these sorts of boolean flags [1]. Maybe it'd be useful to allocate space for a similar bitmap in QUIC's TPs, too?

[1] https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 24 Jun 2019 15:24:43 -0700

In principle you could also negotiate feature masks that way. Client says, I have this mask, server says I have this mask. AND them together and see of the result makes sense.

-- 
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/2839#issuecomment-505204388

---

From: ianswett <[email-masked]>
Date: Mon, 24 Jun 2019 15:58:16 -0700

One could also imagine changing disable_migration from a bool to an enum, if we want to describe a wider variety of functionality?  I'm not sure if that's better or worse than a bitmap, but it's certainly more descriptive than a bool.

-- 
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/2839#issuecomment-505211956

---

From: David Schinazi <[email-masked]>
Date: Mon, 24 Jun 2019 16:57:45 -0700

This is interesting but it can also be implemented as an extension, so I'd personally recommend waiting until after QUICv1 ships to avoid delaying the core spec.

-- 
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/2839#issuecomment-505224456

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 18:11:45 -0700

I think that David is right about this.  We have just one transport parameter that could use this right now, so anything we do is strictly worse.  Also, TLS haven't really settled any of the details of the flags proposal.  We can avoid doing the same work in parallel, so to avoid creating similar but confusing mechanisms, so we should.

My proposal: quicv2.

-- 
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/2839#issuecomment-505677873

---

From: Christopher Wood <[email-masked]>
Date: Wed, 26 Jun 2019 07:56:34 -0700

> My proposal: quicv2.

That works for me! 

-- 
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/2839#issuecomment-505912640