Re: [Json] FYI ECMA, W3C, IETF coordination on JSON

Allen Wirfs-Brock <> Tue, 08 October 2013 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6184A21F9AC4 for <>; Tue, 8 Oct 2013 12:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rAK5Qq7tJysl for <>; Tue, 8 Oct 2013 12:37:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0681721F9343 for <>; Tue, 8 Oct 2013 12:37:53 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <>) id 1VTd6M-0005Yw-Vf; Tue, 08 Oct 2013 19:37:51 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19MLNaTWmfp1iWZBazJ2mQygnhqZT+KRkY=
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Allen Wirfs-Brock <>
In-Reply-To: <>
Date: Tue, 08 Oct 2013 12:37:43 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: "Peter F. Patel-Schneider" <>
X-Mailer: Apple Mail (2.1085)
Cc: JSON WG <>, Tim Bray <>, "" <>, Larry Masinter <>
Subject: Re: [Json] FYI ECMA, W3C, IETF coordination on JSON
X-Mailman-Version: 2.1.12
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: Tue, 08 Oct 2013 19:37:59 -0000

On Oct 8, 2013, at 9:37 AM, Peter F. Patel-Schneider wrote:

> What is the relationship (supposed to be) between this standard and the JSON MIME type?  As far as I can tell they cover precisely the same ground, except for interoperability warnings and admonitions.
> peter

I can't speak officially for TC39 but I can give you my personal interpretation of the discussions and consensus that lead to the release of Ecma-404.

JSON is used for many purposes.  All of those uses require at least two agreements between a producer and consumer of JSON text:

1) There must be agreement upon the syntactic structure of JSON text so it can consistently decomposed into its constituent elements. 

2) The must be agreement upon the semantic interpretation of the syntactic elements.

Ecma-404 address the first of these needs.  It specifies the JSON syntax structure for sequences of Unicode code points and nothing more.

In particular, it does not address any issues relating to the semantic interpretation of that syntactic structure.  This includes issues such as the maximum precision of a "JSON number" or even a mathematical interpretation of a JSON numbers.  Semantis also includes any meaning  associated with the "names" of JSON Object name/value pairs including issues of ordering or repetition.  Finally, there are likely to be many domain specific semantic issues  that may be loosely described as the "schema" of a particular JSON text.  The TC39 consensus was that there is no universal semantics that can be applied to all uses of JSON texts.  It is up to produces and consumers to agree upon a semantics.  Perhaps via ad hoc agreements or perhaps via other standards that address specific use cases.  TC39 currently has no plans to develop any additional standards at this semantic level.

There are other situational agreements that may be necessary in order to coordinate a producer and consumer of JSON text.

For example, Ecma-404 defines a syntax over unicode code points.  A producer and consumer may communicate in a manner that does not directly transfer such code points.  In that case, there needs to be agreement upon an transport encoding of JSON text.  Such encodings might place restrictions upon the JSON text it can deal with.  For example, it  might specify an UTF-8 encoding and refuse to encode JSON text that includes unmatched surrogates.  To me, this seems to be where the question of a JSON MIME type lives.  As far as far as I know, nobody has suggested that TC39 should issues a standard relating to this encoding level or concerning the JSON MIME type.  This seems like an appropriate subject area for the IETF.

Another area of coordination relates to the translation of JSON texts to/from language specific data structures.  Use of JSON does not require such a translation (a producer could just directly output syntactically valid JSON text and a consumer could take direct action as it parses a JSON text) but expectations and experience suggest this usage mode to be very common. Translation to/from a syntactically valid JSON text requires the specification of a mapping from the JSON syntactic elements specified in Ecma-404 to language specific data structures.  Such a translation is itself a semantics applied to the JSON syntax.  Like any semantics it may place restrictions on the JSON texts that it will accept or produce.  Ecma-262, the ECMAScript Language Specification, includes the definition of such a mapping of JSON text to ECMAScript language values.  The next edition of Ecma-262 will be updated to normatively reference Ecma-404.  It will continue to impose ECMAScript specific semantic restrictions such as the conversion of JSON number tokens to ECMAScript Number values and a specific interpretation of repeated names within a JSON object.   Ecma-262 doesn't say that this is the only way to translate a JSON text into ECMAScript language values. It simply defines the translation behavior that is provided by the standard ECMAScipt library. Other languages are likely to define there own mappings to/from JSON text.

TC39 internally agreed that the foundation for the use of JSON is the syntactic structure of JSON text and that is the purpose of Ecma-404. There was no consensus (and minimal discussion) concerning encoding or semantic issues (other than the Ecma-262 mapping) or even a consensus on the need/desirability of a single standard addressing semanitic issues.  TC39 is not currently working on additional standards that address those areas and I doubt that this will change in the near future.  If a need emerges addressing a specific use case or application domain that fits within the TC39 charter (just as an example,  using JSON to encode ECMAScript debugging information) then we might start an activity in that area.