The sad generalizations are in E.2<p>Things like stating that &quot;evolution has stalled&quot; while also recognizing that the format is stable is hand wavy when you consider we&#x27;re discussing things that go over the wire and even end up on disk. Yes, stability should be a goal.<p>The real difference between CBOR and MessagePack is that CBOR wants to be &quot;schemaless&quot; in the <i>applications</i> themselves instead of just on the wire. They hold up json as the example format for something that doesn&#x27;t require schemas, and yet I see &quot;json schemas&quot; being published[0], and even people trying to standardize the schema format[1]! Looking at any modern JSON API would tell you that &quot;schemas&quot; in the xml sense are not required, but applications all must be very knowledgeable of the format.<p>Having a data type for &quot;PCRE&quot; is just insanity on the wire, and I can&#x27;t imagine the type of API you&#x27;d be publishing where you would accept URLs or Regular Expressions or Text or Binary, <i>AND</i> want to be able to decode them into proper types in memory all without applications on both ends knowing that ahead of time.<p>Which brings me back to my initial point: CBOR is not just a &quot;standardized Message Pack&quot;, it&#x27;s a very different approach to what they think the applications on either end of a protocol should be doing.<p>[0]: <a href="http:&#x2F;&#x2F;json-schema.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;json-schema.org&#x2F;</a><p>[1]: tools.ietf.org&#x2F;html&#x2F;draft-zyp-json-schema-03