CBOR relationship with msgpack

[charlesroddie]

The current draft of CBOR (Oct 23 2018): https://tools.ietf.org/html/draft-ietf-cbor-7049bis-04

There doesn't appear to have been any communication between CBOR and msgpack for the last 5 years:

• 5 years ago, @cabo branched CBOR off from msgpack and submitted to IETF.
• @frsyuki expressed concerns about compatibility in going to IETF: link.
• Joe Hildebrand suggested that by being involved in the process and specifying compatibility conditions this could be prevented: link.
• I am not able to find any other correspondence between cbor and msgpack, but it could just be that they are using email message boards to communicate which are hard to search.

For a user it would be good to have an idea of differences and compatibility when deciding which to use. Is data currently serialized with msgpack valid CBOR? It would also be good to have some communication to ensure that CBOR ends up as a well thought-out standard.

[cabo]

CBOR already has been an Internet Standards document since October 2013: please see https://tools.ietf.org/html/rfc7049. CBOR was created so we were able to use a standard binary serialization for JSON-like data models in IoT standards and beyond, including support for binary data and a concept for extensibility. CBOR is currently being used by a couple dozen IETF specifications in various stages as well as by other standards development organizations.

As you noted, the now more than five years old specification is currently in a process of revision (the document is worked on as CBORbis or 7049bis). This is not about technical changes (CBOR is stable and has well-defined extension points that are actively being used) but about cleaning up the specification text, removing the (trivial) errata, and addressing some finer points of interoperability — the latter are important for CBOR because the specification is being used outside of tightly coupled software bases. If you want to watch this process, you can find the most recent editors' copy of the revised specification on github, e.g., https://cbor-wg.github.io/CBORbis/draft-ietf-cbor-7049bis.html, and the repository at https://github.com/cbor-wg/CBORbis. (Note that until recently, most efforts of the WG went into completing the CDDL specification, a language for describing the shape of CBOR data structures – this currently covers CBOR and JSON, but could be used with msgpack or other JSON-like formats if there is interest).

In 2013, when we gave up trying to drag msgpack into a standardization process, we used the opportunity to clean up the msgpack format, so CBOR is not byte-for-byte compatible to msgpack. (It is close enough that some early CBOR implementations were derived from msgpack implementations.)

But that doesn't mean the current revision of the CBOR specification text cannot benefit from experience that has been gained with msgpack. The IETF is wide open for contributions, no formal membership is required. The best way in is to join the mailing list of the CBOR WG, please see https://www.ietf.org/mailman/listinfo/cbor. Of course, you can also contribute right into the CBORbis document issues list, https://github.com/cbor-wg/CBORbis/issues. But please do keep in mind that the current process is not about making wild technical changes but about further increasing the stability and interoperability of what already is a quite stable specification.