Re: [Json] Limitations on number size?

Tatu Saloranta <tsaloranta@gmail.com> Wed, 10 July 2013 18:47 UTC

Return-Path: <tsaloranta@gmail.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 1327D21F9E6B for <json@ietfa.amsl.com>; Wed, 10 Jul 2013 11:47:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 E9mjd-7vUpEw for <json@ietfa.amsl.com>; Wed, 10 Jul 2013 11:47:52 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD721F9CE6 for <json@ietf.org>; Wed, 10 Jul 2013 11:47:51 -0700 (PDT)
Received: by mail-wi0-f172.google.com with SMTP id c10so11757758wiw.11 for <json@ietf.org>; Wed, 10 Jul 2013 11:47:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eFBRP3ZRuxbHD2YI6kgnOTSPEssJe+S+IxQTOj6qzzw=; b=PKKTrgJa/eRn6VO18XyKoeQw+KsXwNmEXnjZiZSWejBvf26lJnBfGew/X6E+RLsYkA 9PzTgjQUrBqAySRQ5tq7WebhWkLFAvdqgRuXEykC14+7oG43SkCz28hshk8cUPZFsKN1 +r3Y+g+rltcflgNkyaW3Mf51F8NPOf62SLcAVnqweYFE/umFQgOFv6d3WLfskc8O50P1 9z2yDMIZHAWVVUR3gEGz89Cjcz7NKK1BfsoyQyavK5A0RHpcYVhNXR84VAqdbqVHOrID 2fUlFP0HM6eTLWccaNVd7YzcZRlc16CRg4n+81j5Ww2CInlqXjOp/8zArAKlBvxZjQRV 7KoA==
MIME-Version: 1.0
X-Received: by 10.194.90.244 with SMTP id bz20mr19450010wjb.69.1373482070930; Wed, 10 Jul 2013 11:47:50 -0700 (PDT)
Received: by 10.227.34.199 with HTTP; Wed, 10 Jul 2013 11:47:50 -0700 (PDT)
In-Reply-To: <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> <20130710024215.GO9153@mercury.ccil.org>
Date: Wed, 10 Jul 2013 11:47:50 -0700
Message-ID: <CAGrxA24qfKanyOvOgEv3gqcGq9iDFPZwUfs1p=C=4nXtdT+d4A@mail.gmail.com>
From: Tatu Saloranta <tsaloranta@gmail.com>
To: John Cowan <cowan@mercury.ccil.org>
Content-Type: multipart/alternative; boundary=047d7bfd090af17c2304e12cb6d2
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 18:47:56 -0000

On Tue, Jul 9, 2013 at 7:42 PM, John Cowan <cowan@mercury.ccil.org> wrote:

> 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.


I am not saying there can't be problems there (and I have gotten feature
requests for optional processing limitations to conform to Javascript
representation); but rather that these are also successfully and widely
used. So it is fine to define or recommend safe(r) profiles that take
commonly encountered limitations into account.
But just to take care not to consider this strict limitation on all usage.

-+ Tatu +-