Re: Add extension work to Interop matrix

[Dmitri Tikhonov <[e-mail]>]

On Tue, Jan 07, 2020 at 03:16:48PM +0000, Lucas Pardue wrote:
> >     g   Datagram extension
> >     r   HTTP priorities extension
> >     q   Loss bits extension ('l' looks too much like '1')
> >     1   One-way delay extension
>
--- 8< --- SNIP --- 8< ---
> 
> Its great that people want to test these extensions out, but where its
> difficult to see why these extensions should be included an not others.

I did not state that we should exclude any extensions.  I believe
the list above is exhaustive.  If not, I am all for adding to it.

> We're at 19 "codes" right now, and not many implementations satisfy them
> all. I'd like to find a solution that is more sustainable in the longer
> term that can support extensions along with QUIC v2 or whatever comes next.

The good thing about the current form of the Interop matrix is that
it is easy to start a new sheet and that older matrices become useless
rapidly.  The English alphabet has 26 letters, so we are using
19 / (26 * 2 + 10) = 31% of all easily readable code available to us.
Going up to 23 codes (37%) is not a big deal.  I don't expect us to
run out.  Even if we do, we can always do something new with the
next version of the matrix.

(I considered proposing E1, E2, or Eq, Eg, but one-letter codes are
simpler and fit with the current model.)

> I don't know what that looks like but I'd take some inspiration from things
> like the QUIC Network Simulator interop runner and Web Platform Tests (
> https://wpt.fyi/results/?label=experimental&label=master&aligned).

My proposal is just to capture extension work in a simple, low entry
cost, manner.  I am not willing to commit to create a framework such
as to which you refer above.

  - Dmitri.