IETF Logo Mail Archive

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

Rob Sayre <sayrer@gmail.com> Wed, 17 January 2024 17:27 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 5BA8EC151990 for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 09:27:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 QxxztzvkuFDr for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 09:27:44 -0800 (PST)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 46C3BC14F61A for <json@ietf.org>; Wed, 17 Jan 2024 09:27:44 -0800 (PST)
Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a28bd9ca247so1356030666b.1 for <json@ietf.org>; Wed, 17 Jan 2024 09:27:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705512463; x=1706117263; 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=s0043Wya+LT1b9vunvxLDY8MHFUZ5dZJt98of2aEe2E=; b=XON55OVCriZ/TSGz0QjIB3xbRLXrDSoyOUZX3wrUXWjUSWw7cMdnvEqSwHLaPR4YRa ssgvCE+n6lVYZVLAyIV8KVZtR0sIDBOKwFrqRtLShy+K1KTTsT7UsrASSR9k80u2aj6D A9NRjQFqXAodAjcfcvataO6bnL2WyecGpAGClz0e5FJlj9mf9e5YfKXtdpoIkcn6n3mO jox2aE5Cdq5iG8PeLGIzTjipuxjLm55HDMf/JBHNYlCcEnpgiZiGTk5zo05qdKb4MIEk TCM6w2d44DQMolEfhaiqOpr8HOkOiXrJDc+bsiY2yc+YK5WEEfWhC2z9g5+Co61GZljH L64A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705512463; x=1706117263; 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=s0043Wya+LT1b9vunvxLDY8MHFUZ5dZJt98of2aEe2E=; b=P/IzvADSvIqSXl0lkIki+tMYGauJrYRuCvBhrHo0IzORn8W8jgZfOaf8IF7x7jN2UF lNuWFrjfYmJvUoLlJXvoKCmTCifNeGXvUqYadqqMuPfhUXYfpWMLApBvEhHkdOxy//a0 05geqm51F8Yq0MTtUQxjHggiWO9gqehX7lQDYhdi2XZptrCJL6Zf5h1b9COFt5tL7fvL +/dNp6WXS6hVx3yhxOLYgX9cJ9ljfyW9w/TU0f6juA5eKm7VRX/GFD2y9ysGpmOQTo0c OtNx/qvRMai4czKtZ/WWxT00JkBI4X3f75Dvrgc+JRI/HVccXAcJe4y6QxZVQ/aaYwT7 3NaQ==
X-Gm-Message-State: AOJu0YykOt8FY0Ak8CxFUSs76GZIJJABGBqeTYWYa0ewPJAmtttgGmwr KhhZzNlisxmT+zPg8DYGb3F0kLQUvg2kUbEnihY=
X-Google-Smtp-Source: AGHT+IFIlbXqrEkapGMSJDuozmu4UqhGC6HiuGzsRb1mktFfVLYGpD1IwWj8+QHcK27dmOuGxO4ULXU3DEvfAl+ofv0=
X-Received: by 2002:a17:907:a78c:b0:a2d:a17b:7fcf with SMTP id vx12-20020a170907a78c00b00a2da17b7fcfmr3698885ejc.52.1705512462412; Wed, 17 Jan 2024 09:27:42 -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>
In-Reply-To: <0D9273E3-A07F-4303-9AF7-89375FDC2496@tzi.org>
From: Rob Sayre <sayrer@gmail.com>
Date: Wed, 17 Jan 2024 09:27:30 -0800
Message-ID: <CAChr6Sw=em9poOXTEsYzxbFHSRsrWzFyZof50X4Tca0E2Fecuw@mail.gmail.com>
To: Carsten Bormann <cabo@tzi.org>
Cc: Tim Bray <tbray@textuality.com>, Pete Cordell <petejson@codalogic.com>, "json@ietf.org" <json@ietf.org>, Joe Hildebrand <hildjj@cursive.net>
Content-Type: multipart/alternative; boundary="0000000000007b6ebb060f27908b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/hQlhU-PTV7aCx9D8dr6xDYfp_RI>
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 17:27:48 -0000

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

> On 2024-01-17, at 17:57, Tim Bray <tbray@textuality.com> wrote:
> >
> >
> >
> > On Jan 17, 2024 at 8:54:40 AM, Carsten Bormann <cabo@tzi.org> wrote:
> >>
> >> What *is* a “local bigint type” in Rust?  Ruby?  Erlang?
> >
> > An integer of unbounded size, no?
>
> But 1 is not of unbounded size, so I don’t understand what 1n means.
>
> The syntax 1n seems to assume that the target platform has a separable
> type for those integers of unbounded size.  That doesn’t work with
> platforms where integers of unbounded size aren’t anything special.  It is
> also weird with platforms that have many bounded types to choose from (is
> i128 OK for 1n?).
>

I still think CBOR would be better here, because you can cover all this
stuff:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Typed_arrays#typed_array_views

and get Blobs:
https://developer.mozilla.org/en-US/docs/Web/API/Blob

and Dates:
https://www.rfc-editor.org/rfc/rfc8949.html#section-3.4.1

The BigInt in JSON issue is widely duplicated in the TC39 Github, so I do
agree the problem is real. Might as well really go after all of this stuff
at once, though.

thanks,
Rob

v2.23.0 | Report a Bug | By Email