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

Nico Williams <> Wed, 30 April 2014 19:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D6A361A887E for <>; Wed, 30 Apr 2014 12:03: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 rVG64C26cblW for <>; Wed, 30 Apr 2014 12:03:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 843C71A8867 for <>; Wed, 30 Apr 2014 12:03:10 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 1FA8A778071 for <>; Wed, 30 Apr 2014 12:03: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=m73c4HazvHp90V117bH/7GvwJnw=; b=GJ4MCrH/pyr e+rkuSp96Nr32GTHvgiOJfGI7VciOTm7KiHxee3jB12N8HxrkvPwRammcFOPG5P+ usbKgTQGXLwwDtY7EHiTlH4I7cHne7tD+FdwLbY8gn6MkudYGnuOpqsSnf6B1cKR hmJoKhfgqPScBCJlIK9zGSETgB3Kksig=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id C7330778057 for <>; Wed, 30 Apr 2014 12:03:08 -0700 (PDT)
Received: by with SMTP id w61so2104965wes.4 for <>; Wed, 30 Apr 2014 12:03:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id z16mr3385568wjr.67.1398884587320; Wed, 30 Apr 2014 12:03:07 -0700 (PDT)
Received: by with HTTP; Wed, 30 Apr 2014 12:03:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 30 Apr 2014 14:03:07 -0500
Message-ID: <>
From: Nico Williams <>
To: Tim Bray <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "Manger, James" <>, 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, 30 Apr 2014 19:03:12 -0000

On Tue, Apr 29, 2014 at 10: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.  7159 specifically says that for
> interoperability a JSON Text should be an object or array, and the idea of
> making I-JSON less constraining totally defeats its purpose.  This is just
> not a reasonable direction to be going.

Applications that use JSON -or any other encoding system for
structured data- need to agree on schema to begin with.

Yes, it's true that a human can eyeball a JSON text, or a dump of
ASN.1 BER/DER/CER encoded data, or..., and get a pretty good idea of
the meaning of various artifacts.  But by and large it's applications
that consume these things, not humans.  And applications, not being
humans, need to agree on schemata.

Usually schema signalling is done out of band, and you have dropped
your earlier proposal to do I-JSON signalling in-band.  Why do we need
to do anything else at all regarding this?  (That's not rhetorical.  I
want to understand just why we should do what you propose.)

Extensibility of schemata is a separable issue; we should separate it.
 I agree that uses of JSON should generally have a default implied
extensibility rule, a-la modern ASN.1 -- i.e., ignore unknown names in
objects -- all objects most likely.  But that has nothing to do with
the top-level being an object, which is why it's separable.