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

Recommend replacing, not changing, protocol components #3206

Merged
merged 3 commits into from Dec 10, 2019
Merged

Recommend replacing, not changing, protocol components #3206

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8a47a06
Recommend replacing, not changing
MikeBishop Nov 8, 2019
36eba03
Remove extra word
MikeBishop Nov 8, 2019
0b355bf
Update draft-ietf-quic-http.md
MikeBishop Nov 11, 2019
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
5 changes: 3 additions & 2 deletions draft-ietf-quic-http.md
View file
Open in desktop
Expand Up @@ -1485,8 +1485,9 @@ requirement and SHOULD be treated as an error.
Extensions that could change the semantics of existing protocol components MUST
be negotiated before being used. For example, an extension that changes the
layout of the HEADERS frame cannot be used until the peer has given a positive
signal that this is acceptable. In this case, it could also be necessary to
coordinate when the revised layout comes into effect.
signal that this is acceptable. Coordinating when such a revised layout comes
into effect could prove complex. As such, allocating new identifiers for
new definitions of existing protocol elements is likely to be more effective.

This document doesn't mandate a specific method for negotiating the use of an
extension but notes that a setting ({{settings-parameters}}) could be used for
Expand Down