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

Carsten Bormann <cabo@tzi.org> Thu, 23 May 2013 08:11 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC78711E8155 for <apps-discuss@ietfa.amsl.com>; Thu, 23 May 2013 01:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.213
X-Spam-Level:
X-Spam-Status: No, score=-106.213 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zykFp0P8gst8 for <apps-discuss@ietfa.amsl.com>; Thu, 23 May 2013 01:11:43 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 67F7A21F9709 for <apps-discuss@ietf.org>; Thu, 23 May 2013 01:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r4N8BcWH001010; Thu, 23 May 2013 10:11:38 +0200 (CEST)
Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ACD813B58; Thu, 23 May 2013 10:11:37 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <002201ce5781$5ee92b20$1cbb8160$@packetizer.com>
Date: Thu, 23 May 2013 10:11:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <25F67EB3-B70E-4A19-AD08-7B4ADC6ECC63@tzi.org>
References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <CABP7RbcUJJoPJYdCOGSoa8fJfqj+R5RttjDtG5zXDirUV9OMQA@mail.gmail.com> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <CAMm+LwjKzHnOKDp0dmHN1Czes-f7tcJ2U1qz7S_HoSpcfKMyyA@mail.gmail.com> <002201ce5781$5ee92b20$1cbb8160$@packetizer.com>
To: "Paul E. Jones" <paulej@packetizer.com>
X-Mailer: Apple Mail (2.1503)
Cc: 'Paul Hoffman' <paul.hoffman@vpnc.org>, 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2013 08:11:49 -0000

On May 23, 2013, at 08:47, "Paul E. Jones" <paulej@packetizer.com> wrote:

> compression

CBOR is not about compression.
It is about compact encoding, achieving reasonable message sizes with reasonable effort.
In many cases, compression is premature optimization.
CBOR only avoids premature pessimization.

Compressed (e.g., via deflate/gzip) JSON works very well for a large number of applications.
CBOR is about generating and consuming data streams with much less complexity.
Complexity
-- eats CPU and thus energy,
-- creates interoperability problems and other bugs,
-- may not fit into constrained systems.
But these considerations may simply not be the overriding ones for many applications, and LZ77 can achieve efficiencies that a simple serializer can't, so absolutely go ahead and deflate JSON for these.

EXI is not a bad serializer.  
There are a number of weird design decisions in there that I would prefer to avoid.
More importantly, EXI is based on an XML data model; the JSON model is what I'm interested in.
EXI also has to be servant to two masters: schema-informed and schema-less.
Finally, it has a medium (but not severe) case of design by committee.
All this creates a bit more complexity than I like, but, again, it is not nearly as bad as it could be.

Grüße, Carsten