I don't want to lose this thread, as this is a quite important thing to resolve. I personally would prefer to keep the version number constant, but it's not all clear to me that it's acceptable to deployed implementations.
On Mon, Nov 21, 2022 at 5:06 AM Nick Banks <[email protected]> wrote: > MsQuic has released a version with VN+V2 support, but it’s marked as > “preview” so it can change, as necessary. We weren’t planning to make it an > official feature until the RFCs. > > > > Thanks, > > - Nick > > Sent from Outlook <http://aka.ms/weboutlook> > > *From:* QUIC <[email protected]> *On Behalf Of * Martin Duke > *Sent:* Thursday, November 17, 2022 8:45 PM > *To:* Christian Huitema <[email protected]> > *Cc:* Martin Thomson <[email protected]>; [email protected] > *Subject:* Re: Transport parameters for version negotiation and v2 > > > > In Google's code, the v2 code is exists but is not in production because > we haven't done compatible VN yet. So changing the transport parameter at > this point would have no impact on Chrome or Google production servers. > > > > On Thu, Nov 17, 2022 at 4:28 PM Christian Huitema <[email protected]> > wrote: > > > > On 11/17/2022 4:15 PM, Martin Thomson wrote: > > How many people have shipped version negotiation and v2 already? > > > > I assume that implementations are using the codepoints for the transport > parameter in the draft (0xFF73DB), but the drafts says this: > > > >> When this document is approved, it will request permanent allocation of > a codepoint in the 0-63 range to replace the provisional codepoint > described above. > > > > IANA are about to make that new allocation, but that might not do good > things for interoperability. > > > > We're not changing the v2 version number and v2 *requires* the use of > this transport parameter: > https://quicwg.org/quic-v2/draft-ietf-quic-v2.html#section-4-2 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.org%2Fquic-v2%2Fdraft-ietf-quic-v2.html%23section-4-2&data=05%7C01%7Cnibanks%40microsoft.com%7C0b21307c92c24ee5f18c08dac906a08b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638043327575620512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wz2tzGwBJsw7zyflxjdsihvHeZ%2FvFJhb1S48%2Bc9x%2BAY%3D&reserved=0> > > > > Consequently, an implementation that uses the current transport > parameter codepoint will not interoperate successfully with an > implementation that uses any new transport parameter codepoint. > > > > So, we either allocate a new codepoint for both, or we keep the existing > ones. Which do people prefer? > > > > Or, am I wrong about this? > > > The way I read it, QUIC-V2 makes a reference to QUIC-VN, which is > documented in the reference section as pointing to > draft-ietf-quic-version-negotiation-13. But I fully expect that the next > QUIC-V2 draft will refer to the updated version of QUIC-VN, and thus to > the final transport parameter. > > -- Christian Huitema > >
