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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3F6A21F97EA for <>; Thu, 23 May 2013 13:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hz7BUYby2Le8 for <>; Thu, 23 May 2013 13:22:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22b]) by (Postfix) with ESMTP id 4923221F9731 for <>; Thu, 23 May 2013 12:42:19 -0700 (PDT)
Received: by with SMTP id ez20so3688690lab.30 for <>; Thu, 23 May 2013 12:42:18 -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=dfThcFuMJul61GJGy2StEX4LUHVPfz+BrzO+FGiiafI=; b=UvXJJWtdtMsrtRCXwZ/zem2lEcQCyOPblEin2IGOb0f+K+2+H09cnJGKsyTmt6FNgh g09poi6AQhg1N1C3vlEgm7IDHmyeuwjLke9XI5Bq50LdQYRBb/DXqg+0YBAU8OfZQaDp XMohMed8eOBWB/APkPmcr8WLD7WH2Ur1+zwBGZk7shfFNQaesO3J2uZJ7pwjhuyJI1v3 i9rJBmP2ebo2ipzwWfPmOWvbqxY0Ar2tDAaX1+QRXhkeM78z5DW83Cc7rdhggCGq1rJC BoFX2pX8g97UV/WU8GI9YBo1Cj28ZxRi3ong5w640XJvxFgGJJ+6rZ6EO0xBCX4g1MMP SIaQ==
MIME-Version: 1.0
X-Received: by with SMTP id ka3mr7076748lbc.113.1369338138027; Thu, 23 May 2013 12:42:18 -0700 (PDT)
Received: by with HTTP; Thu, 23 May 2013 12:42:17 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Thu, 23 May 2013 15:42:17 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary="001a11c32a064b6d1504dd67e1fa"
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 20:23:11 -0000

On Thu, May 23, 2013 at 12:13 PM, Nico Williams <>wrote:

> Also, I believe this is the fifth binary encoding of JSON proposed
> thus far.  Can we list the ones that have been proposed thus far?
> Here's a [no-doubt partial] list:
>  - BSON
>  - MsgPack
>  - Smile
>  - CBOR
> That's just the ones I recall seeing before or which I found in 30
> seconds of searching.
> Some of these are used in actual protocols right now.


I don't see any particular reason to favor this new proposal.

> I do agree that we need a schema-less encoding (which means we can't
> get as good as PER and friends).  We probably don't need a
> schema-capable encoding for JSON (though that might be nice).  We do
> need schema-aware encodings for some protocols, but we have plenty
> already, and none are nor need to be JSONish.

What I think you intend here is that the encoding should not be
schema-aware. Whether or not you have a formal schema is not the issue
here, the issue is whether it is necessary to know the schema to make sense
of the wire format.

One of the main reasons that JSON and XML encodings are attractive is that
you can look at the wire format and make sense of them. ASN.1 BER encoding
can also be read with an appropriate dump tool. It has to be possible to do
the same with Binary JSON.

Some of the compact XML representations used knowledge of the schema to
improve packing density and some could be read using a dump tool but
required knowledge of the mapping from the text representation to the
binary to be able to convert from one to the other.

I think it is clear that any JSON binary coding has to be readable without
knowledge of a schema and that a non-schema aware tool must be able to
convert between the two formats.

Insisting on a single representation for a number seems much less important
to me. Whether 7 is represented in one, two, four or eight bytes seems to
me to be something that can be left to the implementations.