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

Phillip Hallam-Baker <> Thu, 23 May 2013 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A521B21F9787 for <>; Thu, 23 May 2013 08:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.968
X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hliu5tbc5L1p for <>; Thu, 23 May 2013 08:41:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 562B621F9780 for <>; Thu, 23 May 2013 08:41:30 -0700 (PDT)
Received: by with SMTP id u10so3589470lbi.33 for <>; Thu, 23 May 2013 08:41:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EadpByTrLQM7ElCt62nwkhPbggwcUQnKjUxGHMhNmXw=; b=a3boFOy+ySO9DVHZIZ5KkIAM+X2UF5dvwLKSxZ31iGklA1qel1fegIGGQdlr6J8IHL snQPG8A+3bNIbCO48+znY/gIwwnsnVi4xaKcWFbbz1ep8ulL7ROmLko+keB22bjIIHzm nXrafQaINHYf0bJKtm2kzoDuGERh0X7SfIQbDFfeODyHsOfmkOwaBpHQSJQgEERV3asA S+GvlU+IvkZeXkItBGPK79GMoL0dhfUa2CqigOu6gSt7r3UaVG82EvV5TZYsTKoA5qel uhcopyj2N3yiAbju1ibnl0xSNnoztLI6gW+X0Ug9MeVCGXgvOi6bX3J/klmr2v18Q1xV 3hkQ==
MIME-Version: 1.0
X-Received: by with SMTP id bk8mr703362lbb.73.1369323686703; Thu, 23 May 2013 08:41:26 -0700 (PDT)
Received: by with HTTP; Thu, 23 May 2013 08:41:26 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 23 May 2013 11:41:26 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary="001a11c37a0aedb72204dd6483fa"
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 15:41:38 -0000

On Thu, May 23, 2013 at 1:27 AM, Nico Williams <>wrote:

> Thoughts:
>  - if we're going to have an RFC on JSON, might as well have one on
> some binary encoding of JSON
>  - yet another encoding.  yay.
>  - this encoding does suffice for encoding JSON
>  - this encoding can go beyond JSON -- this is good, but a strict
> JSON-equivalent subset should be specified
>  - yeah, multiple ways of encoding a given value suck; in particular,
> for the JSON-equivalent subset, there should be only doubles, no
> floats, no integers
>  - might as well have a type for "octet string" -- no base64 encoding
> please

+1 to Nico.

The only types I have found a need for in my JSON schema are:

String (UTF8)
DateTime   (As RFC 3339 format string)
Binary (as base64 encoded string)
List (X)  - JSON List

I do think that it is worth calling out DateTime and Binary for special
treatment because they both appear very frequently in code. I have not
found a need for any other special format.

For Integers, I only use double for representation but that is a design
choice that does not affect bits on the wire. For a binary format I would
prefer that like JSON, the wire format be neutral with respect to the code

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

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.

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

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.

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.

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