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

Paul Hoffman <> Thu, 23 May 2013 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BAD021F8F12 for <>; Thu, 23 May 2013 13:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.607
X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u2aAr-HXzGil for <>; Thu, 23 May 2013 13:06:49 -0700 (PDT)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 65B9121F9330 for <>; Thu, 23 May 2013 12:24:33 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id r4NJOU9D005745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 12:24:31 -0700 (MST) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Thu, 23 May 2013 12:24:30 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: James M Snell <>
X-Mailer: Apple Mail (2.1503)
Cc: " 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: Thu, 23 May 2013 20:07:00 -0000

On May 23, 2013, at 11:35 AM, James M Snell <> wrote:

> That's well and good, from everything I've seen so far in this thread,
> the collective majority opinion can be summarized as "Ugh... Groan..
> Another one? Really?"  

Just a note that this is one of the only ones that people are groaning about that has an Internet Draft and might go through the IETF consensus process. Carsten and I (maybe naively) thought that doing this in this environment, instead of say posting ephemeral specs on a web page and not having it be clear where the community fit it, was a good thing.

> ... That being said, there's really nothing
> *technically* wrong with CBOR that I can spot and there are a number
> of very nice features included.

So far, the one technical change that falls within our design goals that we have heard in the past two days is the possible addition of, or changing to, streaming for arrays and maps. Like Carsten, I'm still unsure of the tradeoff of "can also do streaming" versus "having two ways of doing the same thing has lots of downsides". FWIW, I disagree about needing it for converting from JSON to CBOR, since holding a counter of items from the JSON object that is prepended to the eventual CBOR item is trivial.

> Posting the I-D is good, and having
> implementations available is good, but having a running debate of the
> technical merits of CBOR vs. Everything Else is pointless. It would be
> great to see a comparison of CBOR to other previous attempts in this
> space added to the next iteration of the draft.

Am doing so. And of course, everyone will agree with the criteria for the comparisons! :-)

> As far as the I-D being an apps area wg work item... I'm not sure I
> personally see the value in that yet. There's nothing wrong with
> handling it as an individual, independent submission for a few
> iterations and just seeing how support shapes up around it (if it
> does).

That would work too. Some ADs prefer things like this to come from WGs, some are fine with individual submission; thus our question in the first message in the thread.

--Paul Hoffman