Skip to content

Instantly share code, notes, and snippets.

@tkellogg

tkellogg/CBOR-objectives.md

Last active August 29, 2015 14:15
Show Gist options
  • Save tkellogg/5a84c5307f1e0415887a to your computer and use it in GitHub Desktop.
Save tkellogg/5a84c5307f1e0415887a to your computer and use it in GitHub Desktop.
Download ZIP
I copy & pasted this from RFC 7049 (http://tools.ietf.org/html/rfc7049) because I believe it succinctly embodies many of the goals of IoT. TL;DR - it must be simple, interchangeable, small wire size and small code size
Raw
CBOR-objectives.md

Objectives

The objectives of CBOR, roughly in decreasing order of importance, are:

  1. The representation must be able to unambiguously encode most common data formats used in Internet standards.
    • It must represent a reasonable set of basic data types and structures using binary encoding. "Reasonable" here is largely influenced by the capabilities of JSON, with the major addition of binary byte strings. The structures supported are limited to arrays and trees; loops and lattice-style graphs are not supported.
    • There is no requirement that all data formats be uniquely encoded; that is, it is acceptable that the number "7" might be encoded in multiple different ways.
  2. The code for an encoder or decoder must be able to be compact in order to support systems with very limited memory, processor power, and instruction sets.
    • An encoder and a decoder need to be implementable in a very small amount of code (for example, in class 1 constrained nodes as defined in [CNN-TERMS]).
    • The format should use contemporary machine representations of data (for example, not requiring binary-to-decimal conversion).
  3. Data must be able to be decoded without a schema description.
    • Similar to JSON, encoded data should be self-describing so that a generic decoder can be written.
  4. The serialization must be reasonably compact, but data compactness is secondary to code compactness for the encoder and decoder.
    • "Reasonable" here is bounded by JSON as an upper bound in size, and by implementation complexity maintaining a lower bound. Using either general compression schemes or extensive bit-fiddling violates the complexity goals.
  5. The format must be applicable to both constrained nodes and high- volume applications.
    • This means it must be reasonably frugal in CPU usage for both encoding and decoding. This is relevant both for constrained nodes and for potential usage in applications with a very high volume of data.
  6. The format must support all JSON data types for conversion to and from JSON.
    • It must support a reasonable level of conversion as long as the data represented is within the capabilities of JSON. It must be possible to define a unidirectional mapping towards JSON for all types of data.
  7. The format must be extensible, and the extended data must be decodable by earlier decoders.
    • The format is designed for decades of use.
    • The format must support a form of extensibility that allows fallback so that a decoder that does not understand an extension can still decode the message.
    • The format must be able to be extended in the future by later IETF standards.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment