You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Section 3: “Version negotiation takes place after the retry cycle is over.” This is only possible for compatible versions; if the server does not support the version the client attempted, it obviously cannot send a Retry packet in that version, because Retry packets are version-specific.
Section 3: “Servers must retain the ability to process the Initial packet from older versions….” No, it means that if the server wants to avoid a VN packet, it needs to be able to process the Initial packet from the version the client tried.
Section 4: Rather than putting a count-prefixed list of versions, perhaps consider just embedding the VN packet payload? It’s equivalent, but easier to explain.
Section 7: Clearly it is possible to possible to add new frame types to Initial packets in a future version, I think what you mean to say is that this is a change that would break compatibility between versions.
As a general statement on the document, you assume throughout that all versions have packet types, contain packet types called Initial and Retry, and that Initial packets contain frames. The odds of those things being true across QUIC versions is likely high, but they’re not invariants, so you can’t assume them here. You need to state general principles, and then use concepts from QUICv1 as examples of the principle.
For example, rather than discussing version compatibility in terms of Initial packets, you might want to say that versions A and B are “compatible” if the first flight of packets sent by the client in version A carries enough information for the server to generate the corresponding flight in version B, the server speaks version B, and is able to parse at least the first flight of version A.
Also not discussed is the case where the server speaks version(s) which are compatible with what the client offered, but doesn’t speak the version the client offered, even enough to generate the response. With the right definition of “compatible,” this just falls into the “incompatible” path and works for the server, but you need to call out the fact that the client shouldn’t consider it an error if the server uses the incompatible path between versions that the client thinks are compatible.
The text was updated successfully, but these errors were encountered:
This PR rewrites most of the draft to make it more aligned
with the fact that it's now a stand-alone document that
is not directly tied to QUICv1.
Fixes#1.
Fixes#2.
Fixes#3.
Fixes#4.
Fixes#6.
Fixes#8.
Comment from @MikeBishop on the QUIC list on 2019-11-06 :
The text was updated successfully, but these errors were encountered: