Re: [Json] I-JSON vs. JSON-S

Bjoern Hoehrmann <> Mon, 08 July 2013 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3964D21F9A57 for <>; Mon, 8 Jul 2013 08:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c-JwMV1Op8cf for <>; Mon, 8 Jul 2013 08:25:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 14A1921F8F38 for <>; Mon, 8 Jul 2013 08:25:30 -0700 (PDT)
Received: from netb.Speedport_W_700V ([]) by (mrgmx102) with ESMTPA (Nemesis) id 0LrIPo-1UCwJe1ZYi-0137JL; Mon, 08 Jul 2013 17:25:28 +0200
From: Bjoern Hoehrmann <>
To: Carsten Bormann <>
Date: Mon, 08 Jul 2013 17:25:25 +0200
Message-ID: <>
References: <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:xu4PM8phKZx31+GSJgy7m3CdjGQGaHzmEXgzqj9vTvbT4pGybqD ezsaxZW5ZO2enyJdjInaWuTIwv9tjR6DfaXgw1hFA0y5UaFyV+DUXwquZS3muIt0xRr619n EkKf3vhKQawSPl+6iAdZ7gJrJ/wtmmlnyW1VUjqXJCEAanWZIxie+gT1r28ubqpp6uYg9Ds i+e+CPA4Nh7zbxTckQZmg==
Cc: " WG" <>
Subject: Re: [Json] I-JSON vs. JSON-S
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: Mon, 08 Jul 2013 15:25:35 -0000

* Carsten Bormann wrote:
>When people talk about "not breaking things", it is just not clear
>whether they mean "carry along all usages of JSON-S" or "make sure all
>I-JSON implementations stil interoperate flawlessly".  That's why the
>current charter may have less of a defined meaning than it appears.
>Unless the two levels of interoperability are clearly identified, it
>is not possible to break neither. proposes that the
XMLHttpRequest implementations parse JSON HTTP responses by way of


That extends and subsets what is defined in RFC 4627. If this is imple-
mented as proposed, and my parser does something else, I may eventually
have to deal with bug reports telling me "but it works with XHR". And I
might have to adapt my parser. Same for many other implementations. proposes
a `parse-json` function that takes option parameters like "RFC4627" and
"ECMA-262" to select among JSON profiles. People seeing this might ask
that my parser also has such options.

We could take RFC4627-JSON, remove unpaired surrogate escapes and dupli-
cate keys and call it RFC7xxx-JSON, but that would make ECMA-JSON and
RFC-JSON more different. RFC4627-JSON with all values at the top level
allowed would make them more similar. It would improve our understanding
of what is JSON.
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·