Right, thanks for reviving this. My sense is that the best approach here is to make a clean break and get a new codepoints for BOTH the version negotiation transport parameter and the v2 version.
Though deployments can change, they probably won't change atomically enough to avoid real negotiation failure. On Thu, Dec 1, 2022, at 06:25, Martin Duke wrote: > 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 >>> >>> ____
