> - 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.