Re: [quicwg/base-drafts] Compatible version upgrade (#1901)

[Martin Thomson <[e-mail]>]

@RyanAtGoogle, @dtikhonov,

Happy to take this to Bangkok (it's only a week away, after all).  However, I think that you will appreciate the change to having the server validate versions when you walk through the process of upgrading a server to support a new version, even if you don't see the point of the upgrade part of this.

@mikkelfj 
> It is a bit unclear when a client populates other compatible versions: in the first connection attempt, or only as a response to a VN packet. In the latter case the client already has made a choice and the server should not send VN.

A client populates supported_versions with all versions it supports.  In response to VN, it moves one or more from that list to unsupported_versions.

> On the hand, in the first connection attempt the client might want to try v1 with the option of v1.1 and v1.2 as compatible upgrades. It might also want to support v2 but since v2 is not compatible, it cannot say that. But it could hope for v2 in a VN packet. Except, the server is not allowed to do that.

The client lists v2 in supported_versions.  The server can't use the information, so there is no benefit in  terms of validating version negotiation gained by adding it, but it's easier to describe this way.

I could change supported_versions to compatible_versions and recommend including only those that are compatible with the packet version, but then there is some information absent, and we've only ever regretted that in the past.

-- 
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/1901#issuecomment-433755897