Subject: [quicwg/base-drafts] Invarinats in TP (#1672)

From: mirjak <[email-masked]>
Date: Thu, 16 Aug 2018 09:40:40 -0700

The transport draft says:
"When an endpoint accepts multiple QUIC versions, it can potentially
   interpret transport parameters as they are defined by any of the QUIC
   versions it supports.  The version field in the QUIC packet header is
   authenticated using transport parameters.  The position and the
   format of the version fields in transport parameters MUST either be
   identical across different QUIC versions, or be unambiguously
   different to ensure no confusion about their interpretation.  One way
   that a new format could be introduced is to define a TLS extension
   with a different codepoint."
It seems that this actually belongs in the invariants draft.

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

---

From: Mike Bishop <[email-masked]>
Date: Thu, 16 Aug 2018 11:38:05 -0700

It's not actually an invariant, because it's not true of all QUIC versions, nor is it (for servers, at least) visible outside the encryption envelope.  It's really advice to the authors of future QUIC versions about how to avoid bugs when supporting both versions simultaneously.  (There's similar text on how to design a multi-version Stateless Reset.)

-- 
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/1672#issuecomment-413644290

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Aug 2018 17:12:14 -0700

I don't think that we need to do anything about this, and I would be opposed to moving this to invariants for the reasons @MikeBishop outlines.  I would consider a PR that improves the text.

-- 
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/1672#issuecomment-413720700