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

Carsten Bormann <> Thu, 23 May 2013 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D093511E812F for <>; Thu, 23 May 2013 09:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.565
X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, 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 84CyD8m6G1bC for <>; Thu, 23 May 2013 09:23:20 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id 8FF1211E80EC for <>; Thu, 23 May 2013 09:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r4NGNDCF026195; Thu, 23 May 2013 18:23:13 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 48DF83050; Thu, 23 May 2013 18:23:13 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset="utf-8"
From: Carsten Bormann <>
In-Reply-To: <>
Date: Thu, 23 May 2013 18:23:12 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Nico Williams <>
X-Mailer: Apple Mail (2.1503)
Cc: Paul Hoffman <>,
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 16:23:27 -0000

On May 23, 2013, at 17:35, Nico Williams <> wrote:

> On Thu, May 23, 2013 at 2:15 AM, Carsten Bormann <> wrote:
>> On May 23, 2013, at 07:27, Nico Williams <> wrote:
>>> - 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
>> This is about like saying there should only ever be 64-bit integers (or 128-bit, while we are at it).
> ECMAScript specifically only allows that.  That's where the
> restriction comes from.

JSON ≠ JavaScript.  
JavaScript's numbers are IEEE 754 double precision.
That is not at all a property of JSON.  
(It *is* something you care about if one or two of the peers speaking JSON actually are written in JavaScript and you are using JavaScript primitives to operate on the JSON.)

> Many a ECMAScript and/or JSON implementation use NaN coding, which is
> probably why this restriction is there in the first place (though
> that's just a guess; I'm sure there's a list archive somewhere with a
> lengthy discussion I could check; I don't care).

Now you lost me -- JSON doesn't have NaNs.
(Another thing that CBOR has that you can't use in a JSON subset.)

>> The serializer can choose one of multiple representations (or, if it is expedient, it can stick with one).
>> Like with different size of integers, there is little effort in a deserializer to support different sizes of floats.
> I wouldn't insist on having a canonical representation.  I would
> prefer to have a canonical representation if possible.  The biggest
> issue would be the need to sort object keys, which I'd not insist on
> (but it's nice to have the option to, and many a JSON encoder provides
> this).

I think Paul is working on c14n for CBOR.
As I said, I don't want to go there...
(If you think you need c14n, you probably have a bug in your architecture.)

>>> - might as well have a type for "octet string" -- no base64 encoding please
>> Yes, we are just not using the liturgical name "octet string" :-)
> Yes it's there and I missed it?

Yes, we call them "byte strings" (major type 2).
(They are actually the main reason I started work on CBOR.)

Grüße, Carsten