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

Add nextHopProtocol HTTP/0.9 and 1.0. Link to QUIC #159

Merged
merged 5 commits into from Jun 15, 2018

Conversation

Projects
None yet
4 participants
@yoavweiss
Copy link
Contributor

yoavweiss commented May 18, 2018

Closes #122


Preview | Diff

@yoavweiss yoavweiss requested review from igrigorik and toddreifsteck May 18, 2018

index.html Outdated
@@ -464,6 +467,9 @@ <h3>The <dfn>PerformanceResourceTiming</dfn> Interface</h3>
be percent-encoded if they are valid token characters except "%",
and when using percent-encoding, uppercase hex digits MUST be
used.</p>
<p class=note>The "hq" ALPN ID is defined for the QUIC protocol in the <a
href="https://tools.ietf.org/html/draft-ietf-quic-http-11#section-9.1">HTTP over QUIC Internet Draft</a>.

This comment has been minimized.

Copy link
@igrigorik

igrigorik May 18, 2018

Member

We recently changed this:

We should probably capture the resolution from that discussion in this note?

Otherwise, LGTM!

This comment has been minimized.

Copy link
@yoavweiss

yoavweiss May 18, 2018

Author Contributor

Theoretically, that has not changed, it's just that Chrome is using a different string for G-QUIC, instead of publishing it as the IETF variant, which "owns" the ALPN ID.

I wonder if we need to also add some liberty on that front for experimental protocols. Maybe something like: "In case the network protocol used is an experimental one and not defined in the above registry, user agents MAY also use other descriptive strings."

This comment has been minimized.

Copy link
@igrigorik

igrigorik May 18, 2018

Member

Yeah, that makes sense. In fact, perhaps invert it and lead with note about experimental protocols, citing QUIC as one example.

This comment has been minimized.

Copy link
@yoavweiss

yoavweiss May 18, 2018

Author Contributor

I think the bit about experimental protocols needs to be normative. Maybe I can add it around the HTTP/0.9 and 1.0 bits. (I'm also thinking it'd make for a long paragraph, so maybe I should split it up into a list somehow)

This comment has been minimized.

Copy link
@yoavweiss

yoavweiss Jun 14, 2018

Author Contributor

(belatedly) added the above. PTAL

@yoavweiss yoavweiss referenced this pull request Jun 14, 2018

Closed

NextHopProtocol Values #122

yoavweiss added some commits Jun 14, 2018

index.html Outdated
@@ -469,8 +469,8 @@ <h3>The <dfn>PerformanceResourceTiming</dfn> Interface</h3>
user agents MAY return "http/0.9" and "http/1.0" respectively. In
case the user agent is using an experimental protocol which ALPN
protocol ID has not yet been defined in the above registry, the user
agent MAY use the ALPN negotiated value or use another descriptive
string.</p>
agent SHOULD use the ALPN negotiated value or MAY use another descriptive

This comment has been minimized.

Copy link
@igrigorik

igrigorik Jun 14, 2018

Member

Do we really both a SHOULD and a MAY here? Can we collapse them?

user agent SHOULD use the ALPN negotiated value or another descriptive string if the ALPN negotiated value is not available.

index.html Outdated
protocol MUST NOT be percent-encoded if they are valid token
characters except "%", and when using percent-encoding, uppercase hex
digits MUST be used.</p>
<p>The registry for protocol identifiers lists the possible values

This comment has been minimized.

Copy link
@MikeBishop

MikeBishop Jun 14, 2018

The whole point of the issue is that the registry isn't the set of "possible" values, it's a set of values whose meaning is generally well-defined. I'd say that the registry lists some common values, but implementations need to be prepared to encounter identifiers for experimental or unregistered protocols.

index.html Outdated
used.</p>
ALPN Protocol IDs</a>. For the HTTP/0.9 and HTTP/1.0 network
protocols, which are not defined in the ALPN Protocol ID registry,
user agents MAY return "http/0.9" and "http/1.0" respectively. In

This comment has been minimized.

Copy link
@MikeBishop

MikeBishop Jun 14, 2018

Just submitted the registration request for these, so hopefully this sentence will become obsolete next week.

This comment has been minimized.

Copy link
@yoavweiss

yoavweiss Jun 15, 2018

Author Contributor

Removed for now in hope it will

index.html Outdated
case the user agent is using an experimental protocol which ALPN
protocol ID has not yet been defined in the above registry, the user
agent SHOULD use the ALPN negotiated value or MAY use another descriptive
string if one is not available.</p>

This comment has been minimized.

Copy link
@MikeBishop

MikeBishop Jun 14, 2018

As suggested on the issue: MUST use the negotiated ALPN token if any, MAY use another descriptive string if ALPN was not used.

This comment has been minimized.

Copy link
@yoavweiss

yoavweiss Jun 15, 2018

Author Contributor

Changed in that spirit. PTAL

@yoavweiss

This comment has been minimized.

Copy link
Contributor Author

yoavweiss commented Jun 15, 2018

OK, I believe I addressed all the comments.
@igrigorik @MikeBishop @LPardue @RyanAtGoogle PTAL?

@LPardue

This comment has been minimized.

Copy link
Contributor

LPardue commented Jun 15, 2018

Thanks. I wonder, in light of removing explicit HTTP 0.9 and 1.0 and adding negotiation text, could you be less explicit about the "hq" identifier? Perhaps just point to the IETF HTTP/QUIC document, which already fully defines how to handle ALPN identifiers.

@yoavweiss

This comment has been minimized.

Copy link
Contributor Author

yoavweiss commented Jun 15, 2018

Thanks. I wonder, in light of removing explicit HTTP 0.9 and 1.0 and adding negotiation text, could you be less explicit about the "hq" identifier? Perhaps just point to the IETF HTTP/QUIC document, which already fully defines how to handle ALPN identifiers.

The reason this is added (as a non-normative note) is that it already caused some confusion when folks tried to find "hq"'s definition. I don't see harm in us being explicit about it (in a note).

@LPardue

This comment has been minimized.

Copy link
Contributor

LPardue commented Jun 15, 2018

I can live with that 😀

@igrigorik
Copy link
Member

igrigorik left a comment

👍

@yoavweiss yoavweiss merged commit 709c54a into w3c:gh-pages Jun 15, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
ipr PR deemed acceptable.
Details

@yoavweiss yoavweiss deleted the yoavweiss:nexthop_values branch Jun 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.