> How does ASN.1 compare to something like binary protobuf?
Protobuf is probably easier to work with in many cases, but there are a few issues that I've run across that makes protobuf a greater challenge in production:
1. Backwards compatibility.
proto2 vs. proto3 for example introduced changes that you can work around but could cause issues if you're upgrading. Among those changes was the handling of optional vs. required elements; this may have changed since, but IIRC proto3 makes all elements optional.
ASN.1 also supports explicit extensibility and message versioning.
2. ASN.1 supports canonical encodings (CER and DER for sure, and I think there are canonical encodings for PER and XML), which means that the same data are encoded exactly the same way across the wire. Protobuf doesn't guarantee element ordering. When hashing messages, this is important.
3. ASN.1 supports length and value constraints, and compilers can take advantage of these in message validation and (in some cases) message compression. Protobuf, last I checked, did not.
ASN.1 predates open source software, though, and that means that most (all?) of the viable solutions are commercial (Objective Systems, OSS Nokalva, Marben, etc), or else rolled in-house (e.g., erlang). My guess is that the older standards were designed in part by LISPers: I'm not sure how else you would produce a general solution for MACRO constructions in their absence.
It's also much easier to construct a safe parser if you can use metaprogramming and effectively build a parser from generic blocks.
Consider also how ASN.1 heavily uses specifications that are supposed to be read by compiler generators, something that also is replicated in Protobuf, but with less expressive power.
Protobuf is probably easier to work with in many cases, but there are a few issues that I've run across that makes protobuf a greater challenge in production:
1. Backwards compatibility.
proto2 vs. proto3 for example introduced changes that you can work around but could cause issues if you're upgrading. Among those changes was the handling of optional vs. required elements; this may have changed since, but IIRC proto3 makes all elements optional.
ASN.1 also supports explicit extensibility and message versioning.
2. ASN.1 supports canonical encodings (CER and DER for sure, and I think there are canonical encodings for PER and XML), which means that the same data are encoded exactly the same way across the wire. Protobuf doesn't guarantee element ordering. When hashing messages, this is important.
3. ASN.1 supports length and value constraints, and compilers can take advantage of these in message validation and (in some cases) message compression. Protobuf, last I checked, did not.
ASN.1 predates open source software, though, and that means that most (all?) of the viable solutions are commercial (Objective Systems, OSS Nokalva, Marben, etc), or else rolled in-house (e.g., erlang). My guess is that the older standards were designed in part by LISPers: I'm not sure how else you would produce a general solution for MACRO constructions in their absence.