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

Carsten Bormann <> Thu, 18 January 2024 13:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBED3C14F6E8; Thu, 18 Jan 2024 05:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 a9eC8r9muRZt; Thu, 18 Jan 2024 05:56:46 -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 B15A4C14F695; Thu, 18 Jan 2024 05:56:43 -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 4TG46c5FmKzDChL; Thu, 18 Jan 2024 14:56:40 +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: Thu, 18 Jan 2024 14:56:40 +0100
Cc: "" <>,
X-Mao-Original-Outgoing-Id: 727279000.112599-ea7fbb450929eff11e6aa65b754e813a
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: Thu, 18 Jan 2024 13:56:50 -0000

Hi Joe,

thanks for the list!
I’m CCing cbor@, as we are just finishing the extended diagnostic notation (EDN) document, and it is worth considering these points.

> We would need to rework that grammar to make it suitable for interchange:

[context: as a JSON extension]

> - Remove encoding indicators as mentioned

Right.  When you say “remove”, you mean “do not include in JSON subset”?
(ABNF doesn’t have the “.feature” feature of CDDL…)

> - Reference IEEE754 for the 0x1.2p3 format, or remove it

Good point.  Section 5.12.3 of IEEE Std 754-2019?

> - Remove embedded notation

(I.e., not in JSON subset.)

> - Remove ellipsis processing

(I.e., not in JSON subset.)

> - Discuss whether results should always be an array, as sequence is currently top-level

Good question.  I gather the pickup of JSON sequences (RFC 7464) is not that great?  EDN is not entirely compatible with that as we don’t do the RS character, but do an explicit comma.
The JSON subset could simply use “item” as the entry point.

> - Discuss adding other JSON5 features

Do you have some examples for what you would like to add?
What are we missing out for EDN?

> We wouldn't get Tim's desired property of one character look-ahead.

On constrained systems, you could always use CBOR…

> Other than that, it's as good a place to start as anywhere else.

I could imagine we finish the EDN-literal document for its CBOR target audience, and then write another document about the JSON subset (which would be less of a delta and more of a free-standing specification that is just anchored in the full version for CBOR).

I just noticed that we do have a required comma between items in arrays and sequences.  I just confused this with CDDL (which I’m prone to do), where that comma is not required.  Leaving off the comma conflicts with implicit string concatenation (which is one way to address the 2D string problem).  So maybe there is a bit more work to do...

Grüße, Carsten