Re: The "CBOR Everywhere" Project

On 2022-12-15 10:05, Christopher Allen wrote:
> On Wed, Dec 14, 2022 at 8:20 PM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> 
>     For me it is obvious that developers of new designs should seriously consider CBOR as an alternative to JSON and XML:
> 
>     https://github.com/cyberphone/cbor-everywhere <https://github.com/cyberphone/cbor-everywhere>
> 
> 
> Here is my own list of answers for "Why CBOR?":

Thanks Christopher,
I have only looked at this topic from a JSON/XML horizon.

The conversion ("upgrade") is simple with one exception; I'm not entirely convinced that adopting the CBOR tag system is sufficient for everybody, which is why I have toyed with a new CBOR construct:
https://github.com/cyberphone/cbor-everywhere#url-based-object-identifiers

Some CBOR folks maintain that URLs are not only big but bad as well.  However, high-level systems like Open Banking are frequently updated as well as defining many object types, both which seem to speak for locally managed namespaces.

Thoughts?

Anders


> 
> Why CBOR?
> 
> The Concise Binary Object Representation, or CBOR, was chosen as the foundational data structure for Gordian specifications such as Envelope and URs for a variety of reasons. These include:
> 
> * IETF Standardization. CBOR is a mature open international IETF standard.
> * IANA Registration. CBOR is further standardized by the registration of common data types through IANA.
> * Fully Extensible. Beyond that, CBOR is entirely extensible with any data types desired, such as our own listing of UR tags.
> * Self-describing Descriptions. Data is self-describing, so there are no requirements for pre-defined schemas nor more complex descriptions such as those found in ASN.1.
> * Streaming Friendly. CBOR works well with streaming without requirements for extra memory; its tagging system allows for data to be skipped if it is irrelevent or unknown.
> * Constraint Friendly. CBOR is built to be frugal with CPU and memory, so it works well in constrained environments such as on cryptographic silicon chips.
> * Unambiguous Encoding. Our use of Deterministic CBOR, combined with our own specification rules, such as the sorting of Envelopes by hash, results in a singular, unambiguous encoding.
> * Multiple Implementations. Implementation are available in a variety of languages.
> Compact Implementations. Compactness of encoding and decoding is one of CBOR's core goals; implementations are built on headers or snippets of code, and do not require any external tools.
> 
> See also:
> * a comparison to protobuffers: https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md#qa <https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md#qa>
> * a comparison to Flatbuffers
> https://stackoverflow.com/questions/47799396/flatbuffers-vs-cbor <https://stackoverflow.com/questions/47799396/flatbuffers-vs-cbor>)
> * a comparison to other binary formats
> https://www.rfc-editor.org/rfc/rfc8949#name-comparison-of-other-binary- <https://www.rfc-editor.org/rfc/rfc8949#name-comparison-of-other-binary->
> 
> -- Christopher Allen
>

Received on Thursday, 15 December 2022 09:41:58 UTC