IETF Logo Mail Archive

Re: [Json] Limitations on number size?

Carsten Bormann <cabo@tzi.org> Tue, 04 June 2013 06:30 UTC

Return-Path: <cabo@tzi.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 4014321F9B8A for <json@ietfa.amsl.com>; Mon, 3 Jun 2013 23:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 XaK5sMZV6MGW for <json@ietfa.amsl.com>; Mon, 3 Jun 2013 23:29:59 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 67C4821E80E8 for <json@ietf.org>; Mon, 3 Jun 2013 22:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r545PevZ012529; Tue, 4 Jun 2013 07:25:40 +0200 (CEST)
Received: from [127.0.0.1] (zoo.informatik.uni-bremen.de [134.102.218.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EC7EF3A89; Tue, 4 Jun 2013 07:25:39 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <C42654A3-E218-45A8-B368-4A60CB89619D@vpnc.org>
Date: Tue, 04 Jun 2013 07:25:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4D8E604-E4F8-408B-B7DD-97226300C212@tzi.org>
References: <CAK3OfOgPGi4PKxKAGEG=PCv-xaszMqWpUUUH2B9f0UaeMMO1gQ@mail.gmail.com> <C42654A3-E218-45A8-B368-4A60CB89619D@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1503)
Cc: "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 06:30:15 -0000

>>> JavaScript might not, but JSON actually does have indefinite length bignums. A JSON number can have any number of decimal digits.
>> 
>> Yeah, but it is constrained to IEEE 754 64-bit floating point values, no?
> 
> I don't see any limitation in RFC 4627, but it would be interesting if other folks here believe there is a limitation as Nico does.

I think this is a nice example of the distinction between JSON the representation format, a specific JSON application, and JSON the ecosystem.

JSON the format has no trouble in representing high-precision numbers (and big integers).  
So if somebody wanted to send ECDSA signature r/s values as JSON numbers, the format would be fine.

Many JSON applications have at least one end that is implemented in JavaScript.  JavaScript implementations of JSON (including the one now built into the language) typically represent JSON numbers as JavaScript numbers locally (in theory, they could implement their own high-precision numbers/bignums).  So in these applications, whatever information may have been in the JSON format is reduced to what can be represented in JavaScript's IEEE 754 double precision number format (i.e., 53 bits of precision).

Implementations in other languages may even be shaped by the expectation that they will be used in such applications, making the choice of IEEE 754 double as a number format for unencoded/decoded JSON numbers attractive.
This is particularly true for languages such as C that do not have a native way to work with bignums.

As a result, large parts of JSON the ecosystem may be biased to IEEE 754 numbers.  People designing JSON applications that need to work with a large part of the ecosystem (including the common JavaScript implementation and other implementations influenced by the capabilities of that) are better off designing to IEEE 754 double precision numbers.  
People who use JSON the format between implementations that do support bignums, however, may not care much.

So the answer is:
No, JSON the representation format doesn't have such a limitation.
JavaScript's common implementation does, and, as a result, some parts of the JSON ecosystem do as well.
Your JSON application may be well advised to live within these limitations.
Or not.
It depends on the application.

Now if I were designing a new standard for a JSON-based protocol that is going to be used in wider parts of the JSON ecosystem, I'd probably make use of the knowledge that many JSON implementations are limited to IEEE 754 doubles.  So I would choose to encode my ECDSA signatures in base64url instead of sending them as bignums.

It may be useful for RFC4627bis to document all this.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email