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

Rob Sayre <sayrer@gmail.com> Wed, 17 January 2024 18:32 UTC

Return-Path: <sayrer@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D138BC151980 for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 10:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11FwWTN5RMLQ for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 10:32:12 -0800 (PST)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 5C13EC14F698 for <json@ietf.org>; Wed, 17 Jan 2024 10:32:12 -0800 (PST)
Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a2dbc61fe89so421800166b.0 for <json@ietf.org>; Wed, 17 Jan 2024 10:32:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705516331; x=1706121131; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Tq0+ahACDYKCPKrpn7PQLsmsHbTi6RdpEmzfM45HkHM=; b=bemRmg3sWgE9JLSHYMmNsTdCEI4i6Ywfi+FaHAQXfLzy+fiq/vBft9AOt488MuWSab UBkcCIrVVwIMrX00P1kOkeZwG6yq0zRwLXmTzEWHyBRQOk5HoepiJTzprqniizgh8r6q P5tl9M7M4vtt3eGiELLoSfnow3J21WuC2j9VRPamjxFw+ncYIhu8odLW6O0T0ZGMxVRU spqVC0Ac1w3sM7DTvYRcKP1Xdpdohr1q4fGu2YqGIkJGh0dtAXU9wkYu5d11K5NxGtV0 k7vB+8VOpx7HBzkv2LjukSrOmIOuAoP5Bu2mTQcvsjCb4gx2rl0y4Unlwdhdn/Ngw3Ua 2TYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705516331; x=1706121131; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Tq0+ahACDYKCPKrpn7PQLsmsHbTi6RdpEmzfM45HkHM=; b=qsOvCrv8Tg1JZK4WbYaYxV1+99ndS+GEW5L/aJqSzIopXUbyvLbRoeNeDJ4qXaIe0F fE93vzm1fkHm8lcAOKxvrWaMAFpKuqhqfwkF9WnG3Ybw2+shoz2j5WHorz6jugnm6X+b uB7BA3aufpg1xAO2PZI11XyqyjCR8giSFtN9MCNgs9FSgLke4SfeCxB040fLksy9Nmps zdnMOP775PGlR5NhTqe1yBh0FWp7wSDmaL+0B0wPN8wbglhIq4YqkZDVQxeXydIe8YEf rTldyLOiLr/o36pG/jac0vXf/Qlgya6fQlsQe4GlIMnHaNRt696ZeyKu/pxguKAkTRtc LMZw==
X-Gm-Message-State: AOJu0Yyn1kOyRs9y+0v4QUmkOQqE0/vjAUPQk3dnQ8EErorrEg8F0p90 yW+EuLXjz3+spA8FBbj8zQhEv9ZsWIg7FHeWGPM=
X-Google-Smtp-Source: AGHT+IE4KRAHa5eRwGoBIFBULjY4xbmTmofOxhMiDvgE9W+XmQU5Z4LYb/7/i2zwCzx4l4UwAOfw0Wi2ry/DWjLyQCY=
X-Received: by 2002:a17:906:2f11:b0:a26:b71e:f75 with SMTP id v17-20020a1709062f1100b00a26b71e0f75mr4681337eji.5.1705516330413; Wed, 17 Jan 2024 10:32:10 -0800 (PST)
MIME-Version: 1.0
References: <87527a42-aaac-4f39-b320-05f18a2808c1@codalogic.com> <C31BF4C8-9E6C-48F8-BF7B-D2C379273B3F@tzi.org> <CAHBU6it4SaLawSiBgK9ySkbxjtHE6CX-P3r=hzcVy4ksoQo-Cg@mail.gmail.com> <CAChr6SxHfLW-A1asAndKJz-AiyJv5QP18bi=_bNdKXw7zYHThw@mail.gmail.com> <CAChr6SweYdCWxSABZ7g20Zd-xBFzcK0Ritq53S7WtjSwc-vLmw@mail.gmail.com> <E5A68370-CC2F-4618-AB39-39A382656616@cursive.net> <807fea1b-a22b-4d6b-aa5d-720c9b12023c@codalogic.com> <09233A73-3A6B-4E6F-AEB8-596AC6442E24@cursive.net> <869950DC-647B-4481-AEF8-9E092384E99F@tzi.org> <CBD32B58-8328-4602-89C6-BC2A7A875A0D@cursive.net> <994E2C0A-4AE0-4720-8C67-913BBF033E11@tzi.org> <CAHBU6isiUhvhk5VPpQ1A_kGDJZhsGLc1xkyu6pNeLUBHw2_dzg@mail.gmail.com> <0D9273E3-A07F-4303-9AF7-89375FDC2496@tzi.org> <360A7E32-C6F5-4EA4-AEDC-C61DE029BFB4@cursive.net> <3B62862C-AEF0-430A-9E9C-0AB3090F1EDE@tzi.org>
In-Reply-To: <3B62862C-AEF0-430A-9E9C-0AB3090F1EDE@tzi.org>
From: Rob Sayre <sayrer@gmail.com>
Date: Wed, 17 Jan 2024 10:31:58 -0800
Message-ID: <CAChr6Sy4gTWd=Wz23sFtuf8NzCYwW=Q1weBDJEXd1LhnOjf4ig@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Joe Hildebrand <hildjj@cursive.net>, Tim Bray <tbray@textuality.com>, Pete Cordell <petejson@codalogic.com>, "json@ietf.org" <json@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000008762a060f287762"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/XC5WYySqaQvLkHxWUNTGj1E-JqY>
Subject: Re: [Json] JSON and int64s - any change in current best practice since I-JSON
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/json/>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2024 18:32:16 -0000

On Wed, Jan 17, 2024 at 9:23 AM Carsten Bormann <cabo@tzi.org> wrote:

>
> > - if they are allowed, are they expected to have (somewhat unspecified)
> JSON behavior, or are they expected to behave in int-like fashion?
>
> There is no JSON behavior.  They are numbers, "similar to that used in
> most programming languages”.
>

Yes, and many JSON implementations work just fine with arbitrary precision
numbers, because that's what is used in the language.  In Ruby:

irb(main):002:0> require 'json'

=> true

irb(main):004:0>
JSON.parse("12341234124123412431234123412340982133049812394")
=> 12341234124123412431234123412340982133049812394

I think we all have things to dislike about JSON, but one thing that's hard
to argue with is its adoption. It was just "eval" in JavaScript as well as
Python at first, so that took off right away.

Similar to the JavaScript Number type:

> 123 + "abc"
'123abc'

So, then people begin to dislike the "keep going no matter what" style of
these approaches, because they do generate bugs in programs that are more
critical than MySpace pages. Then you get things like I-JSON, which
describes what not to assume about JSON in Ruby, for example.

thanks,
Rob