Re: [Json] Limitations on number size?

Carsten Bormann <> Wed, 05 June 2013 15:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 251B621F9AAE for <>; Wed, 5 Jun 2013 08:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GJUQ6JtsNnw8 for <>; Wed, 5 Jun 2013 08:51:52 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id 1383B21F9AB1 for <>; Wed, 5 Jun 2013 08:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r55FpfkA004987; Wed, 5 Jun 2013 17:51:41 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 032443788; Wed, 5 Jun 2013 17:51:40 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 5 Jun 2013 17:51:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Paul Hoffman <>
X-Mailer: Apple Mail (2.1503)
Cc: "" <>
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: Wed, 05 Jun 2013 15:52:02 -0000

On Jun 4, 2013, at 16:07, Paul Hoffman <> wrote:

> And this is the point where one of the chairs says "please suggest specific wording changes to RFC 4627".

I like Tim's idea of a separate "best practices" document and look
forward to the process of creating it (Popcorn!).  However, some
things need to be said in the specification.  Here's my take:

Relationship between JSON and JavaScript

As the name implies, JSON was defined using the literal notation the
JavaScript language uses for its data objects; some restrictions were
made to make it more robust to potential changes in the JavaScript
language.  With that derivation made, JSON is now a specification
separate from JavaScript.

Properties of JavaScript (and changes to the JavaScript specification
[ECMAscript]) do not automatically transfer to JSON.  For example,
considerations about the source character set for JavaScript programs
do not influence what is admissible in a JSON document.  Another
example is the number format: JSON can represent numbers in arbitrary
precision by just supplying the necessary number of decimal digits.
JavaScript uses a number model derived from IEEE 754 binary double
precision numbers; the precision and range it can represent natively
therefore is a subset of the precision and range possible in JSON.

This clear separation of the two specifications does not mean that
users of JSON can always ignore JavaScript properties: A sizable part
of the JSON ecosystem is either using JavaScript implementations or
implementations that have been optimized for interaction with
JavaScript implementations.  Depending on the area of application, a
JSON-based protocol may do well to consider JavaScript's specific
properties.  Discussion of best practices for JSON-based protocols is
outside the scope of this specification.  Here, we just want to point
out that, for example, exclusively using numbers natively
representable in JavaScript is not a requirement of the JSON format.

Grüße, Carsten