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

On 13/03/18 16:56, Ryan Hamilton wrote:
> 
> On Mon, Mar 12, 2018 at 6:46 PM, Amos Jeffries 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?​
> 

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).

Amos

Received on Tuesday, 13 March 2018 04:47:20 UTC