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

Phillip Hallam-Baker <> Fri, 24 May 2013 18:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCA3C21F9673 for <>; Fri, 24 May 2013 11:08:26 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uatxNVnL4wlp for <>; Fri, 24 May 2013 11:08:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::229]) by (Postfix) with ESMTP id 5047721F93C4 for <>; Fri, 24 May 2013 11:08:25 -0700 (PDT)
Received: by with SMTP id ee20so4782957lab.14 for <>; Fri, 24 May 2013 11:08:24 -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=Ga+o3Y1iKjf82YqKrgCxWkMrjBkC//TBk6i5R21eudI=; b=IQXiAQeGDcwyfUR98OgCtz9CpuhHBe7vfAOvLvvs7aJK7oFQhlVrmto27k3TaW28FB dI6IP7lQB9LyJqDlrp6uLQfc2DSfqkE47n8vvtESrSvVIhUkerBJa28zYDkIP4RQaKDP Lj/4xDJ4qlwvrlYdeyg482IlVTKH/20Py1g7mFqaxxrYDHerc3XyB1gRRLf8AOlktjE8 uwj2WA6/ar4XhhaGRz0hLcCVMsI6MbGpumGxf7XX+KOaJ7cfn9uwbX0fA7m2MGBuuORM F6XnmvxM2PPpRXEJAEcV4h67yh5lgOvOApGKC/4Mk9rR8csJIwAM32D/gFry/oHGvruv SP6w==
MIME-Version: 1.0
X-Received: by with SMTP id s8mr6662537lae.6.1369418904096; Fri, 24 May 2013 11:08:24 -0700 (PDT)
Received: by with HTTP; Fri, 24 May 2013 11:08:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 24 May 2013 14:08:23 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary="089e0141a4a453d7f204dd7aafa9"
Cc: " Discuss" <>, 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: Fri, 24 May 2013 18:08:26 -0000

On Fri, May 24, 2013 at 1:53 PM, Nico Williams <>wrote:

> > BSON does not do that quite like I would like but I can fake the same
> effect
> > by using an array of Binary rather than one Binary chunk and the same for
> > strings.
> I think that's as well as you can expect to do without having to
> resort to escaping binary/string characters.

The alternative would be to declare new data types for chunked strings and
chunked binary which would be closed by an end marker.

The advantage to that approach is that it can be used by a transcoder that
has a fixed buffer size converting from JSON to the binary encoding.

It would be fairly easy to add to BSON as they have plenty of unused code
points. The existing scheme is not very satisfactory as they represent
lengths as fixed 32 bit integers!! Kind of disappointing when a single
video file can easily be over 4Gb. Or at least would be if most equipment
didn't have to dance around brain dead file systems with the same

Sure counts of items are better than ASN.1's counts of bytes. But I can't
see any utility in the counts of objects either. If you are trying to
navigate to a particular point in the structure you are going to have to
parse the whole stream regardless. The only way you could skip over a whole
object to go onto the next would be with something like the ASN.1 definite
length scheme.