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

Carsten Bormann <> Wed, 22 May 2013 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46CEC21F96E8 for <>; Wed, 22 May 2013 11:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.203
X-Spam-Status: No, score=-106.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 qukNPYPgj37o for <>; Wed, 22 May 2013 11:55:42 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id 3663311E80E3 for <>; Wed, 22 May 2013 11:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r4MItdHb002627; Wed, 22 May 2013 20:55:39 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id A51F1395B; Wed, 22 May 2013 20:55:38 +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: Wed, 22 May 2013 20:55:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Dave Cridland <>
X-Mailer: Apple Mail (2.1503)
Cc: IETF Apps Discuss <>
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: Wed, 22 May 2013 18:55:47 -0000

On May 22, 2013, at 19:40, Dave Cridland <> wrote:

>  - I'm instantly put on guard by the notion that there are multiple representations for the number 7.

Indeed, the lack of the "unique encoding" property creates heartburn for at least one author of the specification.
(We have gone to considerable length in getting unique encodings in CoAP options.  Even there, we didn't quite succeed.)

One good way to ensure unique encoding for unsigned integers is the o256 encoding documented in Appendix A.4 of

This is just not the right way for CBOR.

> I would in general much prefer to see only one. I admit this may not be possible, or simple - maps, for instance, have no intrinsic ordering, enforcing an integer use the most compact representation is awkward, and so on. But having a canonical representation might well be missed later.

There is a tradeoff between the complexity of the serializer and that of the deserializer.
Complete canonicalization puts the onus on the serializer; e.g., you have to sort the keys of a map before encoding it.
On the other hand, the deserializer knows exactly what to expect when -- if you have seen "b", you know there won't be an "a".

(There is also the use of c14n for signature.  I don't want to go there...)

I think we have the right balance between serializer and deserializer here -- if you have a very constrained serializer, it may be expedient to leave out code for always choosing the shortest representation.  The deserializer already has to have the ability to handle longer representations, so the net value of this design decision is positive.

Grüße, Carsten