Comment by flowerthoughts
4 days ago
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
> 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:
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.
> 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.
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.