Here was Kenton Varda's response: https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4 https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4 My

Here was Kenton Varda's response: https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4 https://groups.google.com/forum/#!topic/protobuf/eNAZlnPKVW4 My understanding of ASN.1 is that it has no affordance for forwards- and backwards-compatibility, which is critical in distributed systems where the components are constantly changing. ... OK, I looked into this again (something I do once every few years when someone points it out). ASN.1 _by default_ has no extensibility, but you can use tags, as I see you have done in your example. This should not be an option. Everything should be extensible by default, because people are very bad at predicting whether they will need to extend something later. The bigger problem with ASN.1, though, is that it is way over-complicated. It has way too many primitive types. It has options that are not needed. The encoding, even though it is binary, is much larger than protocol buffers'. The definition syntax looks nothing like modern programming languages. And worse of all, it's very hard to find good ASN.1 documentation on the web. It is also hard to draw a fair comparison without identifying a particular implementation of ASN.1 to compare against. Most implementations I've seen are rudimentary at best. They might generate some basic code, but they don't offer things like descriptors and reflection. So yeah. Basically, Protocol Buffers is a simpler, cleaner, smaller, faster, more robust, and easier-to-understand ASN.1.