5 ms·

ASN.1 was too broad. There is immense value in a more constrained specification that does not include so many hazardous serialization types and antiquated strin

by bri3d 5y ago

ASN.1 was too broad. There is immense value in a more constrained specification that does not include so many hazardous serialization types and antiquated string formats. Now, should Protobufs or Thrift simply have been constrained versions of ASN.1? I think there is a view of software engineering where this would have been an ideal outcome, but almost universally when we see too-big standards, they are declared "dangerous" and avoided like the plague before they are downscoped.

cryptonector 5y ago
ASN.1 in 1984 was not too broad. It was too simple, and it was too targeted to tag-length-value encoding rules (which are stupid -- TLV is a crutch that is only maybe useful when you lack a compiler, which early on was the case). ASN.1 today is as broad as it needed to evolve to be because its users needed it.
- oblio 5y ago
  There is value in throwing away cruft, especially cruft that comes from the IT Middle Ages (before we decided to drop any non 8 bit word sizes, before UTF-8 became the almost universal string encoding, etc.).
  - cryptonector 5y ago
    Maybe, but ASN.1 is a Chesterton's fence. Before you throw it away and reinvent it badly, acquaint yourself with it. And you might notice that ASN.1 has a long history, but it's thoroughly modern today, and much more so than many alternatives to ASN.1 that have been created even in recent times.
    - bri3d 5y ago
      I agree with this, and I think that overall the Chesterton's Fence principle should be applied more in software engineering. What's hard is finding a set of "thoroughly modern" ASN.1 implementations that work together, and trusting that they will do so. The name is overloaded by the years of revisions and cruft.
      - cryptonector 5y ago
        Fabrice Bellard has a proprietary ASN.1 compiler that looks very modern and very very featureful. Heimdal's ASN.1 compiler is getting to where we should separate it and make it a standalone project. It's really quite featureful, and it's also getting to where adding support for PER, OER, NDR, XDR, XER, JER, and other things should be quite easy: just write a bytecode interpreter for each of those. I only need NDR and JER, so I'll be adding those (already it can dump values as JSON, but it's not quite JER compliant). Also, I've begun adding support for dumping ASN.1 modules (not just values) as JSON with an eye towards rewriting the codegen and bytecode generator in jq, and then maybe adding support for targeting languages other than C. It really helps to have a decent implementation to stand on for this, and I am really standing on the shoulders of giants here.

by bri3d 5y ago

cryptonector 5y ago

ASN.1 in 1984 was not too broad. It was too simple, and it was too targeted to tag-length-value encoding rules (which are stupid -- TLV is a crutch that is only maybe useful when you lack a compiler, which early on was the case). ASN.1 today is as broad as it needed to evolve to be because its users needed it.

oblio 5y ago
There is value in throwing away cruft, especially cruft that comes from the IT Middle Ages (before we decided to drop any non 8 bit word sizes, before UTF-8 became the almost universal string encoding, etc.).
- cryptonector 5y ago
  Maybe, but ASN.1 is a Chesterton's fence. Before you throw it away and reinvent it badly, acquaint yourself with it. And you might notice that ASN.1 has a long history, but it's thoroughly modern today, and much more so than many alternatives to ASN.1 that have been created even in recent times.
  - bri3d 5y ago
    I agree with this, and I think that overall the Chesterton's Fence principle should be applied more in software engineering. What's hard is finding a set of "thoroughly modern" ASN.1 implementations that work together, and trusting that they will do so. The name is overloaded by the years of revisions and cruft.
    - cryptonector 5y ago
      Fabrice Bellard has a proprietary ASN.1 compiler that looks very modern and very very featureful. Heimdal's ASN.1 compiler is getting to where we should separate it and make it a standalone project. It's really quite featureful, and it's also getting to where adding support for PER, OER, NDR, XDR, XER, JER, and other things should be quite easy: just write a bytecode interpreter for each of those. I only need NDR and JER, so I'll be adding those (already it can dump values as JSON, but it's not quite JER compliant). Also, I've begun adding support for dumping ASN.1 modules (not just values) as JSON with an eye towards rewriting the codegen and bytecode generator in jq, and then maybe adding support for targeting languages other than C. It really helps to have a decent implementation to stand on for this, and I am really standing on the shoulders of giants here.