I spent a year of my life making an ASN.1 compiler in D
16 points by hoistbypetard
16 points by hoistbypetard
This made me snort-laugh:
ASN.1 is the result of a bunch of graybeards from the late 80s+ trying to design an overengineered data specification language. In other words, it’s protobuf on steroids.
mostly because I once thought of protobuf as a half-assed reinvention of ASN.1.
I still do.
I often see it used simply 'because', with no real technical reason as to why that should be preferred over any other form of IDL.
I do too, but have a little more sympathy for it now.
I'm one of those weirdos who likes ASN.1. But last time I navigated the purchase of a compiler and runtime, it was so painful that I can absolutely see why an organization might write protobuf and get the exact tooling they want instead. Even so, I don't think anything else is as good as ASN.1 for documenting a wire protocol/message format. I wish there was better tooling for it that didn't cost 5 figures per seat.
What does 5 figures give you that https://github.com/vlm/asn1c or similar projects don't?
The one you linked is the best of the FOSS alternatives, as far as I recall. There were a few things last time I looked in detail:
We also found that JER support let us do some really interesting analysis, though we didn't actually need that for production things.
We were a small team, and could not take on maintaining an ASN.1 compiler and runtime ourselves. We did consider hiring a contractor to fix the gaps we cared about most. Particularly the relative OID support and constraints support and a series of other smaller things that we used heavily. But we concluded that it'd cost us more than we'd need to spend on 5 years of maintenance for the commercial tooling, in addition to the time it'd take to get it done.
Looking at the current state of the lionet asn1c toolset, some of the compatibility we cared about seems likely to have been addressed by now. And it looks like they've probably fixed the warnings for runtime stuff at least if not the compiler itself. But I'd want to dedicate someone to spending time on the open issues in their issue tracker before relying on it in production. Which is completely fair, especially given the eye-watering costs of the alternatives.
It'd be really cool to be able to do that, though. Because I think a few things on the internet would be better if the open tooling story for ASN.1 were as good as protobuf's.
ASN.1 does something which I don’t remember seeing in other RPC / data description frameworks: it has a bunch of different encoding rules that can be used to serialize objects described in the abstract notation. So there’s BER, the basic encoding rules, PER, the packed encoding rules (bandwidth was scarce in the 1980s), DER, the distinguished encoding rules (because BER is too loosey-goosey for cryptographic applications and x.500 is one of the main uses of ASN.1), and XER, the XML encoding rules (because that was the thing 25 years ago).
There’s a funny pattern where OSI protocols get ported to the internet and get reduced in the process, eg LDAP is more lightweight than the OSI directory access protocol, and SNMP is more simple than the OSI network management protocol. (But not reduced so much that they got rid of ASN.1). I was about to joke that SOAP is simpler than XER, but I checked the timeline and XER is a few years later than SOAP – and of course SOAP is unrelated to OSI so the joke was on a weak footing from the start.
ASN.1 has various separate value forms that start with a left bracket ({), a lot of these forms are ambiguous due to a variety of factors and can only be distinguished with semantic context.
Is a schema not required for parsing ASN.1 value notation, which would remove all ambiguity? Or am I missing something here?
As I recall, the requirement for a schema depends upon which encoding rules used.
Some (PER?) absolutely need a schema, whereas others (DER and probably BER?) don't.