How about bencode? c-sexp? netstrings? The important features I would demand are: able to represent the types you need (e.g. integers instead of strings of digits or floats) and designed to have a canonical presentation from the beginning. There are so many bugs around ASN.1/XML/JSON parsing and "normalisation" that it's simply inexcusable to repeat this mistake. If the designers didn't come up with a really convincing explanation for selecting the wrong serialisation format for a cryptographic protocol how likely is it they read and understood the prior art in other fields like cryptography? Just because a canonical JSON (de-)serialiser is only a npm/pip/gem install is no excuse to burden a specification with the bloat and attack surface. Even fix sized, flat, packed structs are a better solution. K.I.S.S.!

I wish there was some language-agnostic tool for defining byte-oriented data strucrures that could emit code to manipulate them in different languages. Protobuf and similar tools exist but they still have their own weirdnesses and aren't entirely zero-overhead. I've seen plenty of pseudo-schemas used in standards documents, in particular the MLS spec which I think was finalized recently.