JSON-LD seems to fit modern needs from an extensibility / simplicity point of view. All the bit-packing goodness of various encodings are dreadful from an interoperability point of view. Rich formalisms and separation of syntax and "encoding rules" seem counter-productive. -- https://LarryMasinter.net https://interlisp.org > -----Original Message----- > From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Nico Williams > Sent: Monday, March 1, 2021 5:08 PM > To: ietf@xxxxxxxx > Subject: What ASN.1 got right > > As an ASN.1 implementor, I can tell you things I, like many of you, hate about > ASN.1: > > - ugly syntax (made uglier by having tags as optional lexical elements) > > - ugly OIDs (should have been URNs or URN-like) > > - BER/DER/CER and all TLV encodings in the world (protocol buffers, I'm > looking at you too) are awful > > - the fact that the specs were, for a long time, non-free, which led to > a dearth of open source tooling that still persists somewhat (though > not as bad as it used to be) > > - the fact that for years people hand-rolled their codecs due to the > previous item, and so created many bugs > > - X.400/X.500, which are not part of ASN.1, of course, but closely > related -- especially X.500 style naming! > > Having recently implemented automatic open type decoding handling X.681/ > X.682/X.683 (see RFCs 6025 for some insight, and 5912 for real examples that > I'm making use of), I can tell you that ASN.1 got some things > right: > > - rich formalisms ("constraints") > > - separation of syntax and encoding rules > > The fact that there are many encoding rules for ASN.1, of almost every kind > (binary TLV, binaray non-TLV, and textual, including XML- and JSON-based > rules) proves the last point. I can't help but see how XDR, NDR, and > flatbuffers, among many other encodings out there, could easily be used > with ASN.1. (E.g., what XDR and NDR call "pointers" are just optional fields in > ASN.1.) > > The fact that one can implement automatic open type decoding using ASN.1 > formalisms and those already published in, e.g., RFC 5912[*] proves the > utility of those formalisms. I now get to see certificates and many other > things in all their "glorious" detail as JSON, including all extensions and what > not, and that's made possible by these formalisms. > > I beg the next person to re-invent this darned wheel to please educate > themselves as to what came before. Among many lessons you should learn, > learn that some things can't be monetized well enough, or at all, or can only > be monetized in exchange for limiting their adoption, so figure out what your > goals are, then align pricing and licensing with those. > > And since open types appear to be unavoidable, but also always a pain if you > don't have the metaschema to express the metadata needed to automate > their handling, don't forget to cover that. > > XML, of course, with namespaces and references, has a reasonable approach > to open types as well. It's not just ASN.1 that gets that right well enough. > > Nico > > [*] A big thank you to RFC 5912's authors, though sadly one of them has > passed.
