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

Nico Williams <> Thu, 01 May 2014 00:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ECBAA1A0981 for <>; Wed, 30 Apr 2014 17:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OsXBlQUx-KiT for <>; Wed, 30 Apr 2014 17:40:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CBC5A1A096A for <>; Wed, 30 Apr 2014 17:40:10 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 4623F10060 for <>; Wed, 30 Apr 2014 17:40:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s=; bh=eufqkg68olKJVt/HaxuQIyzvK7g=; b=P7Tw0kS0crn +b1gNmnN2O0pZ1etQecg75fSx9yLdDSNGt5/cJM/7b1dDPPBfxS8uNdSFsq0JYgh PK27z1cl9iu4U6AnaJasG21Zk2iWj73ZgyQl5XhL8HBaUntyUDIXovmkTKgXnKjD PQmsZXzlkN/dsBOsxjOUXfsmZLypBSPk=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id EC46110059 for <>; Wed, 30 Apr 2014 17:40:08 -0700 (PDT)
Received: by with SMTP id f8so3808448wiw.9 for <>; Wed, 30 Apr 2014 17:40:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id xl6mr6059120wib.42.1398904807693; Wed, 30 Apr 2014 17:40:07 -0700 (PDT)
Received: by with HTTP; Wed, 30 Apr 2014 17:40:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 30 Apr 2014 19:40:07 -0500
Message-ID: <>
From: Nico Williams <>
To: Paul Hoffman <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Tim Bray <>, 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: Thu, 01 May 2014 00:40:12 -0000

On Wed, Apr 30, 2014 at 6:42 PM, Paul Hoffman <> wrote:
> On Apr 29, 2014, at 8:40 PM, Tim Bray <> wrote:
>> I’m sorry, but the central idea of I-JSON is to explicitly rule out all the interoperability problems identified in RFC7159: How to produce maximally-interoperable JSON.
> This is a good point, and one that I forgot when I said "this isn't needed". There are probably some parsers out there that expect the original JSON restriction; given that, repeating the restriction here seems fine.

Conceding that for the time being, the restriction to repeat was that
JSON texts must be objects or arrays at the top-level, NOT just

Now, as to whether we should repeat that restriction, given that every
parser I know of at least has an option to permit non-object/array
types at the top-level, I find the interop argument wanting.  If I
know some application uses I-JSON, and if I know I-JSON permits any
type at the top-level (supposing it were to), why would I have any
trouble implementing that with existing parsers?

I haven't carried out an exhausting analysis of existing parsers, and
since I can't -no one can-, I might concede that point even if no one
confirms the existence of any JSON parsers that don't have an option
to permit any type at the top-level.  For now I'm just not buying the
interop argument.