From mboxrd@z Thu Jan 1 00:00:00 1970 From: cym224 at gmail.com (Nemo Nusquam) Date: Sat, 30 Jan 2021 21:47:26 -0500 Subject: [COFF] Joys of ASN.1 [Was: Re: tangential unix question: whatever happened to NeWS?] In-Reply-To: References: <20210124183653.GD21030@mcvoy.com> <202101242045.10OKjDvA964774@darkstar.fourwinds.com> <20210124211100.GI21030@mcvoy.com> <202101242114.10OLEYGk966708@darkstar.fourwinds.com> <20210124212525.GJ21030@mcvoy.com> <202101242333.10ONXjcI974038@darkstar.fourwinds.com> <202101250021.10P0L3Z2976588@darkstar.fourwinds.com> <6557f782-ecb1-6476-1eda-e23f30f9bbea@bitsavers.org> Message-ID: <60161A3E.9040702@gmail.com> Migration to COFF, methinks On 30/01/2021 18:20, John Cowan wrote: > 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. True but tools such as the commercial ASN.1 -> C translators are fairly good and even asn1c has come a long way in the past few decades. N. > > 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 at 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 > 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. >