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 18:58 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 B2A83C14F6F1 for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 10:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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 5oPyU2xXdZNQ for <json@ietfa.amsl.com>; Wed, 17 Jan 2024 10:57:59 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 64BB4C14F602 for <json@ietf.org>; Wed, 17 Jan 2024 10:57:59 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-50e72e3d435so11016654e87.2 for <json@ietf.org>; Wed, 17 Jan 2024 10:57:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705517877; x=1706122677; 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=ZvQjKGOziWXEtu1Gx8QWC1IJdrtCu0punAcTdfDS8u0=; b=FB+QLTkzhEj6XlZSygUaRMLPGQKJXOZChis8W0RTOmk4un8saxRaBoPFclCr4AXGpu qfMKBjqZy1QKkFGISxW9AqG5daT0blKEjf05Ozsxp9U8EZOS/MKFp6+D7gY8kJfpJlcS /NUF90lTvFaSG6TDtMAufOLZmQiskMe/pPxZsBKbvMDl5zA++GCwEXYOHln5u3qQG52Y hiziunHXrZdXvm6R7r5tuTrX/66IWTMTa3sRJk6ZrF0yjCUNeK+w/wEVvwcMooDbfRC6 +aknu84+awdVBVT1L+MF6MgoOJ2uTp31qX6zl+1AB/pr28Fa2+EEojegqCYdCTkUT1fk SuKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705517877; x=1706122677; 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=ZvQjKGOziWXEtu1Gx8QWC1IJdrtCu0punAcTdfDS8u0=; b=a1W6ZlWKSBHbe47cgspnwjBgif/EeC5FDPMFBa02VeP0wN4BULuEPdWkW3PfDp/VLm /IFG9ukJaNmpMj4ME9opiQbEOkJ3p86T1drZFns0yKlyfGeNcqsLD9lS4wmiBHyOGzBb yFkrPoZIQgnZTVm/dUSADPuyLkUec3OXwZqofF0YlXZuwLgpMkOxVFp5g5ORSFdOWz/s 2DiskzPflvdcq8PWDkpOEkYdI3jcGj1wSOmLeWE/oF3Y+jzrForfmsE7FalyzIWOUXeh AaGl3bywe1plKvBa5V6bOrQjqgHvC8RiffXk1wSVycmDSVv3in8VZLyEo8eVBMNbSfF5 xrOQ==
X-Gm-Message-State: AOJu0YykAmr5u8Q+VsuDQeriKpK+9biIhbYZ1E6SYVYueIkdiTC7I5nP wrfVwh7V0tuSyc04qcCqbgNxphWyEVg2UPNk1ac=
X-Google-Smtp-Source: AGHT+IGLuAYIDH6IvUE+KFyImx87nfm2lfhHaC9VtONBC8jOI4H27C0sSx+juxB/2MfvqstEis5PFnuMvHM4IyCH+WY=
X-Received: by 2002:ac2:530a:0:b0:50e:771e:e09e with SMTP id c10-20020ac2530a000000b0050e771ee09emr2917205lfh.125.1705517877047; Wed, 17 Jan 2024 10:57:57 -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> <CAChr6Sw=em9poOXTEsYzxbFHSRsrWzFyZof50X4Tca0E2Fecuw@mail.gmail.com> <CAHBU6it4rvnYQGnrwrigAtL05O7SH2coRrq91Si1xr3u7oC47w@mail.gmail.com> <E798F54D-B727-42E5-8229-DB1F75C9378F@cursive.net>
In-Reply-To: <E798F54D-B727-42E5-8229-DB1F75C9378F@cursive.net>
From: Rob Sayre <sayrer@gmail.com>
Date: Wed, 17 Jan 2024 10:57:45 -0800
Message-ID: <CAChr6SyX3kxG6YFGv7mTJ7fRcZmQEytD2W3c1aYZeKF_PHn7+A@mail.gmail.com>
To: Joe Hildebrand <hildjj@cursive.net>
Cc: Tim Bray <tbray@textuality.com>, Pete Cordell <petejson@codalogic.com>, "json@ietf.org" <json@ietf.org>, Carsten Bormann <cabo@tzi.org>
Content-Type: multipart/alternative; boundary="000000000000383734060f28d390"
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/6q1eMXPY_eGYWJuMbArBSEyyjXA>
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:58:01 -0000

On Wed, Jan 17, 2024 at 10:49 AM Joe Hildebrand <hildjj@cursive.net> wrote:

>
> > But this is a fever dream, JSON has been JSON for many years and
> probably has more technical inertia than all the other data formats put
> together.
>
> All new things have to start somewhere.  Worst case, nobody uses it -- I
> doubt it will hurt the Internet.


This I agree with, there is probably more not-actually-json.json stuff
already out there than this effort will generate.

But I think most people come around to something like CBOR or Protocol
Buffers or Avro eventually. So, is there a place for this EJSON/SuperJSON
thing? I don't think so, but I certainly don't think it's harmful.

FWIW, comments were deliberately excluded in JSON, because Crockford
thought people would use them for extensions that might change the
processing model. Difficult to disagree with that call given the behavior
of software companies in the 90s. These days, I think everyone is a bit
better about this kind of thing.

thanks,
Rob

v2.23.0 | Report a Bug | By Email