Re: [apps-discuss] Concise Binary Object Representation (CBOR)

Carsten Bormann <> Thu, 23 May 2013 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2EF721F9783 for <>; Thu, 23 May 2013 10:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.356
X-Spam-Status: No, score=-105.356 tagged_above=-999 required=5 tests=[AWL=-1.272, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6WK-mNGmbFWC for <>; Thu, 23 May 2013 10:00:25 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id BD4B821F96E7 for <>; Thu, 23 May 2013 09:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r4NGrv5x021482; Thu, 23 May 2013 18:53:57 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DC83C3085; Thu, 23 May 2013 18:53:56 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <>
In-Reply-To: <>
Date: Thu, 23 May 2013 18:53:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Phillip Hallam-Baker <>
X-Mailer: Apple Mail (2.1503)
Cc: Paul Hoffman <>, General discussion of application-layer protocols <>
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2013 17:00:41 -0000

> The only types I have found a need for in my JSON schema are:
> Integer
> Float 
> String (UTF8)
> DateTime   (As RFC 3339 format string)
> Binary (as base64 encoded string)
> List (X)  - JSON List

CBOR is a pretty good match then (we also have a map/dictionary/table/JSON object).
(There is never a need to base-64 encode anything in CBOR.)

> Since most of the proposals are of the form <type> <data> where <type> and we only have 7 fundamental types it is quite easy to make the type octet combine the type and length information. So if the integer fits in 2 bytes then just use 2 bytes and mark the length in the type octet, the number 256 could be represented as:
> X2 01 00

(CBOR has a slightly different encoding of the first byte to be able to encode the number right there if it fits).

> I would use twos compliment for all values and so a 64 bit unsigned integer could potentially have 9 octets but that would be a rare event.

CBOR uses two different encoding types for unsigned and negative numbers.  See Figure 2 for an easy way to convert signed integers to that.

> A side benefit to this approach is that big numbers are easily supported.

CBOR also has a representation for big (> 64-bit) numbers (based on the byte string).

> Representing floats is a lot harder than the specs I have written seem to understand. In particular the main reason I would want a binary format for JSON is that it is NOT possible to round trip floats from decimal format to binary without special care.

Representing floats is rather easy -- IEEE 754 is well-documented.  So CBOR uses the three main binary floating point formats from that (Half, Single, Double).
If you do need (negative) base-10 exponents, we have a special Decimal fraction (inspired by YANG and EXI), trying not to use decimal mantissae.

> So the main reason for using a binary JSON is going to be not introducing the errors, possibly cumulative errors that round tripping from decimal to binary introduces.

That is one good reason (not the main one I'm interested in).

> So we do need to have 32 bit and 64 it floats.

Strictly, that is not needed, as every 32-bit float can be easily converted into a 64-bit float.
But the inverse (going down from 64 to 32 to 16, and checking whether that is lossless) is also easy.

Grüße, Carsten