Skip to content
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

Change framing to improve clarity #4

Closed
DavidSchinazi opened this issue Nov 6, 2019 · 1 comment
Closed

Change framing to improve clarity #4

DavidSchinazi opened this issue Nov 6, 2019 · 1 comment

Comments

@DavidSchinazi
Copy link
Collaborator

Comment from @martinthomson on the QUIC list:

Hi David,

I think that this is broadly the right mechanism. It would be good to validate it more thoroughly.

The model and framing could use a little work.

I struggled a little with the framing here because the split between incompatible and compatible versions is very important, but also unclear. The definition of "compatible" is left for Section 7, but it seems like it should be right up front.

The framing I would choose puts the model up front. The model that you have have two layers that are applied progressively:

  1. incompatible version negotiation, where the server sends a Version Negotiation packet in response to a version it does not understand.

  2. compatible version negotiation, where the server can generate interpret a version X Initial packet and continue with version Y.

Regarding the model, the definition of "compatible" needs work.

I observe that you only need a mapping from "Initial"-equivalent packets in X to the same in Y - and maybe the ability to generate a Retry in version X (more below) - in order for this to work. That's where there is a clear functional mapping from a version X packets that initiate the connection to something that fills the same purpose in version Y.

But the definition you have for "compatible" implies that the mapping is bijective, which I don't think is necessary. As the draft says, version Y might define (and allow) new frame types in its Initial-equivalent packet(s), but as long as those are either optional or can be synthesized from X, that's OK. It isn't necessary that every Y have a functional representation in X. We might not want to define a way to negotiate an older version from a newer one (or at least not for every case).

The ability to generate a Retry stretches this definition a little. Can you explain why you can't generate a version Y Retry? I have an inkling, but it's not fully formed. It complicates the model more than I'd like to have it this way around.

@DavidSchinazi
Copy link
Collaborator Author

Closing this issue, follow along on the new repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant