Unfortunately that won't work. Supporting multiple versions of QUIC does not require supporting any document, apart from the QUIC invariants. And the invariants don't reserve space for a trailer after the Supported Versions field. What problem are you trying to solve with this trailer? I suspect there are easier ways of solving it.
David On Tue, May 11, 2021 at 10:11 AM Martin Duke <[email protected]> wrote: > Section 6 of invariants > <https://quicwg.org/base-drafts/rfc8999.html#name-version-negotiation> > sayeth: > > "Version Negotiation packets do not use integrity or confidentiality > protection. Specific QUIC versions might include protocol elements that > allow endpoints to detect modification or corruption in the set of > supported versions." > > I also vaguely remember ekr batting around the idea of tacking some data > onto the packet to solve a problem we were discussing. > > *Maybe we just don't want to do this at all and we can safely ignore this > text in invariants.* > > If we *do* want to do it, the design is a little problematic. There is no > length field in VN packets to signal that the supported version list is > ending and other stuff is beginning. > > The only way I can think of to make this work is to use the VN draft to > reserve a magic version number to mean "this is the end of the supported > version list". That version is not a real version, MUST be the last one > listed, and perhaps can be followed by another magic number to indicate the > content that follows. > > Leaving aside legacy stuff negotiating pre-standard versions, which will > hopefully go away someday, someone supporting multiple versions would be > REQUIRED to support the VN draft and therefore incorporate this change. > > Thoughts? > Martin > > >
