Details please.

Things people say who know very little about ASN.1:

- it's bloated! (it's not)

- it's had lots of vulnerabilities! (mainly in hand-coded codecs)

- it's expensive (it's not -- it's free and has been for two decades)

- it's ugly (well, sure, but so is PB's IDL)

- the language is context-dependent, making it harder to write a parser for (this is quite true, but so what, it's not that big a deal)

The vulnerabilities were only ever in implementations, and almost entirely in cases of hand-coded codecs, and the thing that made many of these vulnerabilities possible was the use of tag-length-value encoding rules (BER/DER/CER) which, ironically, Protocol Buffers bloody is too.

If you have a different objections to ASN.1, please list them.

▲ theamk 4 days ago | parent [-]

Neither of those, the main problems are:

- There is no backward or forward compatibility by default.

(Sure, you can have every SEQUENCE have all fields OPTIONAL and ... at the end, but how many real-life schemas like that you have seen? Almost every ASN.1 you can find on the internet is static SEQUENCE, with no extensibility whatsoever)

- Tools are bad.

Yes, protoc can be a PITA to integrate into build system, but at least it (1) exists, (2) well-tested (3) supports many languages. Compared to ASN.1 where the good tooling is so rare, people routinely manually parse/generate the files!

- Honorable mention: using "tag" in TLV to describe only the type and not field name - that SEQUENCE(30) tag will be all over the place, and the contents will be wildly different. Compare to protobuf, where the "tag" is field index, and that's exactly what allows such a great forward/backward compatibility.

(Could ASN.1 fix those problems? Not sure. Yes, maybe one could write better tooling, but all the existing users know that extensibility is for the weak, and non-optional SEQUENCEs are the way to go. It is easier to write all-new format than try to change existing conventions.)

	▲	cryptonector 3 days ago \| parent [-]
		> - There is no backward or forward compatibility by default. ASN.1 in 1984 had it. Later ASN.1 evolved to have a) explicit extensibility markers, and b) the `EXTENSIBILITY IMPLIED` module option that implies every SEQUENCE, SET, ENUM, and other things are extensible by default, as if they ended in `, ...`. There are good reasons for this change: - not all implementors had understood the intent, so not all had implemented "ignore unexpected new fields" - sometimes you want non-extensible things - you may actually want to record in the syntax all the sets of extensions > - Tools are bad. But there were zero -ZERO!- tools for PB when Google created PB. Don't you see that "the tools that existed were shit" is not a good argument for creating tools for a completely new thing instead? > - Honorable mention: using "tag" in TLV to describe only the type and not field name - that SEQUENCE(30) tag will be all over the place, and the contents will be wildly different. Compare to protobuf, where the "tag" is field index, and that's exactly what allows such a great forward/backward compatibility. In a TLV encoding you can very much use the "type" as the tag for every field sometimes, namely when there would be no ambiguity due to OPTIONAL fields being present or absent, and when you do have such ambiguities you can resort to manual tagging with field numbers or whatever you want. For example: `Thing ::= SEQUENCE { a UTF8String, b UTF8String }` works even though both fields get the same tag (when using a TLV encoding) because both fields are required, while this is broken: `Broken ::= SEQUENCE { a UTF8String OPTIONAL, b UTF8String }` and you would have to fix it with something like: `Fixed ::= SEQUENCE { a [0] UTF8String OPTIONAL, b UTF8String }` What PB does is require the equivalent of manually applying what ASN.1 calls IMPLICIT tags to every field, which is silly and makes it harder to decode data w/o reference to the module that defines its schema (this last is sketchy anyways, and I don't think it is a huge advantage for the ASN.1 BER/DER way of doing things, though others will disagree). > (Could ASN.1 fix those problems? Not sure. Yes, maybe one could write better tooling, but all the existing users know that extensibility is for the weak, and non-optional SEQUENCEs are the way to go. It is easier to write all-new format than try to change existing conventions.) ASN.1 does not have these problems. Better tooling does exist and can exist -- it's no different than writing PB tooling, at least for a subset of ASN.1, because ASN.1 does have many advanced features that PB lacks, and obviously implementing all of ASN.1 is more work than implementing all of PB. > It is easier to write all-new format than try to change existing conventions. Maybe, but only if you have a good handle on what came before. I strongly recommend that you actually read x.680.