Re: [Json] On flat vs nested JSON encoding style

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 05 February 2016 16:27 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B01B31EA for <json@ietfa.amsl.com>; Fri, 5 Feb 2016 08:27:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToACebwD1OqI for <json@ietfa.amsl.com>; Fri, 5 Feb 2016 08:27:53 -0800 (PST)
Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CAA1B31E5 for <json@ietf.org>; Fri, 5 Feb 2016 08:27:53 -0800 (PST)
Received: by mail-lb0-x234.google.com with SMTP id cw1so52494015lbb.1 for <json@ietf.org>; Fri, 05 Feb 2016 08:27:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UTkG16+QdMYEWaP0gjOYW7wj2GmlkOFX52iTGab39mM=; b=QUqiyUflJtNMfayx/xrywfUr0+AKBiavTJ4eRKMdF6CvtoZHx6TuwyNtC2CvMEcYTt FOSt7Ts5kqKpUVpQ3gA+hER+PEp5t5V7Qw2R1LBH5S7EWkggtCDcwJeKI/0xZ5V+/ZOA 3PLHNua3Lghsy0vg27NHAB0LY6y9PPt6NeLfmpfNTjpU8fB3CsFbfbemuoU8tFF5BR6Y D9V3IAsfn8+xkulyR7W+0xqRGDjatePeA5souLcT27QdxfwPt1uy2p8btCByGveeQ9qe kXSPPsUR97Q4IGhWT/uRPIMunR39lZxJ+7tfeeu5z73gU9kGzTkTA79kHkcuvkiamGhZ 9bng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UTkG16+QdMYEWaP0gjOYW7wj2GmlkOFX52iTGab39mM=; b=bOih84kuKfhK4VVsntRKCDYF0wlFCChYnImLDweR3xNk5h8VErxfVrUnRiJmZpr2r8 jDFCJN37+huZ1x9XurUJa/+jr8kF71lhtn7h5+vwkETt0G/ACxowgfIB93P50oiqjc/S 2CNJiixBAxFPU1/muESGu6Ayu+OoNhntf90Sk3CtjaQYZQcAfHiVwkqMrwTheC1XWZJP pbbuikQeC2gWkHwfzaI9pIctSNr3UXluG4MOmjGS0PTTtXiXJCz6MU9XTZGrVqqz1W4g g8TS/bkOVwYKtIQD8uosKws5NyuZt+q3WvqQizXYelJIdfmSINEoKbevXXFTaOu4lUXH Zqvw==
X-Gm-Message-State: AG10YOTDdQnYYfo5tP8Vbb/mz/YmrkB3zMh4YPUfSp2A1M2x9QoQYpdQjT1JpuDGmzPCN/NzdNiDZl/qk25lOA==
MIME-Version: 1.0
X-Received: by 10.112.166.100 with SMTP id zf4mr6365711lbb.58.1454689671664; Fri, 05 Feb 2016 08:27:51 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.49.80 with HTTP; Fri, 5 Feb 2016 08:27:51 -0800 (PST)
In-Reply-To: <56B4BB58.4010104@gmail.com>
References: <CAMm+LwirhVcmUkdfyA3WKe_W747JTWNF1Ht2Nr8NJdDxOFCJOw@mail.gmail.com> <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <CAMm+Lwg4iqKtUjX+gw2zMu6A-fRc7_MRT14R3n670gBzMtdP9Q@mail.gmail.com> <56B43FCE.6080408@gmail.com> <CAHBU6iu9peh7YkPV4SsRmtmuEjwoQH_Kg+Wf3qtvBccT=iChRQ@mail.gmail.com> <CAMm+LwhZdAC1nnO=2qqMrgDfXtjtz37cLSac3c_EvQExWoLv4w@mail.gmail.com> <56B4BB58.4010104@gmail.com>
Date: Fri, 5 Feb 2016 11:27:51 -0500
X-Google-Sender-Auth: DFgnnMX-B-HUyGrLlLu1tDHVBKU
Message-ID: <CAMm+Lwj9Z=5S5ASqp2zRoukF0CByohLzUsNZowt=L9TNJsjcvA@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/sZHvCzsU5BkHzx8a5DlAjt-921U>
Cc: John Cowan <cowan@mercury.ccil.org>, Carsten Bormann <cabo@tzi.org>, Tim Bray <tbray@textuality.com>, JSON WG <json@ietf.org>
Subject: Re: [Json] On flat vs nested JSON encoding style
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 16:27:55 -0000

On Fri, Feb 5, 2016 at 10:10 AM, Anders Rundgren
<anders.rundgren.net@gmail.com>; wrote:
> On 2016-02-05 15:01, Phillip Hallam-Baker wrote:
> <snip>
>>
>> What you are arguing for is that you want to write your structures like
>> this
>>
>> struct fred { int a, int b, int c}
>>
>> { "a" : 1, "b" : 2, "type" : "fred", "c" : 3}
>>
>> Now you might think that is a reasonable way to present the data in a
>> spec but most of us would say that it is hard to follow. The important
>> information of the type of the structure is buried in the
>> serialization stream.
>
>
> I fully buy into the efficiency aspect of the nested encoding style (which I
> honestly had never thought of), but when it comes to "hard to follow",
> predictable
> serialization a la ES6 seems like a more universal solution since this also
> sucks:
>   {
>      "city": "Paris",
>      "name": "John Doe",
>      "country": "FR",
>      "zip": 245333
>   }
>
> ES6 serialization and the nested encoding style scheme can easily be
> combined,
> hopefully bringing out the best of both worlds!

There are probably valid use cases for a canonical serialization
format. And that is probably more viable in JSON than in XML.

However, I am very very skeptical of the benefit of canonicalization
for digital signatures. I have been in countless meetings where this
has been asserted as a requirement and I have never once heard a
plausible argument. Emit the bits then sign them.


BTW, yes I am working on a way to avoid the wrapped Base64-url encoding:

https://tools.ietf.org/html/draft-hallambaker-json-web-service-01

This is part of The Mathematical Mesh which is described at
http://prismproof.org/


I have a scheme to get rid of the Base64-url encoding in JSON as well.
But the result isn't JSON, it is JSON-B. Which is simply JSON with
some additional code points defined for sending binary data as
length-data chunks.

The reason I want this is that I use cryptography at multiple levels
in the Mesh and I want to use the JSON data model as my only encoding
regardless of the layer I am at in my protocol stack. You can't meet
requirements for meta-data protection and end-to-end security with a
single layer of crypto. A 33% increase in data volume for each crypto
pass is unacceptable.


So I have these schemes, but they are not JSON encoding. I call them
JSON-B, JSON-C and JSON-D. The simplest, JSON-B just adds binary
encoding for numbers and length delimited strings and binary data.
JSON-C adds tag compression and JSON-D adds in more floating point
formats such as you might need for scientific data.

I suggest that you write up the canonical serialization as a separate
draft and get it an assigned content-type. We could call it JSON-F
(for fixed) or something like that.