Re: [Json] Limitations on number size?

Tatu Saloranta <tsaloranta@gmail.com> Tue, 09 July 2013 20:13 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 D554A21F9E28 for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 13:13:49 -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=[AWL=0.000, 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 eJAlnheguyvJ for <json@ietfa.amsl.com>; Tue, 9 Jul 2013 13:13:49 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D721F9DF8 for <json@ietf.org>; Tue, 9 Jul 2013 13:13:48 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id ey16so10626578wid.9 for <json@ietf.org>; Tue, 09 Jul 2013 13:13:48 -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=j/GASpFq5LYTtq/zFXmKUSsNSMcvPEInXhC2lQQjCDU=; b=HF1MVjwprT7f051Tf9jxSwuPzWJSPYLoUjpuIudp94Yif3ATbVN92ftadqtaK0WrTn ffwwFFgg6gaGZGJm5H6nx5LoREMtKYLlJ396K+fFHff5iTs2awRuessQfi9Epjk8t53q KsMdRKrzLPS40wXgG8pT4eghkqdVB1mQK9E20hJ4OYVT06WsbKChh3sW3tZBBFxKUHnN X+9h6PeJZycRY8QGm4w5t64VTHA9dKD5wWmFET6qSk6SvZ4II1D4yQ3XqT9TTYw7jTZO VKxMaji6h94ooGlMsp3Z7lYBwPTrF6jBe0keHdZX7IBi2u/80oByI+lIR+dRayZZ8/bB FLvA==
MIME-Version: 1.0
X-Received: by 10.194.90.244 with SMTP id bz20mr16570616wjb.69.1373400827963; Tue, 09 Jul 2013 13:13:47 -0700 (PDT)
Received: by 10.227.34.199 with HTTP; Tue, 9 Jul 2013 13:13:47 -0700 (PDT)
In-Reply-To: <CAK3OfOi_q8KTQd-RW7PPhS5ZXXYSMEJ57uKTKL-ck6ocd6Nbeg@mail.gmail.com>
References: <51DC0F95.7010407@gmail.com> <F142B117-37C4-4936-AE81-D3571AB118C8@tzi.org> <CAHBU6isckD0JCNT66BiS7sWXV3qyUXfseJ1kJk0bSL62QNFkQw@mail.gmail.com> <CAK3OfOi_q8KTQd-RW7PPhS5ZXXYSMEJ57uKTKL-ck6ocd6Nbeg@mail.gmail.com>
Date: Tue, 9 Jul 2013 13:13:47 -0700
Message-ID: <CAGrxA24RoFnkB=BJLdvoZ+u=DrS-a6A4P3kDDMqHX6j4PDYUpg@mail.gmail.com>
From: Tatu Saloranta <tsaloranta@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=047d7bfd090a7c323104e119cc22
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Carsten Bormann <cabo@tzi.org>, Tim Bray <tbray@textuality.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: Tue, 09 Jul 2013 20:13:50 -0000

On Tue, Jul 9, 2013 at 8:38 AM, Nico Williams <nico@cryptonector.com> wrote:

> On Tue, Jul 9, 2013 at 10:27 AM, Tim Bray <tbray@textuality.com> wrote:
> > Yeah, we can’t retroactively change the 4627 production for number, nor,
> in
> > the -bis, say very much useful aside from a caution that implementations
> are
> > all over the map.  When we move on to the BCP or Internet JSON or
> whatever,
> > I think the single most interesting discussion will be how to constrain
> > numeric values for maximum interoperability.
>
> I would like to do two things here though:
>
> 1) give advice as to what numeric ranges and precisions are generally
> supported (e.g., 32-bit signed integers);
>
> 2) what a parser SHOULD do when it parsers a number that it cannot
> represent.
>

This would be useful. One challenge is that of precision for floating-point
types: figuring out whether loss occurs is rather costly. For integer types
this is easier.

-+ Tatu +-