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

Carsten Bormann <cabo@tzi.org> Mon, 29 January 2024 10:05 UTC

Return-Path: <cabo@tzi.org>
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 53359C14F6AE; Mon, 29 Jan 2024 02:05:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 FVDj-jxmu2QS; Mon, 29 Jan 2024 02:05:53 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 1F002C14F5E8; Mon, 29 Jan 2024 02:05:51 -0800 (PST)
Received: from eduroam-0298.wlan.uni-bremen.de (eduroam-0298.wlan.uni-bremen.de [134.102.17.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4TNkT83Y0qzDCf8; Mon, 29 Jan 2024 11:05:48 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <PH0PR02MB7256FACC8FD6E1AAAB388365F27E2@PH0PR02MB7256.namprd02.prod.outlook.com>
Date: Mon, 29 Jan 2024 11:05:48 +0100
Cc: Joe Hildebrand <hildjj@cursive.net>, "json@ietf.org" <json@ietf.org>, "cbor@ietf.org" <cbor@ietf.org>, Tim Bray <tbray@textuality.com>
X-Mao-Original-Outgoing-Id: 728215547.972334-4415aef74ee1eff4098046133b9262e0
Content-Transfer-Encoding: quoted-printable
Message-Id: <4BED31C6-156C-4CF1-A3DC-31BCEC82806F@tzi.org>
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> <0BB09B30-B606-44CC-85DC-95A47E485316@cursive.net> <B22EDB2D-0AD1-4582-9191-EFB40E163F19@tzi.org> <F6EB02CA-C240-4FA1-92A8-C5BB883929C7@cursive.net> <29BD1557-59A1-4578-901B-C626ABBE9A78@tzi.org> <B25E10D2-17CF-4B3D-B04B-BABE3A209B90@cursive.net> <6A73993B-B54D-480D-AF79-081EE9D2E1C8@cursive.net> <94BD8ECC-0D50-4C09-9B29-7552AFC4D9ED@tzi.org> <0C97FF67-A3D4-44EC-BD17-AC1F7A2BA9A2@cursive.net> <80D3667A-BC74-4197-BBBC-2B7B9D478D34@tzi.org> <PH0PR02MB72562E37EEB0AC197AB28283F2782@PH0PR02MB7256.namprd02.prod.outlook.com> <64F16573-3CBB-4D21-B974-9E0E0E89D465@tzi.org> <PH0PR02MB7256FACC8FD6E1AAAB388365F27E2@PH0PR02MB7256.namprd02.prod.outlook.com>
To: Jeremy O'Donoghue <jodonogh@qti.qualcomm.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/-wak8TMcpVRX6xY-HldPBTm_Gn4>
Subject: Re: [Json] [Cbor] 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: Mon, 29 Jan 2024 10:05:57 -0000

On 2024-01-29, at 10:54, Jeremy O'Donoghue <jodonogh@qti.qualcomm.com> wrote:
> 
> “Note: Implementors are advised that the built-in numeric parsers in some programming implementations accept only a subset of the floating point syntax defined in [IEEE 754] and used in this document. In particular, care may be required with respect to supporting input with leading and/or trailing zeros.”

Thanks!

I combined this with the text already there, streamlined it a bit, and came up with:

https://github.com/cbor-wg/edn-literal/pull/30

Please have a look!
 
> Might also be good to have a couple of examples which are known to fail with at least some language parsers. At least for myself, the first thing I do in an implementation is to implement all of the examples in an RFC as test cases, so this is an easy way to ensure that implementers catch any issues.

There are some examples in that note; I’m not sure we should do a full-on attempt at defining test vectors in this document though.

Grüße, Carsten