Re: [Json] Kicking Off JSONbis

Tim Bray <> Sat, 14 November 2015 18:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 728911ACEF6 for <>; Sat, 14 Nov 2015 10:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ut0XXZmgi1uT for <>; Sat, 14 Nov 2015 10:55:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34C161ACECB for <>; Sat, 14 Nov 2015 10:55:53 -0800 (PST)
Received: by ioir85 with SMTP id r85so85802796ioi.1 for <>; Sat, 14 Nov 2015 10:55:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hvJS0FdNHFaYDRL++Q2sZi6hcJpjpRzq8S9pSOD1jpI=; b=Vs9RD7eMG99HqPoiiLDjvCVfINSY0/RB63WLdahL+1iJbvfBpWORNv8PzKoWE2MZEx URZTDOcJovKIfuqTBB//VabKau/+5MdgPcyxcUQ8HiVd6I+Ossd90E1Kz8fn/FPmgUB8 BS40QkZm8it8OaZXlDqhgxMHPFbTLv7T5kb/oPtaq6hyxY1OUIYLJrjPtzg2q2+ZC85n KDCmzjQm8Sf0oXvH0zx4R0rToTz2iPNkq5oIIjdNnofRKfWt8bMHyi0fPgFKl8mvJT/7 J0ACb5Ihid6Rt6slWdW15lB0tpu+lRUt4TXXbKHWb24qgemGKrVfVhvcWrrxEoZXkjzW 655g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hvJS0FdNHFaYDRL++Q2sZi6hcJpjpRzq8S9pSOD1jpI=; b=Hsnb5/OTjWWD4NOecjHNX5AIQ4zUsdxKyZqM2uqV553N5CMZvHZQoPFMNaT3pNxyFj ZIvseB2ZWNGDeoKOQUjd4MZUFsw/uFjltnnYxByA4E8TNLIRpfuq55XT4WbMBlPl781i uJnC/J8nQShsPS8IQpiQD+jVzrxoOjnALbSlSHGLscUR5CYfguFLLds/Kn5r5ZQ1L1xL hs2a7vV2DCb1DbDUjJaywS/HauPgtjJEFnHFoBz+A6YNz/c8Y0HqsQZqon38zO0IjzKx MNigmdgAs+E/rXUU/ars/AaI/EHmkal84hyPEsBbrEkxutZSyJm6eqbSJCZpUNLvq5aW 0mtg==
X-Gm-Message-State: ALoCoQkPNeYagEYZWbfHJn97HLgh/eup83dik0RRZwUl6jLtDKVgmZ0qjKY2bwu+Hsi77Y0NV+mj
X-Received: by with SMTP id t102mr11163685ioe.65.1447527353205; Sat, 14 Nov 2015 10:55:53 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 14 Nov 2015 10:55:33 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Tim Bray <>
Date: Sat, 14 Nov 2015 10:55:33 -0800
Message-ID: <>
To: "Joe Hildebrand (jhildebr)" <>
Content-Type: multipart/alternative; boundary=001a1142e806b0e051052484b93f
Archived-At: <>
Cc: "" <>
Subject: Re: [Json] Kicking Off JSONbis
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: Sat, 14 Nov 2015 18:55:56 -0000

On Fri, Oct 30, 2015 at 7:42 PM, Joe Hildebrand (jhildebr) <> wrote:

> ​​
> There's an argument to be made that if you want to interoperate with JSON
> implementations in browsers, you should probably read ECMA-404.  Several of
> the places where 7159 says "interoperable in
> ​​
> the sense" have specific choices in ECMA-404.

​I just re-read ECMA-404 (I recommend this, it doesn’t take long) and I
couldn't find examples of such specific choices, could you be more specific?

> ​​
> Conversely, serious implementors of ECMA-404 really ought to read 7159bis
> in order to understand some of the edge cases of interoperability a little
> better.


> The argument that we shouldn't bother with 7159 at all was discussed the
> last time through.  ECMA-404 only specifies what to do in an ECMAscript
> environment, and someone needed to specify interoperability for other
> environments, such as those that don't use UTF-16 code units or 64bit
> floats as their implementation substrate.

​Actually ECMA-404 says exactly nothing about what any software should do.​
(Maybe I missed it?)

Whether one should bother with ECMA-404 is out of our control, and overcome
> by events.  Both documents exist, and we need to ensure that they stay in
> sync going forward.  We could add a statement to section 1.2 such as:

​I'm not sure about the premise.  It's not obvious to me that any changes
are required in either 404 or 7159 for the foreseeable future.  404
explicitly says “Because it is so simple, it is not expected that the JSON
grammar will ever change.”​

"This document intends to document the exact same data model as described
> in ECMA-404, which is the main document used by ECMAscript implementors.
> Implementors that want to interoperate with ECMAscript implementations
> (such as web browsers) are advised to also read ECMA-404 to understand any
> potential interoperability challenges. Any differences in the model
> described in this document with that described in ECMA-404 are not
> intentional, and will require the IETF and ECMA to work together to resolve
> the difference."

1. ​First, ECMA-404 absolutely does not describe any data model.
2. I don't like this sort of nudge-nudge, wink-wink language. If we want to
provide this language, don't tell them to go search 404 for
“interoperability challenges”. Rather, a simple statement along these lines
would be appropriate.  “This document contains several recommendations for
best practices to avoid interoperability problems.   ECMA-404 enforces none
of these, thus implementations based on it might potentially emit JON texts
which exhibit these problems.“
3. Having re-read 404 closely, I am pretty sure that there are not in fact
any differences in the set of data objects which qualify as “JSON texts”
aside from 404's greater permissiveness already noted. So I'm dubious of
the need for any future work.

> ​​
> That makes the normative reference understandable, and makes
> ​​
> clear that the IETF and ECMA are partners in maintaining JSON going
> forward.

​No, it still falls massively short of the very explicit and clear
definition of the term “normative reference”.

I’m sticking with my suggestion that if it is absolutely necessary to
insert a normative reference, we need language acknowledging that, while
this reference does not meet the usual criteria for that sort of reference,
we are inserting one anyhow because [X].   I think Joe was starting to
suggest a value for [X], but I'm pretty sure we can do better.  I'll write
a note with some suggestions.


> --
> Joe Hildebrand
> _______________________________________________
> json mailing list

- Tim Bray (If you’d like to send me a private message, see