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

Joe Hildebrand <> Thu, 25 January 2024 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3712AC14F60C for <>; Thu, 25 Jan 2024 07:21:06 -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_DNSWL_NONE=-0.0001, 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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QiP6J04WRoKL for <>; Thu, 25 Jan 2024 07:21:01 -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 23A51C14F697 for <>; Thu, 25 Jan 2024 07:21:01 -0800 (PST)
Received: by with SMTP id ca18e2360f4ac-7bc332d49f6so298165639f.1 for <>; Thu, 25 Jan 2024 07:21:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1706196060; x=1706800860;; 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=LW6J4CXcuM6EqDqXV3IkV2XPwukTE5OF2uxN5Ar59Ok=; b=SA+UN53PzpfCR5k44Ksyhh24tsrYZcAzI8dYa7YrLtjFhBZB/IB0yg+H5p2eAVe175 UMa7vndqd+WYW2a40WCY25Hat9fmkM8YLC9q5w5qKg/1L0M9Tkg1C1g26d7OiM/u09qy 1g1YgOvllQUZrSxeM17mbAJ9QTipcmt7qsWHk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1706196060; x=1706800860; 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=LW6J4CXcuM6EqDqXV3IkV2XPwukTE5OF2uxN5Ar59Ok=; b=cFBemEn3/V+VchIgz4isj6fdUWxOOTdIJ6MabL7kidoNPh9RdGHD5mIJMKoHo5HvJP vXBXEXMj3KA5KbAKs5ktW0CeplbdYilGW3zRniBjB3qqhUWq12znAIqM5AZ6xzCjb9zJ lKUguo/Z6YmQmc7WsMESXwO9sD3Rhoxs0IqRXu8US8Brdoff/n6kgeAEI55DmGflSkH9 N5ebhgY3OrXITW0ZB5maRbNOOJ6pKcS2GNkxNQRgWEULyU6BXf1SsuZgisN2hK3b43gP gGZsyWFAyeT4C58AUyawnj8YE0NjM5QmJ1Yw7qybf0/t8sIFOkKEiwK92q5nL8VNS4O9 cdlg==
X-Gm-Message-State: AOJu0YzT3Sudir5a1zp5byxiFEZDv35MPYBLE/X4U26hHNNAP/DqvnKn jrdKQt4NBTVNbb+J+OGjVF8pGbzfJjOrMQnLqyBJfvP3Tlj8WPfmmzBf8eWp8svWiHFrFYXPLgA =
X-Google-Smtp-Source: AGHT+IF7zLdROuKRv0u9vEsOupxWLQ0mvj/VhTic2XdfSlfPr4zilPy7HiirluVLt9zyKUvmtOe0ow==
X-Received: by 2002:a05:6602:1241:b0:7be:f7e5:44fc with SMTP id o1-20020a056602124100b007bef7e544fcmr1346932iou.21.1706196060080; Thu, 25 Jan 2024 07:21:00 -0800 (PST)
Received: from ([2601:282:2100:4fc9:25e1:9353:a850:2867]) by with ESMTPSA id c14-20020a056602334e00b007bc102fb67asm7665918ioz.10.2024. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2024 07:20:59 -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 08:20:48 -0700
Cc: "" <>,, Tim Bray <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Carsten Bormann <>
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 15:21:06 -0000

> On Jan 25, 2024, at 7:50 AM, Carsten Bormann <> wrote:
> * 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?

Yes.  For anyone else interested, see here:

This is not the place for my rant on how NFD is probably better for most modern protocols than NFKC -- that probably belongs in the CDE thread if anywhere. :)

> * 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.

I don't think it's worth losing a feature for.

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

For leading, probably none.  For trailing, it might be a sign that the number should be treated as floating point, so that there is a difference between `1` and `1.` in environments where there are different types for float and int.  At the very list, the range checking should be different.

> * 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.


Joe Hildebrand