How does this compare to other similar specifications, e.g. MsgPack and BSON?
It also seems to have a better implementation of streaming data than msgpack. In msgpack, streaming is something you have to implement outside of the format itself, possibly by concatenating together many msgpack representations. CBOR has a way to say "here comes a streaming list, I'll tell you when it's done".
BSON is a representation of MongoDB's data model and doesn't make that much sense to use without MongoDB.
I currently use msgpack for a lot of things, but if CBOR's Python library is good enough, I might switch.
I read somewhere that CBOR was better designed for extensibility, but don't know anything further about it.
One difference (on the non-technical side) is that CBOR is standardized through IETF.
The problem is that the 'str' type contains arbitrary binary data in an unspecified encoding, and always will, because of backward compatibility. This isn't changed by adding a 'bin' type.
Msgpack decoders in Python, for example, have to give you bytestrings unless you pass an option that promises that 'str's are all encoded in UTF-8.
Raw
String extending Raw type represents a UTF-8 string
Binary extending Raw type represents a byte arrayBut the link you posted referred to three types, where "str" and "bin" subclass "raw", which sounded like it provided a non-backward-compatible "str" that's guaranteed to be text.
Tags are used to apply meta information to a piece of datum. For example, you can tag a UTF-8 string as a URL or tag an array with a reference so it can be referred to elsewhere in the CBOR encoded data (an extension defined by the IETF but outside RFC-7049).
Having written an implementation (the Lua one) I quite like this format, it's flexible, not too complicated and still quite compact.