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

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Feb 5, 2016 at 10:10 AM, Anders Rundgren
<[e-mail]> 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.