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

Joe Hildebrand <> Wed, 17 January 2024 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F250EC14F6F1 for <>; Wed, 17 Jan 2024 10:49:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Os5HQZhYIBJY for <>; Wed, 17 Jan 2024 10:49:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 166C0C14F6F4 for <>; Wed, 17 Jan 2024 10:49:03 -0800 (PST)
Received: by with SMTP id 00721157ae682-5e89ba9810aso94383117b3.2 for <>; Wed, 17 Jan 2024 10:49:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1705517343; x=1706122143;; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4hGjTKrkPT6Efc+Mf0kRRLj/B+jDp1Zm99/61YWo8zM=; b=b39/Af2leWPrt6meoHonyNfwbo+gTU2gYYnXBxOYvsg5tQuS/yoXy34CIDIzCOeMvu zfB1L/2S/Pj/QDqglPfijjjqbm/2l98wHc0KL1XfLNQOFsbwp/QQDnctI42Kp0tWQW25 KEBM2gB8hi5LROg3Q0hUlyJYwVwJm0kC9eC+s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1705517343; x=1706122143; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4hGjTKrkPT6Efc+Mf0kRRLj/B+jDp1Zm99/61YWo8zM=; b=O+W4rEDSzMiLUZ2kSXkbF9siq2fiEly9VG+ATl/qGe3leRfEVjPRlJeiUu1qvvxI6b fRKVAmxBKifdcpFXxAcq6MdDx4+pXWwY+VeRijYdsL+c0ay6qZzlU4W3laBeoB2+b4Q3 RTLOeK/KiBCfdOxApKayyLOtk6aeVFbLNwq2GRowf0ZJ7Xi/xDNqMRa0Eg39yYFg8RLI 7SrGckdM+NTRllAk2dYMyRuNdFrxdNFJTfb5xXvqIUGaTkUREZtfyAdKoBFlwejsaK4j Iss2NC0l+fEMnEdcp9P852HX4VuCR1q55LppJpDgPuQldv8bZ+ePyplwIafqBs8Yxnj9 PM5w==
X-Gm-Message-State: AOJu0Yy3g1l3Ho/oMeJLrzvJudgG1NzpxHhtl1aqWVzlm9E6tbJe6Bt5 n5iSLcg9U8GrI91mlOhnOo2uijatXvjXAA5DYuyPyKmw+w==
X-Google-Smtp-Source: AGHT+IF2L6lhU/OrkHJN99InlF86dlx23YPLDvld/d3Omzqr0KwVBKhuBrDykQ7GzMARyz73o8l/oA==
X-Received: by 2002:a05:690c:f83:b0:5ff:3c5e:9902 with SMTP id df3-20020a05690c0f8300b005ff3c5e9902mr4496646ywb.8.1705517342972; Wed, 17 Jan 2024 10:49:02 -0800 (PST)
Received: from ( []) by with ESMTPSA id w131-20020a814989000000b005ff826f142fsm61724ywa.92.2024. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2024 10:49:02 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
From: Joe Hildebrand <>
In-Reply-To: <>
Date: Wed, 17 Jan 2024 13:48:50 -0500
Cc: Rob Sayre <>, Pete Cordell <>, "" <>, Carsten Bormann <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Tim Bray <>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
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 18:49:08 -0000

> On Jan 17, 2024, at 1:32 PM, Tim Bray <> wrote:
> If there were going to be an ESON effort, the hills I’d die on are:
>     • Lose the commas

Heh.  I was going to say "trailing commas" which is the exact opposite.  I'd have to do a little prototyping before I agreed with you that we don't need commas at all, but I suspect it would work.  This would also lose us backward-compatibility with JSON, unless the commas are optional instead of forbidden.

If we're not careful, we will just be recreating YAML -- that's another approach we could take, I suppose, but YAML has enough flexibility in its format that I sometimes have a hard time reading it.

>     • @-prefixed date stamp
>     • B-prefixed bigint
>     • I could live with i-prefixed and f-prefixed integers and floats if people cared but the JSON “number” abstraction has never got in my way

I think as long as we specify the behavior adequately this time, we might not need i- and f-.  We could probably discuss prefixes as an extension space over time.

>     • Comments are totally not necessary

This I *strongly* disagree with.  One of the use cases that JSON is misused for is config files, and they badly need comments.

> But this is a fever dream, JSON has been JSON for many years and probably has more technical inertia than all the other data formats put together.

All new things have to start somewhere.  Worst case, nobody uses it -- I doubt it will hurt the Internet.

Joe Hildebrand