IETF Logo Mail Archive

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

Joe Hildebrand <hildjj@cursive.net> Wed, 17 January 2024 17:07 UTC

Return-Path: <hildjj@cursive.net>
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 24AE4C151990 for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 09:07:02 -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, 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 (1024-bit key) header.d=cursive.net
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 Qrv-E_l1Bw9J for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 09:06:57 -0800 (PST)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 8570FC1516E2 for <json@ietf.org>; Wed, 17 Jan 2024 09:06:57 -0800 (PST)
Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-7831b3a48e7so667505085a.3 for <json@ietf.org>; Wed, 17 Jan 2024 09:06:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cursive.net; s=google; t=1705511216; x=1706116016; darn=ietf.org; 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=IhAwOfjvsW63xL4Bh9utdonvEdn+qKDR0WTPoM/5M4M=; b=mjvcXI9X3HsrNkoxh5xThqa820ym3yniEfihmd89/i+lZ6P1GRirz4UzIIRpoiX1ZS XSXiaSeuqxMvYDGotlQKydjevai3aJ/Vxrxqh40k6boMcotyzcEi1TqINCl6dztVcdO+ z6Z2TQWUrH3OMOSVAEM5CP6AnIvGHQOSG4Wgo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705511216; x=1706116016; 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=IhAwOfjvsW63xL4Bh9utdonvEdn+qKDR0WTPoM/5M4M=; b=qGH2B9Fl7tiGxAfou57gvERT9ojwkIulqlxrf36ogCp5afAzeuHxqf28/e9t/meHgD D3LP4UzZ4Ro1msT2+ocPmsX9CgpR6xwWTL1rFLdoBRCvzjEhAyaNcW6DF3HugvKd/mpu NkV+RhwhO6FA15MfJhkMn4UqZIUWtRMJt6tI6alu6w36tEzPFZKWsExZ5E5+xcl36Pkf I5kSfYCvc/ugdoi7Vg8B/WeR79EILVvrD6SU1dtY69zTGlohZp6V8VXDPAXmd7Bp/I6D L7S9WmzQBex4M8QQBGlMlULyP3d/CeGkYW4hHkFRLuGKhRP1AtADAPeGCvoAJLza/aAy Cw7w==
X-Gm-Message-State: AOJu0YyZhH3ByJG1X+xD0dstaH2vNy42Ct2TNYcAkuU80VhxtbSxiGGV ETiDvRUuGV0je2/CxA/h5pgZPhk6PAov
X-Google-Smtp-Source: AGHT+IHakvAMpKV3425sDbzbc/uwCWGSbYIg57sndSJVd3rxKRPBz4EZjSufxc9nbn65m+s0f1mThQ==
X-Received: by 2002:a05:6214:1c06:b0:680:b892:e3ed with SMTP id u6-20020a0562141c0600b00680b892e3edmr9710766qvc.109.1705511216256; Wed, 17 Jan 2024 09:06:56 -0800 (PST)
Received: from smtpclient.apple (pool-71-163-33-223.washdc.fios.verizon.net. [71.163.33.223]) by smtp.gmail.com with ESMTPSA id t3-20020a05621405c300b006818305cf8csm381317qvz.57.2024.01.17.09.06.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2024 09:06:55 -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 <hildjj@cursive.net>
In-Reply-To: <0D9273E3-A07F-4303-9AF7-89375FDC2496@tzi.org>
Date: Wed, 17 Jan 2024 12:06:45 -0500
Cc: Tim Bray <tbray@textuality.com>, Pete Cordell <petejson@codalogic.com>, "json@ietf.org" <json@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <360A7E32-C6F5-4EA4-AEDC-C61DE029BFB4@cursive.net>
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>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/ZP8MM3xLTEqECQ3jolHR7yV5wwI>
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:07:02 -0000

It may be an implementation detail which type gets generated from parsing.  The questions for interop are:

- are long integers without prefixes allowed or cause a parse error?
- if they are allowed, are they expected to have (somewhat unspecified) JSON behavior, or are they expected to behave in int-like fashion?
- are long numbers with decimals or exponents allowed, or cause a parse error?
- same as ints, what is their expected behavior?

Part of this depends on how much you want to be backward-compatible with JSON.

— 
Joe Hildebrand

> On Jan 17, 2024, at 12:02 PM, 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?).
> 
> Grüße, Carsten
>

v2.23.0 | Report a Bug | By Email