Re: [quicwg/base-drafts] Simplify version negotiation (#2133)

[Kazuho Oku <[e-mail]>]

@ekr @DavidSchinazi Thank you for the clarifications.

I'm glad to know that we would have VN-packet-based rejection in the new proposal. I'd assume that we would continue to allow (or encourage) clients to grease the servers.

So now it seems to me that the core of the proposal is to omit servers from sending `supported_versions` and clients checking the value. I can understand that the approach works, because checking `supported_versions` is meaningless for a client that only supports one version, and because future versions of the client can interpret the omission of the field as the server supporting only version 1.

Generally speaking, I agree that compatible version upgrade is preferable, not only because it reduces one round-trip, but because it is easier to deploy than VN-packet-based negotiation (see https://github.com/quicwg/ops-drafts/pull/52).

If we can anticipate that having only compatible version upgrade would be fine, I think I have no reason to complain against dropping `supported_versions` from the QUIC v1.

And that's takes me back to wonder about the inflexibility of the v1 Initial packet design.

As I've stated, [current design is inflexible in sense that it does not have a way to have extensions outside the ClientHello message](https://github.com/quicwg/base-drafts/pull/2133#issuecomment-447194700). The only way for future versions of QUIC to introduce extensions outside of ClientHello, while retaining compatibility with v1, would be to abuse the Token field. They would define extension slots (like the one we have in TLS handshake messages) using the Token field so that additional data and the token can be transmitted.

Would we be fine with that? If we think that's too ugly, maybe we should add a `extensions` field to the client-sent Initial packets, so that future versions of QUIC can use that to contain extensions. QUIC v1 client would set the field to zero-length, and v1 servers would ignore the value of the field.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2133#issuecomment-449672264