Re: [Json] Limitations on number size?

John Cowan <cowan@mercury.ccil.org> Wed, 10 July 2013 02:42 UTC

Return-Path: <cowan@ccil.org>
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 5552811E8199 for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 19:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.571
X-Spam-Level:
X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 lXP9baDHr+zY for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 19:42:17 -0700 (PDT)
Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by ietfa.amsl.com (Postfix) with ESMTP id ED07611E80FC for <json@ietf.org>; Tue, 9 Jul 2013 19:42:16 -0700 (PDT)
Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from <cowan@ccil.org>) id 1UwkMB-0005Pb-JQ; Tue, 09 Jul 2013 22:42:15 -0400
Date: Tue, 09 Jul 2013 22:42:15 -0400
From: John Cowan <cowan@mercury.ccil.org>
To: Tatu Saloranta <tsaloranta@gmail.com>
Message-ID: <20130710024215.GO9153@mercury.ccil.org>
References: <51DC0F95.7010407@gmail.com> <hf8ot8hnpa93pi3t54c4d5qcc3p5tnb3ca@hive.bjoern.hoehrmann.de> <CAK3OfOgTNaLpRthrRcU4Bo+3z1aXUOOn0Ord7RBPN8z6TtiiWw@mail.gmail.com> <51DC7F87.6060503@gmail.com> <CAGrxA24v5L7oCGxEOwecJSLCNiLrSWSt=jFJMA0M9E8fztNLag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAGrxA24v5L7oCGxEOwecJSLCNiLrSWSt=jFJMA0M9E8fztNLag@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <cowan@ccil.org>
Cc: Nico Williams <nico@cryptonector.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, "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: Wed, 10 Jul 2013 02:42:21 -0000

Tatu Saloranta scripsit:

> This is not to say that the way JSON (under-)defines numbers is optimal;
> but at this point forcing castrated version of numbers -- which would lead
> to practical problems like preventing use of 64-bit longs for timestamps --
> would be counter-productive and to me a non-starter.

Apparently, there are already practical problems with interchanging
64-bit longs: google for [json large numbers bugs] for lots of reports.
While there are apparently int32-only systems out there, it's clearly
understood that they are unusually restricted: such is not the case
for JavaScript-hosted implementations.

-- 
By Elbereth and Luthien the Fair, you shall     cowan@ccil.org
have neither the Ring nor me!  --Frodo          http://www.ccil.org/~cowan