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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 22 May 2013 20:23 UTC

Return-Path: <paul.hoffman@vpnc.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 E342621F941F for <apps-discuss@ietfa.amsl.com>; Wed, 22 May 2013 13:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jydKODmFlcfk for <apps-discuss@ietfa.amsl.com>; Wed, 22 May 2013 13:23:40 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AD79821F8F61 for <apps-discuss@ietf.org>; Wed, 22 May 2013 13:23:39 -0700 (PDT)
Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MKNcMk062019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <apps-discuss@ietf.org>; Wed, 22 May 2013 13:23:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <6F7D44CD-E48E-4E74-9FF4-A29553124D9B@tzi.org>
Date: Wed, 22 May 2013 13:23:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FEF07121-5F3B-4A60-B657-69A10010E4FE@vpnc.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> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <CAKHUCzx35qsiz5xiw2dbOjWfRuy05Whxo6-+VpCqmBdvZCj4cA@mail.gmail.com> <6F7D44CD-E48E-4E74-9FF4-A29553124D9B@tzi.org>
To: IETF Apps Discuss <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1503)
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: Wed, 22 May 2013 20:23:41 -0000

On May 22, 2013, at 11:55 AM, Carsten Bormann <cabo@tzi.org> wrote:

> There is a tradeoff between the complexity of the serializer and that of the deserializer.
> Complete canonicalization puts the onus on the serializer; e.g., you have to sort the keys of a map before encoding it.
> On the other hand, the deserializer knows exactly what to expect when -- if you have seen "b", you know there won't be an "a".
> 
> (There is also the use of c14n for signature.  I don't want to go there...)

And here y'all get to see the two authors disagree. (Don't worry, there has been plenty of that in the past few months.) The -01 will have a section on canonicalization that will say the same thing as much of Section 3: if a protocol wants to take on canonicalization it can, but it is not required by the format spec.

--Paul Hoffman