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

Joe Hildebrand <> Thu, 25 January 2024 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CD06C14F6A7 for <>; Thu, 25 Jan 2024 14:42:17 -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 ZlZOYmQKctI4 for <>; Thu, 25 Jan 2024 14:42:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (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 05E53C14F61C for <>; Thu, 25 Jan 2024 14:42:12 -0800 (PST)
Received: by with SMTP id ca18e2360f4ac-7bfbe61859dso575339f.1 for <>; Thu, 25 Jan 2024 14:42:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1706222532; x=1706827332;; 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=RwfZpphItvCUR+jj3j1Szeq7pYiqyJJYg39A7kHW6wo=; b=IgAcHFu7YDwU3ANFZsaRwWdviIfXGij/LoZ57gBYIEW7ovwksnLS+u4rNIqmyQvcnc wxKkkjdVRjPnvDIRZ0QR4+OhroVmPqE7D7pOW8MFkESBK3Q8Ltjqz6XhYJVjs34eR/B9 xZi/iaNExZvwwWJA3bXYhq8klfk1+93nVDr3U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706222532; x=1706827332; 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=RwfZpphItvCUR+jj3j1Szeq7pYiqyJJYg39A7kHW6wo=; b=RVnVbhb6fdxyfjUt/0Qayp/5cb16svyc41ZS3eJM1recAlAsEQrEEANT9qeNeIwOzo XPrMt7+ComnYMU1ToN3oLjdTL/eH7vLKa2ZSj8PpTK/25xkgC+6mVYA8boH86fKMbabb h2CP248jekbjyUlg9Wi+GhfF7LsnRCsYCECVKAFAyWLy+aIZQsTCYBtgdiPItaqPww9P WQYxcd2pJBn8kRHt3ILINCYwtUdLTmZsJxp2Ab17ja0JRdJrEEZGsxZoBkwj1NYRRK4D 9DcMQopV3qAEn7uo2REEgPfU8wPXjXq2JDuDzyWcEs8RZNzPrRVj7wZPhzEVA/a5Teex jDJg==
X-Gm-Message-State: AOJu0YyVWrmvbmNgTo5ykk18gExYokaWENStJep7hu7HaxIA5ysiBfZ6 4HNR+m8OGYFvpa7fRYNYVNuzzHEqCxPWeIH04RZVjTNGDuypuD3nigLORnX0gS7uzsFR+3wUkUI =
X-Google-Smtp-Source: AGHT+IEIlP9fOmd2VgnqnG09OGfzoaQpnqPOGUq65qu+BRzWwLyiEmdbSMv+hSxXOGtb8y4sfYW8zA==
X-Received: by 2002:a5e:9744:0:b0:7bf:ad62:eccb with SMTP id h4-20020a5e9744000000b007bfad62eccbmr547122ioq.26.1706222532173; Thu, 25 Jan 2024 14:42:12 -0800 (PST)
Received: from ([2601:282:2100:4fc9:25e1:9353:a850:2867]) by with ESMTPSA id i5-20020a5d8405000000b007bbab8c40d2sm7886048ion.44.2024. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2024 14:42:11 -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: Thu, 25 Jan 2024 15:42:00 -0700
Cc: Daniel P <>, JSON WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Rob Sayre <>
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: Thu, 25 Jan 2024 22:42:17 -0000

If we were going to do any more work on this, I agree that there would have to be a unifying philosophy; I bet that would answer this question.

As it stands, unless there are a few more people who get excited about putting effort into this, it's probably not worth discussing each of the points on the laundry list until we come to conclusions.

Joe Hildebrand

> On Jan 25, 2024, at 3:16 PM, Rob Sayre <> wrote:
> On Thu, Jan 25, 2024 at 1:56 PM Joe Hildebrand <> wrote:
> Yes, unless we decided that significant digits mattered.  This was just copied from JSON5, I don't feel strongly about it myself, but apparently it's a thing that bites people trying to hand-type JSON sometimes?
> That is a philosophical difference your effort should take a stand on. JSON has no comments, and it does not allow trailing commas because "that would mean someone is hand-writing it" (loose paraphrase). I think for the numbers you should check what David M. Gay's strtod things do. There, I think there is no debate, just reality (the GNU versions are close).
> If you write Protocol Buffers or something, there are comments and trailing commas. This is because to disallow them would be a pain for the person adding the next field. You always have to add a field, because there is an inevitable transition phase, even if you intended to make one unused.
> thanks,
> Rob