Re: [Json] Adding integers to JSON (Re: JSON Schema Language)

"Manger, James" <James.H.Manger@team.telstra.com> Fri, 10 May 2019 07:57 UTC

Return-Path: <James.H.Manger@team.telstra.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 65022120194 for <json@ietfa.amsl.com>; Fri, 10 May 2019 00:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=team.telstra.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0_Gqj2Eh9rE for <json@ietfa.amsl.com>; Fri, 10 May 2019 00:57:01 -0700 (PDT)
Received: from ipxdno.tcif.telstra.com.au (ipxdno.tcif.telstra.com.au [203.35.82.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1D0120178 for <json@ietf.org>; Fri, 10 May 2019 00:56:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,452,1549890000"; d="scan'208";a="131554484"
X-Amp-Result: SKIPPED(no attachment in message)
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipodni.tcif.telstra.com.au with ESMTP; 10 May 2019 17:56:56 +1000
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 10 May 2019 17:56:56 +1000
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsmsg3754.srv.dir.telstra.com (172.49.40.198) with Microsoft SMTP Server (TLS) id 8.3.485.1; Fri, 10 May 2019 17:56:56 +1000
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 10 May 2019 17:56:48 +1000
Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 10 May 2019 17:56:48 +1000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.telstra.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yShu74r1T/+4Uvpnp+Wxmyat4QnrmxBsvc5Ij+skUeQ=; b=FdazfSJmg9UyNR73S2m3dEOpwh8K9LQrh/zHZU1XRGAMTH8cmuYeKS38lnGnddxurWPhN1VAz26+8VjEVJ8ZH45hgy5JGJuGAv7ab+24LqC2rJ0747N6jqO6Muaodfc1hD31NgaHIssZV6l8IPMU9jjfget4JLX9yuQnX1ls89s=
Received: from MEXPR01MB0934.ausprd01.prod.outlook.com (10.169.161.142) by MEXPR01MB1447.ausprd01.prod.outlook.com (10.175.213.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Fri, 10 May 2019 07:56:47 +0000
Received: from MEXPR01MB0934.ausprd01.prod.outlook.com ([fe80::949c:37b:f402:9d3e]) by MEXPR01MB0934.ausprd01.prod.outlook.com ([fe80::949c:37b:f402:9d3e%4]) with mapi id 15.20.1878.022; Fri, 10 May 2019 07:56:47 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Austin Wright <aaa@bzfx.net>, Carsten Bormann <cabo@tzi.org>
CC: JSON WG <json@ietf.org>
Thread-Topic: [Json] Adding integers to JSON (Re: JSON Schema Language)
Thread-Index: AQHVBb+KgK8JWxXYs02YvYkrY6zczqZh1QwAgACGbICAAY+DgIAABriQ
Date: Fri, 10 May 2019 07:56:47 +0000
Message-ID: <MEXPR01MB09341A56C01F2BAB1BD195A5E50C0@MEXPR01MB0934.ausprd01.prod.outlook.com>
References: <CAHBU6itE8kub1qtdRoW8BqxaOmzMv=vUo1aDeuAr3HX141NUGg@mail.gmail.com> <77994bdb-a400-be90-5893-b846a8e13899@gmail.com> <20190507154201.GP21049@localhost> <CEF72901-5077-4305-BA68-60624DCE952D@bzfx.net> <69ea0c99-e983-5972-c0aa-824ddeecb7c4@dret.net> <CAMm+LwjyVjnJuWE4+a9Ea=_X1uuEGuK+O4KojzN3uVQ+s+HqUQ@mail.gmail.com> <058f58a3-dd27-998e-5f54-4874aff5f2f0@dret.net> <20190507221726.GR21049@localhost> <CAJK=1Rj7PBD-bbwvsqgjQQzp4Aoidb-W2q5Lj6asMHHDHaTVYQ@mail.gmail.com> <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com> <20190508160740.GU21049@localhost> <ACD9A0A2-A75E-4B6E-9E9B-165DC222781B@tzi.org> <02755092-1682-45E8-AB6C-0EDA7D35703A@bzfx.net> <B7EA86E6-A9F3-45FE-8436-2F36812C615B@tzi.org> <92D865C6-9990-46B1-961E-2DDD7D06617C@bzfx.net>
In-Reply-To: <92D865C6-9990-46B1-961E-2DDD7D06617C@bzfx.net>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 10.0.500.19
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com;
x-originating-ip: [203.41.142.253]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c41c3457-16df-4ff1-e5d4-08d6d51d0d63
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MEXPR01MB1447;
x-ms-traffictypediagnostic: MEXPR01MB1447:
x-microsoft-antispam-prvs: <MEXPR01MB1447BC5C21AA123CF9C7C34AE50C0@MEXPR01MB1447.ausprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0033AAD26D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(376002)(346002)(39860400002)(189003)(199004)(81166006)(81156014)(74316002)(8676002)(6436002)(14444005)(256004)(8936002)(102836004)(7736002)(86362001)(305945005)(66066001)(486006)(5660300002)(72206003)(229853002)(71190400001)(71200400001)(478600001)(76176011)(476003)(52536014)(110136005)(7696005)(186003)(99286004)(26005)(6506007)(316002)(446003)(25786009)(2906002)(4326008)(11346002)(6246003)(3846002)(6116002)(55016002)(73956011)(9686003)(76116006)(66946007)(66476007)(66556008)(64756008)(66446008)(68736007)(33656002)(53936002)(66574012)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MEXPR01MB1447; H:MEXPR01MB0934.ausprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: +MalQBpwRG9zrQGHAzCe4PWBTkbjOTwh6P+cWrIRpcukU81ZjSJMxmFqEaJlq8DTBD1MiNcLEbqyax5gbYA8jX1RDswgQ0e+vDdPj6nbUfehIsI3vcwTcUYmetkjHgtCdLn8A2vdAsjQSzLsffE4PgfcpW8hKac2j2X/4MFnx9a04D8PBTJjoVbPqBitnNx8s7BQmEOyN0KfuCOiOosPpL7Bdhf9tG0jGznTDdYDD8ngMTm3HWTU8UBJVb0+MJfG6PvrtoOmR3LMo3XxU+Hsn9RRdWpfsXOO85wKTbGKGP8L1bU94i0vT6wznAqf3dCnB5ne0QbnlNIwG9FLVNigu6MtWJoGpaRfqb9fzxPNVjMNwnrcny9Dcj29PRxCsdCveKgw20BkPOMTnmhrQg+v4+mQ3KyrY2XlD2YVdMB/c7E=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c41c3457-16df-4ff1-e5d4-08d6d51d0d63
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 07:56:47.3991 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEXPR01MB1447
X-OriginatorOrg: team.telstra.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/7-7WaGdCTiQZZR2EIgS9icb-8z4>
Subject: Re: [Json] Adding integers to JSON (Re: JSON Schema Language)
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 10 May 2019 07:57:04 -0000

> “SHOULD" allows implementations to vary from the suggested behavior if there’s a reason. RFC8259 specifically says the reason is interoperability, and also says implementations might report all of the key-value pairs, even repeated keys. So if two implementations agree that repeated keys are meaningful, that seems legal to me.

NO WAY!
RFC8259 JSON explicitly says when keys in an object are not unique the behaviour of parsers is unpredictable. So it you specify a system that gives meaning to repeated keys then lots of JSON parsers will be unusable in this case. Hence, it is harmful to call that JSON, call it "ECMA 404 syntax without normal JSON semantics".

> I don’t see how the fact JSON can be streamed changes this. HTTP says servers must produce errors on some headers if they’re repeated; and HTTP is also parsed by streaming parsers.

The number of elements in a JSON object and the number of headers in an HTTP message are both theoretically unbounded. But there is a strong assumption that the latter (#headers) is limited: typically 10s, perhaps 100, never 1000s. Web servers limit total header size to, say, 8KB. That is small enough to always handle repeats. While many JSON objects will also be small, JSON is such a generic format that you cannot make a global assumption that JSON objects will always be small enough to hold in memory. Hence some apps will need streaming JSON processors that cannot reasonably detect duplicate keys (so the "SHOULD" is there to accommodate these).


> Now, if the vast majority of JSON implementations don’t recognize excess precision, and don’t allow (or ignore) repeated keys, then maybe JSON should be updated to reflect that.

RFC8259 JSON does have that text. For example, "good interoperability can be achieved by implementations that expect no more precision or range than [64-bit floats] provide"; "when the names within an object are not unique, the behavior [...] is unpredictable".

For more concrete text, use RFC7493 I-JSON (Internet JSON is a restricted profile of JSON).

--
James Manger