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

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.

AYJ

Received on Tuesday, 13 March 2018 01:47:27 UTC