Re: [Json] Limitations on number size?

Douglas Crockford <douglas@crockford.com> Tue, 04 June 2013 22:02 UTC

Return-Path: <douglas@crockford.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD3E21F9691 for <json@ietfa.amsl.com>; Tue, 4 Jun 2013 15:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVuKUexSA2fg for <json@ietfa.amsl.com>; Tue, 4 Jun 2013 15:02:03 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 83EF521F9339 for <json@ietf.org>; Tue, 4 Jun 2013 15:01:37 -0700 (PDT)
Received: from [192.168.114.223] ([216.113.168.135]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lg1Ct-1U42YU3Dq7-00pfc9; Tue, 04 Jun 2013 18:01:33 -0400
Message-ID: <51AE63B1.80800@crockford.com>
Date: Tue, 04 Jun 2013 15:01:21 -0700
From: Douglas Crockford <douglas@crockford.com>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <CAK3OfOgPGi4PKxKAGEG=PCv-xaszMqWpUUUH2B9f0UaeMMO1gQ@mail.gmail.com> <C42654A3-E218-45A8-B368-4A60CB89619D@vpnc.org> <C4D8E604-E4F8-408B-B7DD-97226300C212@tzi.org> <CAK3OfOjDp=S=HZ5LTP3L+rqq1VjhSShakmBOJD9aPiN8fSULKw@mail.gmail.com> <C30B2D0D-75A7-49A5-A190-5AD5DC1FCDCC@vpnc.org> <CAK3OfOi6uNcXLCcStg90j2LqqdyVWQeoBAd0Mad-EjFEDyixpw@mail.gmail.com>
In-Reply-To: <CAK3OfOi6uNcXLCcStg90j2LqqdyVWQeoBAd0Mad-EjFEDyixpw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:joed6aywFgya2mMfPtkPkcTqo9sRvnEhHxzhmTSWtOw Iv2jMHN0vmYE3hS41k89kjcTCLGjLGAPNCErEdma2+UYsNsGSC c71DObldDS4WlV/JTf0rf37N6uVhU8eFGH9XPUVbJcE892MTjJ MjK2xwWNWfMOEr1MloVqNfTQGM0JeUhnwt6hGQKPKfsrU7IHjD xDTOmRBPSyeLQUMOl5QgATHuNl9qOwuNPNdoBIF6F4qFUm0CyK pLHjd/NS7pl+qXUGf1bAda/SQHub4L+Uu4+t0rG+FxP/CMOx9y fk+NEE2VC7bdcdZ5sEr1aThaSrFGUQQyX0lTCND6O1XLmsg34I uBUPP5CX2TyMpXZegtqY=
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Limitations on number size?
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2013 22:02:38 -0000

On 6/4/2013 11:05 AM, Nico Williams wrote:
> On Tue, Jun 4, 2013 at 9:07 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>> And this is the point where one of the chairs says "please suggest specific wording changes to RFC 4627". (FWIW, Doug just got the XML for the bis draft yesterday, and we'll probably have the -00 soon, but that should not delay people making specific suggestions for wording changes.)
> I think we need at least a note on interoperability, stating that
> ECMAScript can only handle IEEE 754 64-bit numbers, other applications
> might handle only 64-bit two's complement, others might handle bignum
> integers, and yet others might handle arbitrary size reals.
>
> Applications have to agree a priori on some schema (out of scope), and
> this is part of that.
>
> Should there be any advice to decoder implementors as to how to handle
> numbers they cannot natively represent?
>
> Nico
> --
I strongly advise against fixating too much on JavaScript. JSON is 
successful because it popularized the best of JavaScript. We should not 
burden other uses of JSON with the worst of JavaScript.

Keep in mind that this format has been working successfully in the wild 
for over a decade. The goal here should be to do the least that is 
necessary to formally upgrade its status from Informational, not to 
attempt to fix something that is already working well enough. It is only 
because it has been working well enough that we are considering the upgrade.