Re: resourceTiming.nextHopProtocol reports"hq" - is that ok?

On Tue, Mar 13, 2018 at 1:05 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On Tue, Mar 13, 2018 at 4:46 AM, Amos Jeffries <squid3@treenet.co.nz>
> wrote:
> > On 13/03/18 16:56, Ryan Hamilton wrote:
> > For informing the recipient of any additional versions of QUIC which the
> > sender supports. At present it could be referring to older Drafts which
> > are still supported (but not preferred), and after RFC publication to
> > different versions of the "hq" protocol (if any).
>
> Everything Amos said here.  Remember that there are two versions in
> play here: QUIC and HTTP over QUIC.  And using "hq" camps on a value
> we intend to use.  If Google are indeed using it, then it might
> already be unrecoverable, but that depends on how thoroughly it can be
> removed.
>
> If this use of "hq" continues - even in part - then we'll have to pick
> a different value for HTTP over QUIC.
>
> The actual ALPN that Google QUIC uses is unlikely to matter in the
> long term, but I would use hq-00, even if it has diverged from that
> since the -00 drafts went out.
>

​As discussed in-person, the current use of "hq" by Google shouldn't cause
long term harm because it's used in conjunction with a quic​= list that
only includes google QUIC versions.

That being said, I'm happy to change this. We've disabled the experiment in
Chrome which thinks in understands "hq" in an Alt-Svc advertisement and
we'll also disable the server-side announcement. In addition, I've updated
the w3c issue about nextHopProtocol
https://github.com/w3c/navigation-timing/issues/71 and have sent off a
Chrome code review
https://chromium-review.googlesource.com/c/chromium/src/+/963492 to change
the resource timings API output which kicked off this thread.

Cheers,

Ryan