[flowerthoughts]

The ASN.1 notation wasn't meant for parsing. And then people started writing parsing generators for it, so they adapted. However, you're abusing a text format for human reading and pretending it's a serialization format.

The BER/PER are binary formats and great where binary formats are needed. You also have XER (XML) and JER (JSON) if you want text. You can create an s-expr encoding if you want.

Separate ASN.1--the data model from ASN.1--the abstract syntax notation (what you wrote) from ASN.1's encoding formats.

[1] https://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx

[eadmund]

> However, you're abusing a text format for human reading and pretending it's a serialization format.

They should be the same, in order to facilitate human debugging. And we were discussing ASN.1, not its serialisations. Frankly, I thought that it was fairer to compare the S-expression to ASN.1, because both are human-readable, rather than to an opaque blob like:

    MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui/9UGSXau/2P8LjnTD8V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm

Sure, that blob is far more space-efficient, but it’s also completely opaque without tooling. Think how many XPKI errors over the years have been due to folks being unable to know at a glance what certificates and keys actually say.

[flowerthoughts]

> And we were discussing ASN.1, not its serialisations.

You said

>> Would you rather write a parser for this:

which suggested you were talking about serializations. I apologize if I misunderstood.

[eadmund]

No worries! ASN.1 is a bit weird because there’s a textual version and then a bunch of serialisations.

I think that human-readable is more important than space-efficient. At some point an engineer is going to be looking at bytes in a dump or debugger, and it sure is nice to be able to quickly know what they are.