Invariants in Transport Parameters

[mirjak]

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.

[MikeBishop]

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.)

[martinthomson]

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.