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

Use quic= instead of v= #235

Merged
merged 5 commits into from Feb 2, 2017
Merged

Use quic= instead of v= #235

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e3caeaf
Use quic= instead of v=
MikeBishop Jan 26, 2017
684ca6e
Incorporating feedback on quic= parameter
MikeBishop Jan 26, 2017
a6e7d47
Broaden language to include alternate-host Alt-Svc uses
MikeBishop Jan 31, 2017
6b1b10d
Making origin/alternative clearer
MikeBishop Jan 31, 2017
a9e47f2
Clarifying example versions
MikeBishop Feb 1, 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
31 changes: 16 additions & 15 deletions draft-ietf-quic-http.md
View file
Open in desktop
Expand Up @@ -109,35 +109,36 @@ response:

Alt-Svc: hq=":443"

On receipt of an Alt-Svc header indicating HTTP/QUIC support, a client MAY
attempt to establish a QUIC connection on the indicated port and, if successful,
send HTTP requests using the mapping described in this document. Servers SHOULD
list only versions which they support, but MAY omit supported versions for any
reason.

Connectivity problems (e.g. firewall blocking UDP) can result in QUIC connection
establishment failure, in which case the client should gracefully fall back to
HTTP/2.


## QUIC Version Hints {#alt-svc-version-hint}

This document defines the "quic" parameter for Alt-Svc, which is used to provide
version-negotiation hints to HTTP/QUIC clients. QUIC versions are four-octet
sequences with no additional constraints on format. Syntax:
optional version-negotiation hints to HTTP/QUIC clients. QUIC versions are
four-octet sequences with no additional constraints on format. Syntax:

quic = version-number
version-number = 1*8HEXDIG; hex-encoded QUIC version

When multiple versions are supported, the "quic" parameter MAY be repeated
multiple times in a single Alt-Svc entry. For example, if a server supported
both version "Q034" and version 0x00000001, it would specify the following
both version "Q034" and version 0x00000001, it could specify the following
Copy link
Member

Choose a reason for hiding this comment

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

Do we have enough context to understand what "Q034" is, aside from knowing that an ASCII/UTF-8 encoding of "Q" is 0x51?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's still there primarily because I wanted to be able to show the multiple-entry case. However, it might make more sense to change that to a draft version and leave the ASCII-like versions out entirely.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Mm. Except that the draft versions won't be in the final QUIC RFC, so there won't be any context for that reference once it's eventually published. Maybe not.

Copy link
Member

Choose a reason for hiding this comment

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

We could add that context, or we could add a "note to the RFC Editor" to remove Q034 and the related text on publication.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But then we'd still have to give them something to replace it with, and keeping the "how to do multiple" is worthwhile. I've expanded slightly, to refer to it as the version that would be rendered in ASCII as Q034. Given that we allow pretty free-form experimentation in that region, I don't know that we need to elucidate why a server might support an experimental version.

header:

Alt-Svc: hq=":443";quic=1;quic=51303334
Copy link
Contributor

Choose a reason for hiding this comment

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

I suspect this is obvious, but it might be nice to explain why 0x00000001 is ASCII encoded as "1" and not "00000001". I assume the idea is that leading '0's may be removed from the hex encoded string?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Basically, yes. I've made that explicit in a9e47f2.


Where multiple versions are listed, the order of the values reflects the
server's preference (with the first value being the most preferred version).

On receipt of an Alt-Svc header indicating HTTP/QUIC support, a client MAY
attempt to establish a QUIC connection on the indicated port and, if successful,
send HTTP requests using the mapping described in this document. Servers SHOULD
list only versions which they support, but MAY omit supported versions for any
reason.

Connectivity problems (e.g. firewall blocking UDP) can result in QUIC connection
establishment failure, in which case the client should gracefully fall back to
HTTP/2.

# Connection Establishment {#connection-establishment}

HTTP/QUIC connections are established as described in {{QUIC-TRANSPORT}}. During
Expand Down Expand Up @@ -943,14 +944,14 @@ The "hq" string identifies HTTP/QUIC:
Specification:
: This document

## Registration of Version Hint Alt-Svc Parameter
## Registration of QUIC Version Hint Alt-Svc Parameter

This document creates a new registration for version-negotiation hints in the
"Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" registry established in
{{!RFC7838}}.

Parameter:
: "v"
: "quic"

Specification:
: This document, {{alt-svc-version-hint}}
Expand Down