-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify when a client needs to include the version #325
Comments
These are two separate requirements: the first describes when the server can use the VERSION flag, the second describes when the client can use the VERSION flag. The latter sentence is the logical conjunction:
Can you propose a way to reword this that is less confusing to you? |
@martinthomson: Seems I didn't read carefully enough. There's no conflict in that paragraph. Sorry for that! I'd still suggest to shorten the second sentence to
because there's no way a client can obtain a 1-RTT key from a version negotiation packet. |
The extra condition is a concession to proprietary things that Google are doing. If you can convince @janaiyengar, I'd be very happy to make that change. |
I think we want the ability to do out of band key negotiation, and not just for Google internal use cases, because I believe others will/do have similar use cases. |
That makes sense, I didn't consider that use case. |
There's conflicting information in Section 6.1:
First it says
Two paragraphs later it says
This is conflicting, because the client may receive a packet from the server (which is not a Version Negotiation Packet, meaning that the server accepted the proposed version) before having the 1-RTT keys.
Furthermore, the last part of the last sentence makes little sense anyway. It's impossible for the client to have 1-RTT keys unless the server already accepted the version.
The text was updated successfully, but these errors were encountered: