Re: [Json] Limitations on number size?

Nico Williams <> Thu, 11 July 2013 23:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E839921F9B89 for <>; Thu, 11 Jul 2013 16:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.244
X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uq2fussNZW6m for <>; Thu, 11 Jul 2013 16:20:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA37821F9AC4 for <>; Thu, 11 Jul 2013 16:20:50 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 13E61163A for <>; Thu, 11 Jul 2013 16:20:50 -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:content-transfer-encoding; s=; bh=O54kqf6Gn7ftDSrYpz7iJjJ/dbg=; b=bBgz7AfizvA Iga+YWk4hvEm8MxPPSfJ7b/thRd6f8+6GUHTUvIe6Jk8WjkDdXEanM0H641LJhfk PHrhm2JPci8adKwrou2ki+0fiXAvupuNSz1+OLTbgxonaQpsr7wa6vJsiyIVJr0t kBzK3QLMpccUrBugdUWh+yoURP4J+ywE=
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id B3B8D1621 for <>; Thu, 11 Jul 2013 16:20:49 -0700 (PDT)
Received: by with SMTP id c10so98326wiw.2 for <>; Thu, 11 Jul 2013 16:20:48 -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:content-transfer-encoding; bh=ZrjQkJX2Kjw9lpr2TtjgiDz/Eg5frkPdrVoBPshUZU0=; b=G22iGukrr9ckULVrNAtk5s5E8tkFWAWzeQXDS4imokgercMmsw6dLsbyP71oHajdi2 5Mci7HK5RrmVYuNuohiiTXGywcbjG1dpvbazQtZkOuWzwxOGTgiF+OgHNu5/iWilLoTs OwCGQ7tMf051y6DvdZArxCwsz0j7fhVeQX2v2530dg4ipvxKoPkcXvbZnRAFaajZ94E/ zvJ4+3/SKDRhxoSqrSlLdzIpSIaAgm3lEWBosx8/xc1HhexWFTdsYQEe3Wb+EQ/rNx00 WvrJpehWrFf1FxoP82YUqSGgiDQnUqGC4+LVGb7quZhqWYwsQKgUgTQlqKTGP8Jj2uwZ 7GNA==
MIME-Version: 1.0
X-Received: by with SMTP id u2mr72234wiv.36.1373584848104; Thu, 11 Jul 2013 16:20:48 -0700 (PDT)
Received: by with HTTP; Thu, 11 Jul 2013 16:20:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 11 Jul 2013 18:20:47 -0500
Message-ID: <>
From: Nico Williams <>
To: Tim Bray <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Francis Galiegue <>, Bjoern Hoehrmann <>, "Peter F. Patel-Schneider" <>, Jorge Chamorro <>, "" <>
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: Thu, 11 Jul 2013 23:20:56 -0000

On Thu, Jul 11, 2013 at 5:56 PM, Tim Bray <> wrote:
> On Thu, Jul 11, 2013 at 3:41 PM, Francis Galiegue <>
> wrote:
>> I agree, but then it is up to the protocols to define that. Say you
>> want to exchange prices over JSON, then it makes sense to require that
>> numbers be limited to two digits after the decimal point and, why not,
>> require that scientific notation not be used. (and 0.01 cannot be
>> represented reliably with a 64bit IEEE 754 floating point number, too)

Right, we could do that.  We thought we would do that for all JSON
applications, and it turns out we can't quite do it.  It'd be nice,
then, to have a reference (or three) subset(s) of JSON, to facilitate
interoperable application protocol specifications that want to use

> Well yeah, but most programmers want to use generic non-app-sensitive
> libraries to deserialize JSON into structs or objects or database records or
> whatever, and if you send a 78-digit number that will usually break.  So as
> long as you have pre-agreement and a flexible enough library, you’re
> probably good.  This is the main reason I thought I-JSON was worth defining,
> to maximize the chance that you can use a nice simple library at both ends
> and have the lowest possible chance of breakage. -T


I think we've reached a conclusion.  It's time to confirm it.  I
believe that conclusion is: RFC4627 is what it is, we can't agree
exactly on what that is, and while we can explain some/many of the
ways that it's been interpreted, we really need a
very-likely-to-interop subset (even or more than one such subsets) of
the JSON defined in that RFC.