should decoder sort tags alphabetically in table directory?

Hello,

I'm working on writing a Python version of the woff2 encoder/decoder for @behdad's fontTools package.
I'm not a C/C++ programmer, so apologies if my code is a bit naïve -- it's simply meant to show roughly what I mean.

The problem has to do with the order of tags in the table directory, and whether it should be responsibility of the encoder or the decoder.
 
According to WOFF2 specs, section "2. General Requirements":
> When WOFF2 file is decompressed, the decoder MUST sort the tags in the table directory in ascending alphabetical order

Later on, at section "4. Table directory format", it adds:
> the WOFF2 table directory entries define the physical order of tables in which they have been processed and encoded as part of the compressed font data stream. It is a decoder responsibility to sort and reorder the table directory when the font file is decompressed.

Now, the woff2_dec.cc does not seem to do that. It just keeps the same order as the input file's table directory.

It's actually the encoder module woff2_enc.cc that changes the offsets fields in the table headers so that the table data are reordered by increasing tag values.

So apparently, rather than the decoder reordering the the table directory alphabetically, here it's the encoder which reorders the table data according to the input TTF/OTF table directory (which in turn must be sorted alphabetically as per OT specs).

By reading the WOFF2 specs, it seems to me that it should actually be the other way around: that is, the encoder defining the table directory as "the physical order", and the decoder reordering the table directory alphabetically.

But maybe I'm just missing something else...
Anyway, thank you and... merry christmas.

Cosimo

--- 

PS: Interestingly, the OpenType Sanitizer refuses to load a woff2 file whose table directory is not sorted alphabetically. I presume that's because it uses a very similar woff2 decoder that does not reorder the tags (cc @khaledhosny).