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

On Mon, Mar 12, 2018 at 6:46 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 13/03/18 13:26, Ryan Hamilton wrote:
> > Just for reference, here's 2.1.1:
> >
> >    For example, suppose a server supported both version 0x00000001 and
> >    the version rendered in ASCII as "Q034".  If it opted to include the
> >    reserved versions (from Section 4 of [QUIC-TRANSPORT]) 0x0 and
> >    0x1abadaba, it could specify the following header:
> >
> >    Alt-Svc: hq=":49288";quic="1,1abadaba,51303334,0"
> >
> > That suggests that if a server want to advertise HTTP over Google QUIC
> > Q034, it can use "hq" in the advertisement. Perhaps that's not the
> intent?
> >
>
> The 2.2.1 clause "MUST NOT" and "MUST" about appending "-" and draft
> number overrides all regular text, examples, and lesser requirements
> within the Draft. When an RFC is published it should not contain those
> MUST/MUST NOT and the "hq" ALPN becomes valid.
>
> AFAIK it is done this way to avoid having to re-write many references to
> things during the final stage of RFC publication.
>
> That said, 2.1.1 is just an example. Examples are always trumped by
> normative requirements.
>
> > In any case, if we think that "hq" is the wrong identifier to be using
> > in the resource timing API, it would probably be a good idea for the WG
> > to clarify the issue with the w3c since I believe that's what drove the
> > chrome implementation.
>
> It is wrong since it violates the MUST/MUST NOT.
>
> Compliant implementations for that document use the "hq-10" ALPN.
> Anything using "hq" before the RFC is actually published is just forcing
> the RFC editor and IANA to assign a different ALPN to avoid those broken
> implementations when the final protocol is established.
>

​That makes sense, but I'm confused what the quic= parameter of the QUIC
Alt-Svc advertisement is intended to be used for then?​