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