Re: [Json] Limitations on number size?

Nico Williams <> Tue, 09 July 2013 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B213B11E8197 for <>; Tue, 9 Jul 2013 16:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hE6SSbb+mXnd for <>; Tue, 9 Jul 2013 16:00:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B241311E8195 for <>; Tue, 9 Jul 2013 16:00:55 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 45A192AC073 for <>; Tue, 9 Jul 2013 16:00:55 -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;; bh=t2MhviirgZZt3OtFkyS3 XAJmo4A=; b=xH0/VAAnCfukeV1HJJwS/y0r2VUwq0fbcm7XxzBS4Rh+sK8Guwhe UqcQ+Kyq1lEQoYod7GcyT/UekdWk8Htw23gD8C4gtn43SWUImZZN4wh1fOULZdDy vgJ076hcChcyxPAe+ZxiUfIVXBbVagjAE3BOivfKvW5CfobB+BiX9Eo=
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id EA9722AC072 for <>; Tue, 9 Jul 2013 16:00:54 -0700 (PDT)
Received: by with SMTP id j13so5285863wgh.0 for <>; Tue, 09 Jul 2013 16:00:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BNj7QQ7w8nVF2V8tI0NJRKafiHguoV5tWNRSriAWXas=; b=Gk+eFk0tc5dY5bY2QH4Bs1npXunJTuUgZkWR5zFnODAyrGkb/ROp1645eoMp9eF1YZ OpAjxTiIxYOUdlBtukpE/zQECJedDnT8zkkQxQI8BBI9zzPHXy69kPx+UikyESxZ4iKK hSo914LjywU5+writu5WJ6voj1Po6cT9spMixdboJq4Q+s0gCuauuw0/Kh4F9cDkFU9n uVwX0S6HSD86PF1WZvpvRESu9HZGzqaDLJnw3NshFB2e+J263QRnI/vWqCmFIY+oDL5M 22ox1tW/jcpypERtxSgraOaR5B8EJQxgUmPdzsW38axgWWWa4BgANpwa9rkOczxvB44m +YLg==
MIME-Version: 1.0
X-Received: by with SMTP id fd16mr8314605wic.20.1373410853388; Tue, 09 Jul 2013 16:00:53 -0700 (PDT)
Received: by with HTTP; Tue, 9 Jul 2013 16:00:53 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 9 Jul 2013 18:00:53 -0500
Message-ID: <>
From: Nico Williams <>
To: "Peter F. Patel-Schneider" <>
Content-Type: text/plain; charset=UTF-8
Cc: Jorge Chamorro <>, Bjoern Hoehrmann <>,
Subject: Re: [Json] Limitations on number size?
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, 09 Jul 2013 23:01:00 -0000

On Tue, Jul 9, 2013 at 5:46 PM, Peter F. Patel-Schneider
<> wrote:
> But everything that I've read about JSON indicates that JSON is supposed to
> be used for (portably) interchanging data.  If all there is to JSON is the
> grammar then what's the point of JSON?

+1.  In practice agreeing on a subset of typing results in interop, at
least for implementations of specific applications.

Sometimes, when straying past that subset, there's loss of
information, and that mostly works out.  Sometimes parsers reject
inputs, this results in implementors figuring out what happened and
how to improve interop, or else the user doesn't bother reporting the

We can definitely identify a subset of JSON that is extremely likely
to interop successfully:

 - strings being Unicode character strings, possibly with paired
surrogates (there are still some implementations, no doubt, that can't
handle code points outside the BMP)

 - top-level is an array or object (though many parsers have options
to allow other top-level types, so I don't think this is too

 - no dup names (parsers might or might not reject, or deconflict)

 - numbers as 32-bit signed integers, or maybe even numbers as IEEE
754 64-bit doubles -- TBD from a survey we might never do

Note that the proposed I-JSON need not be that subset of JSON most
likely to interop, just the subset we want for Internet protocols.
And we might be happy enough with I-JSON that we never define any
other subsets of JSON.

RFC4627's underspecification, coupled with host languages with widely
varying attributes led to JSON being a superset than most
implementations of it.

ECMAScript JSON is also a subset of RFC4627, and is neither a subset
nor superset of the proposed I-JSON.

> What is (surprisingly) missing in JSON is a firm notion of the data being
> represented by the syntax.   A pale shadow of this issue for strings appears
> to have been consuming this working for quite some time.