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.

Sign up for GitHub

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

Jump to bottom

Version validation fields can't move or change #498

Merged
merged 3 commits into from Aug 10, 2017
Merged

Version validation fields can't move or change #498

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3feae87
Version validation fields can't move or change
martinthomson May 4, 2017
c48030d
Better reasons for maintaining consistent version negotiation fields …
martinthomson Jul 31, 2017
7b05603
Attempt to address feedback
martinthomson Aug 3, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
9 changes: 9 additions & 0 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1232,6 +1232,15 @@ client MUST terminate with a VERSION_NEGOTIATION_ERROR error code if
version negotiation occurred but it would have selected a different version
based on the value of the supported_versions list.

When an endpoint accepts multiple QUIC versions, it can potentially interpret
transport parameters as they are defined by any of the QUIC versions it
supports. The version field in the QUIC packet header are only authenticated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: are -> is
also, "is only authenticated using" -> "is authenticated using"

using the transport parameters. The position and the format of the version
fields in transport parameters MUST either be identical across different QUIC
versions, or be unambiguously different in a way that ensures that there is no
possibility for confusion about their interpretation. One way that a new format
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggested rephrase: "be unambiguously different in a way that ensures that there is no possibility for confusion about their interpretation" --> "be unambiguously different to ensure no confusion about their interpretation"

could be introduced is to define a TLS extension with a different codepoint.


## Stateless Retries {#stateless-retry}

Expand Down