[apps-discuss] CBOR and BULK (was Re: Gen-ART review of draft-bormann-cbor-04)

"Pierre Thierry" <pierre@nothos.net> Fri, 09 August 2013 23:09 UTC

Return-Path: <pierre@nothos.net>
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 057EE21F9E22 for <apps-discuss@ietfa.amsl.com>; Fri, 9 Aug 2013 16:09:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 aBGvYTNh4jDD for <apps-discuss@ietfa.amsl.com>; Fri, 9 Aug 2013 16:09:40 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8118F11E810D for <apps-discuss@ietf.org>; Fri, 9 Aug 2013 16:03:25 -0700 (PDT)
Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id D5DA6172089 for <apps-discuss@ietf.org>; Sat, 10 Aug 2013 01:03:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net
Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id rNPDgxjonauc for <apps-discuss@ietf.org>; Sat, 10 Aug 2013 01:03:11 +0200 (CEST)
X-Originating-IP: 80.112.184.89
Received: from nothos.net (5070B859.static.ziggozakelijk.nl [80.112.184.89]) (Authenticated sender: pierre@nothos.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E835B172055 for <apps-discuss@ietf.org>; Sat, 10 Aug 2013 01:03:09 +0200 (CEST)
Received: by nothos.net (sSMTP sendmail emulation); Sat, 10 Aug 2013 01:03:07 +0200
From: Pierre Thierry <pierre@nothos.net>
Date: Sat, 10 Aug 2013 01:03:06 +0200
To: apps-discuss@ietf.org
Message-ID: <20130809230304.GC1895@amoureux.home>
References: <CABkgnnXtCBHnOpY_=t7yWD-+7rSFHKdUi0VGUSVJqXq+xV-G2g@mail.gmail.com> <D16097AF-5DFB-4F6A-A6E7-2582C1CF25CD@tzi.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="+OVWeTxrbAwQuiek"
Content-Disposition: inline
In-Reply-To: <D16097AF-5DFB-4F6A-A6E7-2582C1CF25CD@tzi.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [apps-discuss] CBOR and BULK (was Re: Gen-ART review of draft-bormann-cbor-04)
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: Fri, 09 Aug 2013 23:09:47 -0000

On Thu, Aug 08, 2013 at 09:58:17PM +0200, Carsten Bormann wrote:
> [CBOR] was written to some specific objectives, clearly stated in
> the document.

Hi all,

I just subscribed to this list and just learned the existence of
CBOR. A few days ago, I just submitted a few independant I-D
specifications also for a binary object representation.

It's very interesting because many of our objectives are the same. The
main differences, as I see them, are that I didn't base my data model
on JSON's and that I didn't specifically cared about constrained
environments. I was more aiming at implementation simplicity in
general and it paid off as a side-effect: I think my current design
can be parsed on a class 0 node.

Also, the balance between the requirement on future extensibility and
size of wire data is different, my design being a bit more verbose
than CBOR.

I also envisioned a jump table parser like CBOR's, but in my case, I
always use a whole byte as marker, where CBOR use 3 bits.

> As Paul and I have repeatedly said, CBOR is not trying to be the
> final, definitive, binary object representation for all purposes.

I would expect it to be an established fact that no single binary
format can accomplish both simplicity of parsing, generality,
extensibility and optimal size of wire data and processing speed. I
don't see how a general and extensible format could do as well as
formats like Ethernet, TCP/IP, Ogg or DivX.

But for the rest, from documents, images, or executables to RPC
messages, I suspect the jury should still be out. One format to rule
them all might be possible. Maybe I suffer from a bit too much
enthusiasm, but I hope BULK might be able to do just that (at least
I'm sure it could be the basis of something that does).

I'm implementing a simple BULK reader/writer and I plan to implement a
few utilities before March (a file compressor/encrypter, BULK/XML and
BULK/JSON translators, an archive creator), as I was hoping to attend
the IETF meeting in London.

Here are the I-Ds:

https://datatracker.ietf.org/doc/search/?name=thierry-bulk&activedrafts=on&sort=

I would be glad to hear feedback on BULK from CBOR's authors.

Regards,
Pierre Thierry
-- 
pierre@nothos.net
OpenPGP OxD9D50D8A