Message Pack[0] is another protocol that follows this very successful simplicity.
A leading thought in a lot of this is the "unset and a zero value are equivalent". It simplifies a lot of what the serializer and deserializers have to understand, and places the burden on code generation or libraries rather than complex serialization. It was unnatural for me to think this way, as I take the opposite for memory (record whether something is set or not, don't just assume it equals zero), but on the wire this makes for very compact and backwards compatible messaging.
Cap'n Proto[1] I have not played with, but would love to learn more about to see the advantages and disadvantages between protobuf, msgpack, and capn.
What makes it a standardized version of Message Pack?
Message Pack has a specification that is well documented[0] and even the rfc you refer to specifically states it has different goals (though, eliding specifics with pretty sad generalizations)[1]
> ...and even the rfc you refer to specifically states it has different goals (though, eliding specifics with pretty sad generalizations) [link to RFC7049, section 9]
You find those generalizations sad because that is the acknowledgements section!
If you start from the beginning, you only need to read three paragraphs to see that "Appendix E lists some existing binary formats and discusses how well they do or do not fit the design objectives of the Concise Binary Object Representation (CBOR)." [0]
If we look at Appendix E, [1] we find that section E.2 contains an explanation that you're likely to be more satisfied with. [2] However, before you go off and read section E.2, I strongly urge you to read the couple of paragraphs in Appendix E, first. The authors of RFCs generally tend to try hard to remove redundancy in their prose, and later sections often elide information covered in earlier sections.
Things like stating that "evolution has stalled" while also recognizing that the format is stable is hand wavy when you consider we're discussing things that go over the wire and even end up on disk. Yes, stability should be a goal.
The real difference between CBOR and MessagePack is that CBOR wants to be "schemaless" in the applications themselves instead of just on the wire. They hold up json as the example format for something that doesn't require schemas, and yet I see "json schemas" being published[0], and even people trying to standardize the schema format[1]! Looking at any modern JSON API would tell you that "schemas" in the xml sense are not required, but applications all must be very knowledgeable of the format.
Having a data type for "PCRE" is just insanity on the wire, and I can't imagine the type of API you'd be publishing where you would accept URLs or Regular Expressions or Text or Binary, AND want to be able to decode them into proper types in memory all without applications on both ends knowing that ahead of time.
Which brings me back to my initial point: CBOR is not just a "standardized Message Pack", it's a very different approach to what they think the applications on either end of a protocol should be doing.
I've done quite a bit of work with CBOR. I took a quick look over the Message Pack spec and found it a bit wanting. The CBOR encoding is more consistent and it allows one to easily define extensions (up to 2^64 worth http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml). One defined extension allows you to define references, which I found useful in encoding Lua tables.
A leading thought in a lot of this is the "unset and a zero value are equivalent". It simplifies a lot of what the serializer and deserializers have to understand, and places the burden on code generation or libraries rather than complex serialization. It was unnatural for me to think this way, as I take the opposite for memory (record whether something is set or not, don't just assume it equals zero), but on the wire this makes for very compact and backwards compatible messaging.
Cap'n Proto[1] I have not played with, but would love to learn more about to see the advantages and disadvantages between protobuf, msgpack, and capn.
[0]: http://msgpack.org/
[1]: https://capnproto.org/