Those were just examples. The hard part is parsing schemas, especially if
you're writing in C and don't know about yacc and lex. That code tends to
be horribly buggy.
But unless you need to support PER (which outright requires the schema) or
unless you are trying to map ASN.1 compound objects to C structs or the
equivalent, you can just process the whole thing in the same way you would
JSON, except that it's binary and there are more types. Easy-peasy,
especially in a dynamically typed language.
Once there was a person on the xml-dev mailing list who kept repeating
himself, insisting on the superiority of ASN.1 to XML. Finally I told him
privately that his emails could be encoded in PER by using 0x01 to
represent him (as the value of the author field) and allowing the
recipients to reconstruct the message from that! He took it in good part.
John Cowan
http://vrici.lojban.org/~cowan cowan(a)ccil.org
Don't be so humble. You're not that great.
--Golda Meir
On Fri, Jan 29, 2021 at 10:52 PM Richard Salz <rich.salz(a)gmail.com> wrote:
PER is not the reason for the hatred of ASN.1,
it's more that the specs
were created by a pay-to-play organization that fought against TCP/IP, the
specs were not freely available for long years, BER was too flexible, and
the DER rules were almost too hard to get right. Just a terse summary
because this is probably off-topic for TUHS.