Re: [Json] I-JSON Tpic #2: Top-Level

Jacob Davies <> Wed, 21 May 2014 22:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2184E1A04D2 for <>; Wed, 21 May 2014 15:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w7Myihw8x4sa for <>; Wed, 21 May 2014 15:47:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F33291A0407 for <>; Wed, 21 May 2014 15:47:24 -0700 (PDT)
Received: by with SMTP id hi2so8386530wib.17 for <>; Wed, 21 May 2014 15:47:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cz0iQaf1/3JHvWXJ/8mqx/oiRT803jntvBrakYDMPfU=; b=pOuHYqsUTZOHZ768qH47Un9eiW7Sq/wbgUHJYZIQZXRD2Gu1CRDthRGHMSO9Lzr81/ StHWTEV7XXAPTLKEyqmbyVitHWqdphogCP7LhQSAmA5mPqpfWQvrzm41EPNpELnO+baI bdl4mUT2Ska8MSSrBsZasqf2DljAz11D9NRc++lt0RtO8CWD2dc5UakYuhQ9wfT4h7X5 JOgLEuYRXSYN+yNGP5n5F4C82HxHyZRA0zLWO/srIhcACfEBdjASCbGMJms+EUfNje9T Z+wp83sw9LLJprqCma1Y7rTATeUQJ7dclq0a45s0XNKGSOlDnfR0hS5H3R97KfSinTv9 gSgA==
X-Received: by with SMTP id o15mr19787778wjq.62.1400712442947; Wed, 21 May 2014 15:47:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 21 May 2014 15:47:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Jacob Davies <>
Date: Wed, 21 May 2014 15:47:02 -0700
X-Google-Sender-Auth: MZjUsnjW3gRJsObAp9Ykgw7oxHw
Message-ID: <>
To: "Joe Hildebrand (jhildebr)" <>
Content-Type: text/plain; charset="UTF-8"
Cc: Nico Williams <>, Paul Hoffman <>, IETF JSON WG <>
Subject: Re: [Json] I-JSON Tpic #2: Top-Level
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 May 2014 22:47:26 -0000

On Wed, May 21, 2014 at 11:44 AM, Joe Hildebrand (jhildebr)
<> wrote:
>>issue in starker terms: interop with RFC4627 implementations with no
>>option to parse all types at the top-level.
> That's what I want.

I have to ask again: why?

The other issues mentioned in I-JSON are subtle interoperability
problems that could trip people up unless they take care to use a
compliant parser/encoder. In fact, they certainly will trip people up
if they do not carefully choose a good library, which means not
picking any old RFC4267 library, because there are lots of extant
libraries that allow the precise constructs that I-JSON mentions.

For instance, there are multiple JSON libraries - including the Java library - that encode Java longs as JSON numbers, which is
exactly the kind of problem I-JSON is concerned with, since Javascript
cannot correctly deserialize these values, a problem that has led to
numerous prominent bugs whose fix (replacing numbers with strings) was
not backwards-compatible. The point about subtle problems is that they
can go unnoticed for a long time and the cost of fixing them is large.

These kinds of problems are what I-JSON intends to address, but to use
I-JSON effectively means either:

1. Using an pre-existing JSON library that is already pretty-well
compatible with the I-JSON requirements (for instance, Javascript's
JSON.parse()). This does NOT include many - perhaps even most -
existing JSON libraries. In my experience with the Java libraries,
most of them fail on at least one of number range, duplicate keys, and
non-characters. Yet almost all of them handle top-level values of any
type just fine (I believe the code does not).

or 2. Writing new libraries that are fully compliant with I-JSON, in
which case the point about existing libraries is irrelevant.

I have never heard of any interoperability problems caused by
top-level values of non-object types and I find it hard to imagine it
would be a real concern, since agreement on the types to be sent and
received is hard to avoid upfront and grossly obvious when it occurs.
In the cases where a top-level primitive or array is desirable, it
will be pretty clear why that is the case (most importantly, selecting
part of a composite object).

This restriction was widely ignored since it never existed in
Javascript in the first place; eval() and JSON.parse() have always
accepted all Javascript literal values anyway. Most people just did
what JS did and accepted them too. That there exist some libraries
that enforce it is not actually evidence that it matters to I-JSON,
since most of those libraries probably fail the other I-JSON tests and
will need rewriting to comply with its requirements.

The restriction to objects and arrays at the top level was a clever
hack to avoid using any out-of-band information to distinguish between
UTF variants at a time when UTF-8 had not taken over the world. It was
obsolete a long time ago. Replicating it in recommended guidance for
using JSON in modern applications just seems very odd to me (and the
original rationale for distinguishing UTF variant doesn't even exist
in I-JSON since UTF-8 is required).