Re: [Json] JSON Schema Language

Nico Williams <nico@cryptonector.com> Wed, 08 May 2019 16:07 UTC

Return-Path: <nico@cryptonector.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 4B07B120150 for <json@ietfa.amsl.com>; Wed, 8 May 2019 09:07:55 -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=cryptonector.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 XJ3cX4RWv2zx for <json@ietfa.amsl.com>; Wed, 8 May 2019 09:07:53 -0700 (PDT)
Received: from golden.birch.relay.mailchannels.net (golden.birch.relay.mailchannels.net [23.83.209.73]) (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 51BA812013C for <json@ietf.org>; Wed, 8 May 2019 09:07:53 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4EAF95020C6; Wed, 8 May 2019 16:07:52 +0000 (UTC)
Received: from pdx1-sub0-mail-a33.g.dreamhost.com (100-96-15-20.trex.outbound.svc.cluster.local [100.96.15.20]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 27B0A502118; Wed, 8 May 2019 16:07:51 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a33.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 08 May 2019 16:07:52 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Stretch-Rock: 25d856eb1203cc7a_1557331671694_624645791
X-MC-Loop-Signature: 1557331671694:1951836751
X-MC-Ingress-Time: 1557331671693
Received: from pdx1-sub0-mail-a33.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTP id 870C580062; Wed, 8 May 2019 09:07:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=FFZCyDRf85BAxB 4ickXiQHx2vWE=; b=CzcjQB9jYEq/8n0dhxrJG1uu5IGPHJlBnVOuFPVJCl4oZm JSKQXNqiIC44HpBLL4rk9B1scbIx15/3YBRMgBoFRyRHTS80Wjkda3Y4Iq6Dv9F5 GeI7X5OUXr0SWYkp0yV8FiDAO2HUd7R1xPYEoVs2AbckeFkAfwdAu22FgoSs8=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a33.g.dreamhost.com (Postfix) with ESMTPSA id AC69D8003F; Wed, 8 May 2019 09:07:43 -0700 (PDT)
Date: Wed, 08 May 2019 11:07:41 -0500
X-DH-BACKEND: pdx1-sub0-mail-a33
From: Nico Williams <nico@cryptonector.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Ulysse Carion <ulysse@segment.com>, Austin Wright <aaa@bzfx.net>, JSON WG <json@ietf.org>
Message-ID: <20190508160740.GU21049@localhost>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <702ee54b-9465-7ca8-b521-2a88c1a47785@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdeljecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/json/7C7At9r5MIrJlbc9z2sFv6TKKQM>
Subject: Re: [Json] 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: Wed, 08 May 2019 16:07:55 -0000

On Wed, May 08, 2019 at 06:40:14AM +0200, Anders Rundgren wrote:
> I believe I have stated my opinion but here it is again:
> 
> The idea is not changing JSON in any way but to add *strictness* to
> its interpretation.

That's not an innocent change.  It breaks interoperability.

> This has ZERO impact on JSON parsers but could in some cases affect

Not true: it makes them reject more inputs, which makes them less
interoperable.

> JSON serialization.

Exactly, so not OK.

> There are no problems defining a set of numeric types having a range
> and syntax that conforms to what is the norm for most programming
> languages since all of that fits nicely into JSON.

This is insufficient justification for making JSON parsing more strict.

> However, assuming that any JSON parser also could be used for
> *implementing* JSL (including verifying arbitrary input data) will set
> the bar way too low.
> 
> Regarding the integer discussion I believe Open API/Swagger which has
> quite an active and big user community already flags 3.0 as an invalid
> integer.  A bug report on Open API (or on Jackson) would most likely
> return "works as intended".

That's an interop bug.  They should fix it.

Nico
--