I agree ASN.1 got a lot of things right. And the problem is that if you are baking a cake, its no longer a cake if there are too many rat droppings in it.
I have written multiple serializers and deserializers for each of the commonly used serialization formats, I have used a dozen schema languages and written another dozen. I created another serialization scheme only last week as it happens, needed something that works at the packet level that worked really well with my crypto.
The problem I see with ASN.1 and XML is that the schema languages are object description languages and thats a different thing from a serialization format. I have stopped talking about 'objects' on the wire and now refer to 'records' because I am not doing object broking, this is message exchange on the wire but they are not events either as I use the same format for stored data.
So the mistake I see in XML schema and also in most JSON schema proposals is that they try to capture the full expressive power of the lexical syntax and I am only interested in exchanging records and mapping them onto my application data structures. I do not want to have the schema saying 'x is an integer between 2 and 6'. I want 'x is an integer' and the only time I want to have more information is if x won't fit into 64 bits. Similarly, I don't want the schema to say '2 to 6 objects of type foo', the minimum number of entries in a list is always either 0 or 1 and the maximum is always 1 or infinity. Nothing else is needed at the schema layer. If you have detailed data constraints you can always apply them later.
On Mon, Mar 1, 2021 at 8:08 PM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
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.
