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

Nico Williams <nico@cryptonector.com> Fri, 24 May 2013 18:05 UTC

Return-Path: <nico@cryptonector.com>
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 89B9011E80BA for <apps-discuss@ietfa.amsl.com>; Fri, 24 May 2013 11:05:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 EKgv+vTj7Q-f for <apps-discuss@ietfa.amsl.com>; Fri, 24 May 2013 11:05:49 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id AC43311E80A2 for <apps-discuss@ietf.org>; Fri, 24 May 2013 11:05:49 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id B60B31DE0C4 for <apps-discuss@ietf.org>; Fri, 24 May 2013 11:05:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CGgT+Ni8Sr4fPlJzaUv1 ofJ09CY=; b=vbDtOQcvmV4/OxBMe5QsLG3++/q0aHNxefXsC8cjpWQC0Je+sfxJ USmO7NwiRrVF07DIAzLMueVqFjnkIeaQmUk7TNGSr4TndifiY+QoMO07fN/Z06bT mSLYreYUcf7uFQFeSiEAZciePn6hlLQhmo3cE8gdNpLfT3iw/xz5QU0=
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id BCBB91DE0CD for <apps-discuss@ietf.org>; Fri, 24 May 2013 10:53:58 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id hr14so49649wib.9 for <apps-discuss@ietf.org>; Fri, 24 May 2013 10:53:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gbCJd4pU3KZIuNHX0zwVVrIB75ImkCxpMRRudbKLn/U=; b=Qd62zwZ6OUZ3B6dro907Uoy3u6GqTXc7FghqhiVOvZcTD3en9YhI+YOvZsQJgMVcFe Eaze8rvbfBWT0QMAJ292LlsmBr3XuhHNfKZ2fClaegY9dlqK9iWqio0N4OTJuj8y/peg CI4Jmf1wjvCMBYwQyNZZCGq32wfIY41VX2/ZFIcLHL/Y2Qm4TZIJ8QBNiw083Wx8A4nf OvKa2ci0UzBfN3/qr+IDR4PUDmjH1X103/z9R6o4LJ0ipRWS214uAHdMeb3lAgc9NlCe g1qCP2ulzgo7jNyzQmXcFjfn93b65WK+26XWR6rBVYWdVAyeWe/uM3B8r45/2jaq+mKe 1B5w==
MIME-Version: 1.0
X-Received: by 10.180.9.35 with SMTP id w3mr142924wia.51.1369418037121; Fri, 24 May 2013 10:53:57 -0700 (PDT)
Received: by 10.217.133.83 with HTTP; Fri, 24 May 2013 10:53:56 -0700 (PDT)
In-Reply-To: <CAMm+Lwg6GN+eE59+eo8HkBkfaH+Y-V6=DqK-eyaucFycHd4emw@mail.gmail.com>
References: <CAMm+LwiWYLBS+H6oKCfByUJVXL8bk293WuFY_M2fnBM2iuvxGA@mail.gmail.com> <A723FC6ECC552A4D8C8249D9E07425A70FC0DB40@xmb-rcd-x10.cisco.com> <CAMm+Lwg6GN+eE59+eo8HkBkfaH+Y-V6=DqK-eyaucFycHd4emw@mail.gmail.com>
Date: Fri, 24 May 2013 12:53:56 -0500
Message-ID: <CAK3OfOgV8Gr7iWVHJ396kRfdvY+6k84uKXdLM6VKKMuO0T8Sbg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.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: Fri, 24 May 2013 18:05:54 -0000

On Fri, May 24, 2013 at 12:14 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> On Fri, May 24, 2013 at 1:02 PM, Joe Hildebrand (jhildebr)
> <jhildebr@cisco.com> wrote:
>> >My experience of coding ASN.1 DER (in C and javascript) leads me to
>> >reject any counted scheme as a non starter.
>>
>> I've read the whole thread, and didn't see adequate justification for that
>> worldview.  Could you reiterate it, please?
>
>
> If you have a counter scheme it is necessary to have the whole data
> structure in memory to serialize it. Many network applications require the
> use of an intermediary with a fixed buffer length.
>
> Now ASN.1 BER definite length encoding makes matters even worse by
> specifying lengths in octets rather than the number of entries in an object
> but the same objection applies. And DER encoding is just plain insane as the
> lengths of the lengths also varies.

Yes, but note that CBOR does much better than DER: it counts elements
(of arrays, of objects), not bytes (except for strings, which are
byte-counted).

It might be nice to have an array/object of indefinite length encoding
where the end is indicated by a special type whose only purpose is to
mark the end of the array/object (CER has this).  But don't try to use
this for strings: you end up having to escape the end-of-string marker
-- ugh!

> A very frequent use case for an encoding format is to take a stream of data
> of unknown size and package it in real time. For example I would like to be
> able to take a video stream and encrypt it using JSON encryption and then
> put a digital signature at the end.

Note BTW that JSON *is* amenable to online encoding (and decoding).
Binary encodings should keep this feature.

> 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.

Anyways, +1.

Nico
--