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

Nico Williams <> Thu, 23 May 2013 20:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55CF921F8ECB for <>; Thu, 23 May 2013 13:49:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bxh8A2YI5jM9 for <>; Thu, 23 May 2013 13:49:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AFF2821F98CE for <>; Thu, 23 May 2013 13:08:41 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id E5C1A350084 for <>; Thu, 23 May 2013 13:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type;; bh=7r6/fvC/f2VWYQLT3kSi ANeylOQ=; b=HeqYbXt5N6ju12oDUBN4emkJeBj0NHHIBn6XiW0w3V3VOgLVcQ0Y fiVgBzugATohT5F1ewXsjassfUj1BZWs6ynpafuo5pB8xfCzA6YptCJEyUG+m47m E5/vybx+ZwVH/d1ePSQFxbVILmmJ+scaoDWtvmYtnf0kH+70b7w/y3U=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 23A0335001C for <>; Thu, 23 May 2013 13:08:15 -0700 (PDT)
Received: by with SMTP id t60so1351461wes.11 for <>; Thu, 23 May 2013 13:08:14 -0700 (PDT)
X-Google-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=epwgZglg5GJMQCozfoAriXb/hGMJpvNLq42g5aLJ9qc=; b=LormnldXBdNCrWM4IOivN22bhTp2w+7mRZQUqBmkx+MKdNxD6xl8xNlRiYZKrczM+H EE1H++4fC6dzddDPG8fyjwSfPau3NXG4mkpbx8Bs7ycrH5TLDBDYxaYwTXfDjTkZfyk1 B5izqJD7x1QVik0M9Wt3WHqQ/s/vLkxDK3cOkTF3UzkUESqFbdBmafiq6kt3FUACMX10 Ml2/Hn1sldcTS/Wj46DiIAVHZqnBAPie++O/yVr5lRQh9CoiO13GEKEvC7UQ/pDrLxJW ZybsYgurZv7qnDCZa+5sSWJQ4+5RDEIN6xE123myrau82/q5VABv81Ysly5+qDoSKS34 M3Tg==
MIME-Version: 1.0
X-Received: by with SMTP id p9mr46322422wik.27.1369339660926; Thu, 23 May 2013 13:07:40 -0700 (PDT)
Received: by with HTTP; Thu, 23 May 2013 13:07:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 23 May 2013 15:07:40 -0500
Message-ID: <>
From: Nico Williams <>
To: Phillip Hallam-Baker <>
Content-Type: text/plain; charset="UTF-8"
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:49:38 -0000

On Thu, May 23, 2013 at 2:42 PM, Phillip Hallam-Baker <> wrote:
> On Thu, May 23, 2013 at 12:13 PM, Nico Williams <>
> wrote:
>> 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.

Indeed, I meant that the encoding doesn't require a schema.  A schema
may still be used by the app, of course, but the codec has no
knowledge of if, and in particular the decoder cannot be required to
have knowledge of the schema.

> 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.

Well, they make some sense.  Documentation really helps though :)

(And BER... can be dumped, but when implicit tagging is used you lose
plenty of type metadata and have to resort to heuristics.)

> 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.

Right, like FastInfoSet (which uses PER).

> 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.

Yes.  If we need further compression then use zlib or similar.

> 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.

I agree that it's less important, and I won't insist on it.  It's just
a mild irritant to not have c14n, but maybe it's just me and I should
get over it for good.