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

Carsten Bormann <> Thu, 25 January 2024 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79AEFC14F61B; Thu, 25 Jan 2024 06:50:16 -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 5XiSafAczCkk; Thu, 25 Jan 2024 06:50:12 -0800 (PST)
Received: from ( []) (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 666ADC14F6BF; Thu, 25 Jan 2024 06:50:09 -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 4TLNz23jyCzDCk9; Thu, 25 Jan 2024 15:50:06 +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, 25 Jan 2024 15:50:06 +0100
Cc: "" <>,, Tim Bray <>
X-Mao-Original-Outgoing-Id: 727887005.9022371-a53ba52752c73082e07790ceac73ba28
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, 25 Jan 2024 14:50:16 -0000

On 2024-01-23, at 00:54, Joe Hildebrand <> wrote:
> I put together a quick requirements doc:


I reviewed this with the objective not to miss any simple things we could add to CBOR Extended Diagnostic Notation (EDN) now without creating pain.

I have the following observations (not commenting on the things already in EDN):

* EDN has a simplified comment syntax that accepts most JS-style comments, with some exceptions.  Since this is widely used in RFCs, we probably don’t want to change anything here.  We could detect * characters lining the inside of comments and react differently to embedded slashes though — this would change the meaning of some EDN that is valid today.

* parsing bare words as text string map keys can probably be added to EDN with limited pain (triggered on the trailing “:”).  The document currently uses ID_Start/ID_Continue as the repertoires, shouldn’t this be XID_Start/XID_Continue at this point?

* while trailing commas are allowed in EDN, elidable commas conflicts with the string concatenation syntax in Appendix G.4 of RFC 8610.  This is not very widely deployed, so we *could* decide to repeal it.

* Detecting range errors (outside binary64) does make sense.  Integers of course have a much larger range in CBOR, so some of this detection would only happen at the point in ingestion where the actual JSON data model is enforced.
(This reminds us that EDN doesn’t have any support for tag 4/5.)

* leading/trailing decimal points.  What is the semantics that need to be defined here?

* There are at least 4 kinds of base64 (classic/URL x padding/no); of course only base64URL without padding should be used in JSON, but this probably needs to be said.

* Rejecting duplicate/equivalent keys is probably something we want to put in.

I will make a few PRs for EDN now with the obvious parts...

Grüße, Carsten