Re: [Json] JSON and int64s - any change in current best practice since I-JSON

Carsten Bormann <> Wed, 17 January 2024 17:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99F94C18DB84 for <>; Wed, 17 Jan 2024 09:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7DWDoDSo_TS6 for <>; Wed, 17 Jan 2024 09:22:34 -0800 (PST)
Received: from ( [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 7FFC4C17C884 for <>; Wed, 17 Jan 2024 09:22:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4TFXkc5Rt3zDCdY; Wed, 17 Jan 2024 18:22:32 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Wed, 17 Jan 2024 18:22:32 +0100
Cc: Tim Bray <>, Pete Cordell <>, "" <>
X-Mao-Original-Outgoing-Id: 727204952.2726851-defec09d03fdb6918f90bafea8e80827
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Joe Hildebrand <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Json] JSON and int64s - any change in current best practice since I-JSON
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jan 2024 17:22:37 -0000

On 2024-01-17, at 18:06, Joe Hildebrand <> wrote:
> It may be an implementation detail which type gets generated from parsing. 

Once there is an application that gives different semantics to 1n in a specific place than to 1, it is no longer an implementation detail at all.

There is a large swath of JSON implementations that bin JSON numbers without dots or exponents into an integer bin and those with at least one of them into a floating point bin.  I’ll call this “syntactic boundary”.

10 and 10.0/1e1/0.1e2 are different with these implementations.

JavaScript gives all these numbers the exact same meaning; it doesn’t have a boundary at all (until you start using | and similar, which then mogrifies into 32-bit integers, IIRC).

(JSON doesn’t give any meaning to numbers, but it seems to imply that they are somehow standing for the mathematical concept of a number without mentioning the computer concept of separate integer and floating point types.
So one might think that JSON favors the JavaScript interpretation.
But then Section 7 of RFC 8259 says:

   The representation of numbers is similar to that used in most
   programming languages.

… where most programming languages have a rather thick firewall between integers and floating point numbers.)

>  The questions for interop are:
> - are long integers without prefixes allowed or cause a parse error?

JSON certainly allows them, so if ESON wants to be a superset, they need to be allowed.

> - if they are allowed, are they expected to have (somewhat unspecified) JSON behavior, or are they expected to behave in int-like fashion?

There is no JSON behavior.  They are numbers, "similar to that used in most programming languages”.

There is the common practice of binning non-dot, non-exponent numbers into the int-like bin (syntactic boundary).  There also is the JavaScript behavior.  One could imaging a semantic boundary, where 10/1e1/0.1e2/10.0 are integers because they are integral numbers, and only non-integral numbers are floating point — see the dCBOR discussion over at the CBOR mailing list for one such model of applications.

> - are long numbers with decimals or exponents allowed, or cause a parse error?

They are allowed in JSON.

> - same as ints, what is their expected behavior?

Depends on where ESON puts the integer/float boundary — on syntactic grounds (like many non-JavaScript implementations).
This gets interesting again with 1e1000 (a common way to say “Infinity” in JSON, which doesn’t have Infinity).

> Part of this depends on how much you want to be backward-compatible with JSON.

Indeed.  I think trying to be backwards compatible with all (syntactically) JSON documents creates an interesting decision space.  Or maybe JSON/ECMA404 (syntax) is less important than semantic compatibility.

Grüße, Carsten