From nobody Wed Apr 4 10:25:47 2018 Return-Path: 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 0999D124C27 for ; Wed, 4 Apr 2018 10:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 7SPGgtV-3zIh for ; Wed, 4 Apr 2018 10:25:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A0B126C22 for ; Wed, 4 Apr 2018 10:25:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7B985B810A1; Wed, 4 Apr 2018 10:25:15 -0700 (PDT) To: tbray@textuality.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, linuxwolf+ietf@outer-planes.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: joakim.erdfelt@gmail.com, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180404172515.7B985B810A1@rfc-editor.org> Date: Wed, 4 Apr 2018 10:25:15 -0700 (PDT) Archived-At: Subject: [Json] [Editorial Errata Reported] RFC8259 (5318) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:25:46 -0000 The following errata report has been submitted for RFC8259, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5318 -------------------------------------- Type: Editorial Reported by: Joakim Erdfelt Section: 7 Original Text ------------- string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-5B / %x5D-10FFFF Corrected Text -------------- string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX escape = %x5C ; \ quotation-mark = %x22 ; " unescaped = %x20-21 / %x23-2E / %x30-5B / %x5D-10FFFF Notes ----- The solidus U+002F is listed as being escaped above, but is not excluded in the 'unescaped' sequence. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8259 (draft-ietf-jsonbis-rfc7159bis-04) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : December 2017 Author(s) : T. Bray, Ed. Category : INTERNET STANDARD Source : Javascript Object Notation Update Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Wed Apr 4 10:50:04 2018 Return-Path: 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 81914126BF6 for ; Wed, 4 Apr 2018 10:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 O1N22M7HO2Kz for ; Wed, 4 Apr 2018 10:50:00 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 3D250124C27 for ; Wed, 4 Apr 2018 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w34HnrJ7026315; Wed, 4 Apr 2018 19:49:53 +0200 (CEST) Received: from [192.168.217.114] (p5DC7FA72.dip0.t-ipconnect.de [93.199.250.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40GYPr4xSJzDfCb; Wed, 4 Apr 2018 19:49:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <20180404172515.7B985B810A1@rfc-editor.org> Date: Wed, 4 Apr 2018 19:49:51 +0200 Cc: tbray@textuality.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, linuxwolf+ietf@outer-planes.net, joakim.erdfelt@gmail.com, json@ietf.org X-Mao-Original-Outgoing-Id: 544556990.118723-86ead9f234c868060ad85ada26f1561d Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180404172515.7B985B810A1@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Json] [Editorial Errata Reported] RFC8259 (5318) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 17:50:03 -0000 On Apr 4, 2018, at 19:25, RFC Errata System = wrote: >=20 > The solidus U+002F is listed as being escaped above, but is not = excluded in the 'unescaped' sequence. This is exactly as it should be =E2=80=94 escaping the slash is = optional, as it is unnecessary (and is generally not done outside the = inclusion of JavaScript in HTML script elements, where it is needed to = provide data transparency for strings containing =E2=80=9C=E2=80=9D= ). Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Apr 9 08:32:00 2018 Return-Path: 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 0B8C912AAB6 for ; Mon, 9 Apr 2018 08:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.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 zel_pDmGz8H9 for ; Mon, 9 Apr 2018 08:31:57 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64422124BE8 for ; Mon, 9 Apr 2018 08:31:57 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id n40-v6so9074124otd.3 for ; Mon, 09 Apr 2018 08:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LWNmWjqiA32XzzeZ0GbydmvKytgokPleBu9BvLrgiDk=; b=a8TM/qIagZVzf8wuf8wwjF04r42WYr2PWRPxnPHckFUsIveoS/43xdJT/k3Aw3oT4Q 0Ma5zE0eUuUcqYVQoirJ8SZQbiNMIw9eYVDQb+GkoUNufjV5D5WPpvXcgwNreHg0xeIG YVxax7Tof5k3KevJvzldcWqiFIdGM1Tr0mOkVBuyFQ3rCIJIaeUgtqAx6pxAIWimI+IZ JQVj9O3RV2kXfo1TouXs7DCU/3RHhvaeGgPqhM+UWyV9mDtUztT6slGeRfRpkS6o5UKe mqpXVSrM+/9spjd2abG5DxqQMIdXPT7EJ3dcYUPHkd0kC2ifgs8YojpzUNokYQdW/VmY gv5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LWNmWjqiA32XzzeZ0GbydmvKytgokPleBu9BvLrgiDk=; b=oiofepWEHGFvQaCKR+ZRZdjcJkVvpoqZl8UrcwhJ+SBbys1PtObe3bt1TN9zY44MB9 6cg7RfWaYdu2uJQK0MFJJUyloi4KkHR588UnA4eK1izlGCL3EXZ9Kmpo89XbkKmtIteQ BPpst/CG8lVO0oSghMzmi7W8nyHy1brLXNafktcrMmtBoZxdKNTzuufDlAEkJzMSeqGz S4wGMhvq0Ufq8U/A8fPT7djLLXXmRVJtwnTaDoqwe30luyA5RfDElUCPH+FTARs8b1rX gJVf+FjoC1DVuquTKu8ml/RCx68BHMBlY+8oLFRahNyF1hYWDfQlRNYjBMHD4YvuRv9m CMrQ== X-Gm-Message-State: ALQs6tBIJ8lLGiNDuBuqdRqnEi17oIDq78T8X5HbtnxC094Jw6ZX5ZkV 2i1RwU75HC1O9b6V0ywB+ZHX9A== X-Google-Smtp-Source: AIpwx4+Z5Fs9Q8+c9uQ3q0MrzQZ4DMlpVft2FZJurKBw8C9y+gk7uod7jvFIoe0QjjCxZhJixEislA== X-Received: by 2002:a9d:2e68:: with SMTP id c37-v6mr18463962otd.373.1523287916606; Mon, 09 Apr 2018 08:31:56 -0700 (PDT) Received: from [10.6.21.160] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id 15-v6sm296387oix.2.2018.04.09.08.31.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 08:31:55 -0700 (PDT) Sender: Matthew Miller To: Carsten Bormann , RFC Errata System Cc: ben@nostrum.com, adam@nostrum.com, aamelnikov@fastmail.fm, json@ietf.org, tbray@textuality.com, joakim.erdfelt@gmail.com References: <20180404172515.7B985B810A1@rfc-editor.org> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: <8724e749-b472-1fd1-f6d8-fd02a200f557@outer-planes.net> Date: Mon, 9 Apr 2018 09:31:54 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] [Editorial Errata Reported] RFC8259 (5318) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2018 15:31:59 -0000 RFC Editor, Please reject this erratum. As Carsten stated, the solidus character is valid in a string unescaped as well as escaped. - m&m Matthew A. Miller On 18/04/04 11:49, Carsten Bormann wrote: > On Apr 4, 2018, at 19:25, RFC Errata System wrote: >> >> The solidus U+002F is listed as being escaped above, but is not excluded in the 'unescaped' sequence. > > This is exactly as it should be — escaping the slash is optional, as it is unnecessary (and is generally not done outside the inclusion of JavaScript in HTML script elements, where it is needed to provide data transparency for strings containing “”). > > Grüße, Carsten > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sat Apr 21 08:14:26 2018 Return-Path: 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 523E91275FD for ; Sat, 21 Apr 2018 08:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDP4aE8kohJj for ; Sat, 21 Apr 2018 08:14:22 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FB3C1274D2 for ; Sat, 21 Apr 2018 08:14:22 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id h3-v6so30029297wrh.5 for ; Sat, 21 Apr 2018 08:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=5WAL/5ml/psEBhNPeJBNlwORs9FP+yCROfK9JO7Ifc0=; b=BqfpDGglDaxnTE3nzTBygauazKm88fcdXSaW5i+cfixWGIIyDrDb7dUYVe3fjD47se RHfW7hhquivYIcgBv8VCIc4npx5oiHCJrxiBy0i985n3j6oonBEh7ZeKWAUsLhqzui7u w6r9AgvyiBxngzsVtqgxOAX4UpxUb7FHolkGHbZzVKphOezHlebQ+QNYcj4EqgM19/rM teVQ0KfFPS+AOmsdB3B4qj2r6lPrDqaTZZjEQ03wcNi9dWpX0RIi1nhkLbd6Oo/HJW4S N/Z4w6ewKnHNrwcJ5wGJ9pztDM7gvCZMNuiKPD5Q8r3a/unDX2zNQEZsL3018kvWNBDr Jhcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=5WAL/5ml/psEBhNPeJBNlwORs9FP+yCROfK9JO7Ifc0=; b=RxoBCpi5Jqa4y7z+uULTkvRSJhLCAdCltL8v3RtlgFGK5mZWanoe/tqbBVAoJJmbaZ k6tKKsBAk3UzeTzfkeB6SPZ5YPH1MHx3Hsi225gboTh1+O1HeY+2AuG8Z1LGyEmd0DEi dIIktCMiUHiBraLtkH6m0Hl1yYXWIutgPuoqzuC2xilOt6rVjBsdSM2AwKbwzI+hKhV7 31bbJlot+5Qfc0GXU9VVg/DoivVzbWeXCux/+fjbnMwMvdOBGqZrzC60yQgsT81XRMLK KNHP5P+7YOWNSkxSDpF+rAt4TwTWabzdbwMtq5DIWBM9YO4iZt8vvcdpi0hg8aOyQtnO zt6g== X-Gm-Message-State: ALQs6tCE5i+PFfG4yNGCFQr2fmH5/2IaS5Fx1jvpuEDOeF6HAbeDdDEu ukdLjofn4oNiaNTVcXpn8xsGRg== X-Google-Smtp-Source: AIpwx4/azXGu4eFINhaylxUH9nEK0XWEQaaeq7oVqz3YjKQ6lN1MQAZYI5AkY5+h3VWAZYGBkRTMDw== X-Received: by 10.80.143.101 with SMTP id 92mr19166781edy.287.1524323660303; Sat, 21 Apr 2018 08:14:20 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id h30sm2618213edh.73.2018.04.21.08.14.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Apr 2018 08:14:19 -0700 (PDT) To: "json@ietf.org" From: Anders Rundgren Message-ID: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> Date: Sat, 21 Apr 2018 17:14:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 15:14:24 -0000 One might believe that JSON is a done deal but if you scratch a bit on the surface it seems that this is not the case. The root of the problem is that JSON offers a very limited set of data types, poorly matching applications. The most problematic data type is the Number type which currently is {ab}used in various ways. The Open API/JSON Scheme folks claim that Number should be used for everything that smells like a number including BigInteger, while Microsoft in their .NET implementation serializes a BigInteger as: "myBigInteger":{"_bits":[1156841472,1164153218],"_sign":1}.  Other implementations use everything from Base64-encoding to simply putting such numbers within quotes. The same issue is valid for the monetary (decimal) data type which in payment-related standards like Open Banking in the UK and the W3C PaymentRequest is expressed as a JSON String "nnnnn.nnn", but in Open API/JSON Schema as a JSON Number. That is, for anything beyond what you can do natively in JavaScript, JSON offers close to ZERO interoperability. I-JSON [https://tools.ietf.org/html/rfc7493] was a good start but it seems that there is more to do or is the general feeling that it is better to slowly deprecate JSON in favor of CBOR [https://tools.ietf.org/html/rfc7049] and/or Protocol Buffers [https://developers.google.com/protocol-buffers/] ? Personally, I don't see any fundamental issue using JSON since you can map any data type to the String type.  This is way more flexible than defining hordes of discrete data types (aka "Fixing JSON"). Mapping can be performed programmatically like obj.getBigInteger("myBigInteger") or through declarative schemes. However, without defined mapping schemes you don't get that far. WDYT? //anders From nobody Sat Apr 21 09:14:46 2018 Return-Path: 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 A1DC712D574 for ; Sat, 21 Apr 2018 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 KSc4hV-OMg1B for ; Sat, 21 Apr 2018 09:14:42 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B012124F57 for ; Sat, 21 Apr 2018 09:14:41 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id f14-v6so30237765wre.4 for ; Sat, 21 Apr 2018 09:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6DmytZ86f7FrGODs8dn/a0c2PfjA/juPYe7J8JqJa7o=; b=xw7fBxcEDrVT4InADF4cYqKDNKVy/6Srsh/NsRUzFu8cRFKes9VzYhfHr60mwje3W+ a65y4jPA4k8vg7McIX17anDu4DIf6DCNCq4gS3CRSCtpr0uohmx5wTwuxOIrTDNRBdVn MRCaQbS7XexWWGD6tSEIQ+bQOoWo2x9VRe9S8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6DmytZ86f7FrGODs8dn/a0c2PfjA/juPYe7J8JqJa7o=; b=njHPXCDkk71tzgJrkOiOjraBrL3l5pRBG7VRfhZ1lSpexJqOay4IHtmcggacDw04zs T9D129Ljx3Xv9tV2q0cUdrl8cYFDoz1xJpd6mcuoFNRMO1XtKtUEXo/FDTAWuEDNApnO BEqfzfQlqYlpKdztK40kPl8hn60GznlkfkFkra7PLejmYOJlIpDlHq7GxWBr9DyP/oFN Q/y0uD7Acic67qaQHU31Pg8yVktd4zocOvsZKIFQDy7krChiTdgZNtbFSDuB3F1k5yct Namlj+qjW3g16n4nSrzg0ghvBADr270rzIAqb3WLlCNGP5MMxPslz+2n3nBdKY8q3sV5 bohw== X-Gm-Message-State: ALQs6tCyasM9fZqj6iZcz8LyZBxYnzAk4QTIXqZX9tWaz4N6+D4z2VWc Hsa9ORIL+pKEv3eqvBE5L9jL5zuL5mObFZitxssJwQ== X-Google-Smtp-Source: AIpwx4/8BER/ThQhp7snEWPuViJBudn7f4LBVDHbBkgYZ3SzhVf2zsWa6E1mW90VtNNVnfnTgIyQzoNwUUTayo/pF9Q= X-Received: by 10.28.20.140 with SMTP id 134mr4373269wmu.87.1524327280007; Sat, 21 Apr 2018 09:14:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.198.79 with HTTP; Sat, 21 Apr 2018 09:14:19 -0700 (PDT) In-Reply-To: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> From: Henry Andrews Date: Sat, 21 Apr 2018 09:14:19 -0700 Message-ID: To: Anders Rundgren Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary="001a1145b0720bf836056a5e1af4" Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 16:14:45 -0000 --001a1145b0720bf836056a5e1af4 Content-Type: text/plain; charset="UTF-8" The JSON Schema project says no such thing. JSON Schema says that if you want to define a sort of number that is *allowed by the JSON specification* but not interoperable by whatever definition of "interoperable" for whatever reason, then that is an ambiguity inherited from JSON and we will not exclude it from JSON Schema. We do, however, provide many tools for constraining JSON numbers or numbers-as-strings within an interoperable subset. I have been asking (including in conversations on issues you filed) for someone to contribute PRs on numeric / numbers-as-strings formats, but neither you nor anoyone else has stepped up. Here is an example where I last asked for contributions in September 2017: https://github.com/json-schema-org/json-schema-spec/issues/361 I am aware that you are unhappy with our response to your issue, but please do not blame JSON Schema for JSON's ambiguities, or for other people happening to use ambiguous values while they also happen to use JSON Schema. We help people describe how they want to use JSON. We don't force them to use it in a particular way. If want to avoid such values, it is entirely possible to write a JSON Schema to filter them out, and would be more possible if anyone understanding the concerns here were willing to submit a PR to define better values for "format". thanks, -henry On Sat, Apr 21, 2018 at 8:14 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > One might believe that JSON is a done deal but if you scratch a bit on the > surface it seems that this is not the case. > > The root of the problem is that JSON offers a very limited set of data > types, poorly matching applications. > The most problematic data type is the Number type which currently is > {ab}used in various ways. > > The Open API/JSON Scheme folks claim that Number should be used for > everything that smells like a number including BigInteger, while Microsoft > in their .NET implementation serializes a BigInteger as: > "myBigInteger":{"_bits":[1156841472,1164153218],"_sign":1}. Other > implementations use everything from Base64-encoding to simply putting such > numbers within quotes. > > The same issue is valid for the monetary (decimal) data type which in > payment-related standards like Open Banking in the UK and the W3C > PaymentRequest is expressed as a JSON String "nnnnn.nnn", but in Open > API/JSON Schema as a JSON Number. > > That is, for anything beyond what you can do natively in JavaScript, JSON > offers close to ZERO interoperability. > > I-JSON [https://tools.ietf.org/html/rfc7493] was a good start but it > seems that there is more to do or is the general feeling that it is better > to slowly deprecate JSON in favor of CBOR [https://tools.ietf.org/html/r > fc7049] and/or Protocol Buffers [https://developers.google.com > /protocol-buffers/] ? > > Personally, I don't see any fundamental issue using JSON since you can map > any data type to the String type. This is way more flexible than defining > hordes of discrete data types (aka "Fixing JSON"). Mapping can be performed > programmatically like obj.getBigInteger("myBigInteger") or through > declarative schemes. However, without defined mapping schemes you don't get > that far. > > WDYT? > > //anders > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --001a1145b0720bf836056a5e1af4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The JSON Schema project says no such t= hing.=C2=A0 JSON Schema says that if you want to define a sort of number th= at is *allowed by the JSON specification* but not interoperable by whatever= definition of "interoperable" for whatever reason, then that is = an ambiguity inherited from JSON and we will not exclude it from JSON Schem= a.

We do, however, provide many tools for constraining JSON nu= mbers or numbers-as-strings within an interoperable subset.=C2=A0 I have be= en asking (including in conversations on issues you filed) for someone to c= ontribute PRs on numeric / numbers-as-strings formats, but neither you nor = anoyone else has stepped up.=C2=A0 Here is an example where I last asked fo= r contributions in September 2017: https://github.com/json-schema-org/json-= schema-spec/issues/361

I am aware that you are unhappy wit= h our response to your issue, but please do not blame JSON Schema for JSON&= #39;s ambiguities, or for other people happening to use ambiguous values wh= ile they also happen to use JSON Schema.=C2=A0 We help people describe how = they want to use JSON.=C2=A0 We don't force them to use it in a particu= lar way.=C2=A0 If want to avoid such values, it is entirely possible to wri= te a JSON Schema to filter them out, and would be more possible if anyone u= nderstanding the concerns here were willing to submit a PR to define better= values for "format".

thanks,
-henry



=
On Sat, Apr 21, 2018 at 8:14 AM, Anders Rund= gren <anders.rundgren.net@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">One might believe that JSON is a done deal bu= t if you scratch a bit on the surface it seems that this is not the case.
The root of the problem is that JSON offers a very limited set of data type= s, poorly matching applications.
The most problematic data type is the Number type which currently is {ab}us= ed in various ways.

The Open API/JSON Scheme folks claim that Number should be used for everyth= ing that smells like a number including BigInteger, while Microsoft in thei= r .NET implementation serializes a BigInteger as: "myBigInteger":= {"_bits":[1156841472,1164153218],"_sign":1}.=C2=A0= Other implementations use everything from Base64-encoding to simply puttin= g such numbers within quotes.

The same issue is valid for the monetary (decimal) data type which in payme= nt-related standards like Open Banking in the UK and the W3C PaymentRequest= is expressed as a JSON String "nnnnn.nnn", but in Open API/JSON = Schema as a JSON Number.

That is, for anything beyond what you can do natively in JavaScript, JSON o= ffers close to ZERO interoperability.

I-JSON [https://tools.ietf.org/html/rfc7493] was a good = start but it seems that there is more to do or is the general feeling that = it is better to slowly deprecate JSON in favor of CBOR [https://t= ools.ietf.org/html/rfc7049] and/or Protocol Buffers [https://developers.google.com/protocol-buffers/] ?

Personally, I don't see any fundamental issue using JSON since you can = map any data type to the String type.=C2=A0 This is way more flexible than = defining hordes of discrete data types (aka "Fixing JSON"). Mappi= ng can be performed programmatically like obj.getBigInteger("myBigInte= ger") or through declarative schemes. However, without defined ma= pping schemes you don't get that far.

WDYT?

//anders


_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json



--
=
--001a1145b0720bf836056a5e1af4-- From nobody Sat Apr 21 09:35:45 2018 Return-Path: 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 0FC39129C53 for ; Sat, 21 Apr 2018 09:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rStLulaPiX1l for ; Sat, 21 Apr 2018 09:35:41 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3452A124F57 for ; Sat, 21 Apr 2018 09:35:41 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id p18-v6so11137893wrm.1 for ; Sat, 21 Apr 2018 09:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=T6nhICLlVCrPB/nqqgdpkOMMaDZC+pPH18Ms06rbWgQ=; b=Kv9wil1A/Q9ClwhpZ45CernsrA8s8Joukc7eJsFroIuudRqasTEk6pw88zQHHa5NAi Y6xoDzqqBHk1ZkNbeeEsLbcMMD+kFHPZzQytHa2anP6ZbdGD2SzddswsKsmWjT545jzL airzJE+qh19GXlN/QwYLAxd6+udOMmEtLrflhaSucQDAXuWpZIfaJexZDMvgXU4faZpi 4TO1B6iC0FdTfGDqyk3ErIRO9G7PHQEK5YrYI7H9ACx0QtYpTSedvp22aDzeg4IBPOzK GACklcrbXMDoo15/XThVSCKE7SzhKf26yOxZbQ52p5b8Y3CUiQI6BmcVPFGfN53fAk3P fQiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T6nhICLlVCrPB/nqqgdpkOMMaDZC+pPH18Ms06rbWgQ=; b=ocLchjTFPMiO9QtCe8LZH3RzIPBhkg6Hz2jrFPA9VapICgc0bnuGrBPqrR7T7IXudv GhtxlgziWH9VNnTe6gjbUFy59S4WtOYlLzzfD3ca9g/Xpfwq/WIE0QGNZFLwPmypkXKu Wwg5Etnch4fSf6MRjoRNGRCuenXo1BTwXUd/dhbwDhDTRvtReA7aMYDxYEmkEqmkWaTc Yz4tRw/7KXXaNlkn6yZ6GjAqI8h/WFtsGSzO4XchynoH1zKWT0dScxSTdKgS3Mmx/AaL T4u9Ro3G87eaPLfIg2GCRGhxCKFpIzhjR/p8areLg6br7HhrdETpkgt2YHUbI8p7JWJC oYRw== X-Gm-Message-State: ALQs6tDY/mtoBRiUAA2US/dxJ2/KnLUJkbOSqfqK76qehkzkc6Zx8q2k JGCe/LijVb5iSamPSD2qRpdM6g== X-Google-Smtp-Source: AIpwx493Ta0PCfCvYjJmHDRfcTNxPfIUh360c/TOFVvhR6xaGy5DzpPKPPBBxigV0W/lJVEsO96EcA== X-Received: by 10.167.208.210 with SMTP id u18mr4676401edo.97.1524328539270; Sat, 21 Apr 2018 09:35:39 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id x18sm4879822edi.58.2018.04.21.09.35.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Apr 2018 09:35:38 -0700 (PDT) To: Henry Andrews Cc: "json@ietf.org" References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> From: Anders Rundgren Message-ID: Date: Sat, 21 Apr 2018 18:35:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 16:35:44 -0000 Dear Henry, As seen by the .NET example I'm pointing to a rather generic problem. I don't know who "owns" it. json@ietf.org may be an appropriate venue for discussing how this could/should be addressed. Ideally that should also involve people designing declarative schemes based on "decorating" data objects like in .NET. For the monetary (decimal) data type there are already some standards out there that on their own seem have come to the same conclusion including the W3C: https://www.w3.org/TR/payment-request/#paymentcurrencyamount-dictionary Thanx, Anders On 2018-04-21 18:14, Henry Andrews wrote: > The JSON Schema project says no such thing.  JSON Schema says that if you want to define a sort of number that is *allowed by the JSON specification* but not interoperable by whatever definition of "interoperable" for whatever reason, then that is an ambiguity inherited from JSON and we will not exclude it from JSON Schema. > > We do, however, provide many tools for constraining JSON numbers or numbers-as-strings within an interoperable subset.  I have been asking (including in conversations on issues you filed) for someone to contribute PRs on numeric / numbers-as-strings formats, but neither you nor anoyone else has stepped up.  Here is an example where I last asked for contributions in September 2017: https://github.com/json-schema-org/json-schema-spec/issues/361 > > I am aware that you are unhappy with our response to your issue, but please do not blame JSON Schema for JSON's ambiguities, or for other people happening to use ambiguous values while they also happen to use JSON Schema.  We help people describe how they want to use JSON.  We don't force them to use it in a particular way.  If want to avoid such values, it is entirely possible to write a JSON Schema to filter them out, and would be more possible if anyone understanding the concerns here were willing to submit a PR to define better values for "format". > > thanks, > -henry > > > > > On Sat, Apr 21, 2018 at 8:14 AM, Anders Rundgren > wrote: > > One might believe that JSON is a done deal but if you scratch a bit on the surface it seems that this is not the case. > > The root of the problem is that JSON offers a very limited set of data types, poorly matching applications. > The most problematic data type is the Number type which currently is {ab}used in various ways. > > The Open API/JSON Scheme folks claim that Number should be used for everything that smells like a number including BigInteger, while Microsoft in their .NET implementation serializes a BigInteger as: "myBigInteger":{"_bits":[1156841472,1164153218],"_sign":1}.  Other implementations use everything from Base64-encoding to simply putting such numbers within quotes. > > The same issue is valid for the monetary (decimal) data type which in payment-related standards like Open Banking in the UK and the W3C PaymentRequest is expressed as a JSON String "nnnnn.nnn", but in Open API/JSON Schema as a JSON Number. > > That is, for anything beyond what you can do natively in JavaScript, JSON offers close to ZERO interoperability. > > I-JSON [https://tools.ietf.org/html/rfc7493 ] was a good start but it seems that there is more to do or is the general feeling that it is better to slowly deprecate JSON in favor of CBOR [https://tools.ietf.org/html/rfc7049 ] and/or Protocol Buffers [https://developers.google.com/protocol-buffers/ ] ? > > Personally, I don't see any fundamental issue using JSON since you can map any data type to the String type.  This is way more flexible than defining hordes of discrete data types (aka "Fixing JSON"). Mapping can be performed programmatically like obj.getBigInteger("myBigInteger") or through declarative schemes. However, without defined mapping schemes you don't get that far. > > WDYT? > > //anders > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > > -- > > * > | > > *Henry Andrews*  |  Systems Engineer > henry@cloudflare.com > > > > 1 888 99 FLARE  | www.cloudflare.com > > | > * > From nobody Sat Apr 21 11:22:12 2018 Return-Path: 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 BCDC112E886 for ; Sat, 21 Apr 2018 11:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 1mVZWdnzQ2Ox for ; Sat, 21 Apr 2018 11:22:09 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA4412D869 for ; Sat, 21 Apr 2018 11:22:08 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id h3-v6so30709835wrh.5 for ; Sat, 21 Apr 2018 11:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SgoyCeJbQlVAKDIhuixqMFTwSv0o8KYbC7xy0mNmMXQ=; b=YLsKEVNv/n5Cg/YdIKNr6vtwEScr8JqE1IhEtO9aOR1x+Z1icNlrQge3hJbjVldV9L WJYOqYdxNUHNiegw0XP3Tu/ZjGY1FBuzPhQnG1+PLGxy+EIBFX9iSouh+YS/9HYq2nWR l5aGtTjHThwwtTMJDdohD0L466HtT16tAjk8k8MXbGLwyD/ZqK6sMiBM8+gpve0//lTZ NVRdrPeV+4tZzrNVyC00M+j5VefSvHBzWEW+m2NT0+RcF3Hva3whnO3c3cCixhu8Tapa 0zbGSvnFHbYgRrVk8tV+3KsS1vOOmAxP54Lm6ABQ6ElgBTCdmCdAas5EfX1HzscjBSQm wkJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SgoyCeJbQlVAKDIhuixqMFTwSv0o8KYbC7xy0mNmMXQ=; b=WIAZe1MDh/yZrl9tvqqAXao+dSJc016n7DYezBH36k5xJvegUNIhI/MSr6o6GmFf3N IoVcQAbMqGbWN/lanazFMYlHa/RIqD/fiXrRWhQhSVrN6GEpRvQyyPm4j8WIBWDMZZWA FEC6s2U/5/G/+n6pEhEHeLxqB5mPich+XR33CDD6komx0fcc7+4XDcWc9v51XJo0a8XB jtrFWiiUYcqZPAQgOmdLgfOtIn/KpOjyf6DL0W8YAl7UFFv4r2m1XtIHifdAq5hAg1jD 9prrf4DhOGcG8lUqMR1n0jGxhntSfW4RmAUEQTfvEhL+fAA3sE1ZhUn+Sc6MSQ5TjNHu 4lDg== X-Gm-Message-State: ALQs6tBn0yIc4Vz2AATh+lfEFe8m6alvR88qcsqfrEv51JPeJekatw1k T+11HzIIwlMycpmY/bBrerXPS3dPiLb/j378Wxq/lA== X-Google-Smtp-Source: AIpwx48SJ1fWyeC9tBcC9p8p3DEXYXWOhQDk2gEBLnIyyk5HCsm2e6cf1/FYipjTskv4S6KTvzs19Izt+kn3BU3kxS8= X-Received: by 10.80.186.67 with SMTP id 3mr20459750eds.194.1524334927238; Sat, 21 Apr 2018 11:22:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.159.206 with HTTP; Sat, 21 Apr 2018 11:21:46 -0700 (PDT) X-Originating-IP: [24.86.156.110] In-Reply-To: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> From: Tim Bray Date: Sat, 21 Apr 2018 11:21:46 -0700 Message-ID: To: Anders Rundgren Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary="f403045c4594db6cba056a5fe15d" Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 18:22:11 -0000 --f403045c4594db6cba056a5fe15d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, the story, per RFC8259, is pretty clear. JSON numbers are safely usable inside the numeric universe that's covered by IEEE 754 double-precision. Fortunately, that covers probably a large majority of all use-cases for numbers in computer programming. If you need to go outside that universe, JSON numbers don't help you. On Sat, Apr 21, 2018 at 8:14 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > One might believe that JSON is a done deal but if you scratch a bit on th= e > surface it seems that this is not the case. > > The root of the problem is that JSON offers a very limited set of data > types, poorly matching applications. > The most problematic data type is the Number type which currently is > {ab}used in various ways. > > The Open API/JSON Scheme folks claim that Number should be used for > everything that smells like a number including BigInteger, while Microsof= t > in their .NET implementation serializes a BigInteger as: > "myBigInteger":{"_bits":[1156841472,1164153218],"_sign":1}. Other > implementations use everything from Base64-encoding to simply putting suc= h > numbers within quotes. > > The same issue is valid for the monetary (decimal) data type which in > payment-related standards like Open Banking in the UK and the W3C > PaymentRequest is expressed as a JSON String "nnnnn.nnn", but in Open > API/JSON Schema as a JSON Number. > > That is, for anything beyond what you can do natively in JavaScript, JSON > offers close to ZERO interoperability. > > I-JSON [https://tools.ietf.org/html/rfc7493] was a good start but it > seems that there is more to do or is the general feeling that it is bette= r > to slowly deprecate JSON in favor of CBOR [https://tools.ietf.org/html/r > fc7049] and/or Protocol Buffers [https://developers.google.com > /protocol-buffers/] ? > > Personally, I don't see any fundamental issue using JSON since you can ma= p > any data type to the String type. This is way more flexible than definin= g > hordes of discrete data types (aka "Fixing JSON"). Mapping can be perform= ed > programmatically like obj.getBigInteger("myBigInteger") or through > declarative schemes. However, without defined mapping schemes you don't g= et > that far. > > WDYT? > > //anders > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --f403045c4594db6cba056a5fe15d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wel= l, the story, per RFC8259, is pretty clear. JSON numbers are safely usable = inside the numeric universe that's covered by IEEE 754 double-precision= .=C2=A0 Fortunately, that covers probably a large majority of all use-cases= for numbers in computer programming.=C2=A0 If you need to go outside that = universe, JSON numbers don't help you.

On Sat, Apr 21, 2018 at 8:14 AM, Ander= s Rundgren <anders.rundgren.net@gmail.com> wrote= :
One might believe that JSON is a done d= eal but if you scratch a bit on the surface it seems that this is not the c= ase.

The root of the problem is that JSON offers a very limited set of data type= s, poorly matching applications.
The most problematic data type is the Number type which currently is {ab}us= ed in various ways.

The Open API/JSON Scheme folks claim that Number should be used for everyth= ing that smells like a number including BigInteger, while Microsoft in thei= r .NET implementation serializes a BigInteger as: "myBigInteger":= {"_bits":[1156841472,1164153218],"_sign":1}.=C2=A0= Other implementations use everything from Base64-encoding to simply puttin= g such numbers within quotes.

The same issue is valid for the monetary (decimal) data type which in payme= nt-related standards like Open Banking in the UK and the W3C PaymentRequest= is expressed as a JSON String "nnnnn.nnn", but in Open API/JSON = Schema as a JSON Number.

That is, for anything beyond what you can do natively in JavaScript, JSON o= ffers close to ZERO interoperability.

I-JSON [https://tools.ietf.org/html/rfc7493] was a good = start but it seems that there is more to do or is the general feeling that = it is better to slowly deprecate JSON in favor of CBOR [https://t= ools.ietf.org/html/rfc7049] and/or Protocol Buffers [https://developers.google.com/protocol-buffers/] ?

Personally, I don't see any fundamental issue using JSON since you can = map any data type to the String type.=C2=A0 This is way more flexible than = defining hordes of discrete data types (aka "Fixing JSON"). Mappi= ng can be performed programmatically like obj.getBigInteger("myBigInte= ger") or through declarative schemes. However, without defined ma= pping schemes you don't get that far.

WDYT?

//anders


_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json



--
- Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/tim= bray)
--f403045c4594db6cba056a5fe15d-- From nobody Sat Apr 21 16:48:09 2018 Return-Path: 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 2C212127876 for ; Sat, 21 Apr 2018 16:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 vRrZ6LrL2ZeR for ; Sat, 21 Apr 2018 16:48:04 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26B8124D37 for ; Sat, 21 Apr 2018 16:48:03 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id d1-v6so31625103wrj.13 for ; Sat, 21 Apr 2018 16:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dAUdutmPy/olFhly9JXaCyy2ktqrxxkgaLgYztcQEJA=; b=OdN8sktS3iPjr+yXZm57Xqb7hOo6kvdrd8rmXNDd635ao9QVHMdUrl60nwI9Hifnqo JHY00jFmLXMNrmnPmMh9h6TZGLOxmG/yqxiAX2Cej1K4JbQmKvkzQa3b0Pm+/7vEO6nR Lbr/PaUKe5iupWV1iu931Bl1J4c/ywzbFL54M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dAUdutmPy/olFhly9JXaCyy2ktqrxxkgaLgYztcQEJA=; b=YIIbCMgouNZRFfxiGLD9w6YEQ73U5Gs7jCA1akYfa5ZypNXq/TuyBb7irJIFt2r3nm 2NdCySy3rovG+7D4CZ9kzwRDEp7+u5ScacJcmyZ3WjNmPa3EfeKJT1GZAPf9IzNqJgiN IZZp8V/1+/Vi0Ba+NRPYKZf+zO5AbwSpXzu7pdsUdi9gYy1tRwnlyG5IN4ypksaCgO1R reDtKCcynPDrvA0OIfTYHntCaTIS2bvsM1qCCE1cj3SlFjblzPoVIUApsU74jaM5p5zk +7vmEp+EkAZ3ZG5q3fKgv6tk1L7IrLLrDw9/wJfhkjYT+vmd1pCIatb/HMHO0lb/0ZfD YQ8Q== X-Gm-Message-State: ALQs6tDX5z4kMbgqkUXjuIItc/pz0H1n9aoVLGyYMwZHYWJct2uCdG8a VTCkVz4siZIe6W+T4IuFxyWC2bQTGdtUOEGlMpVJvw== X-Google-Smtp-Source: AIpwx49gh6ZrFCcjKDqNKTwQmuu6I+WHtAXTgW7R5ilc1+g/bEC/GHhKAWAk4Q+vZVi96nndxYR+4VugrrtMYJArR/Q= X-Received: by 10.28.239.1 with SMTP id n1mr5274881wmh.137.1524354482042; Sat, 21 Apr 2018 16:48:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.198.79 with HTTP; Sat, 21 Apr 2018 16:47:41 -0700 (PDT) In-Reply-To: References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> From: Henry Andrews Date: Sat, 21 Apr 2018 16:47:41 -0700 Message-ID: To: Tim Bray Cc: Anders Rundgren , "json@ietf.org" Content-Type: multipart/alternative; boundary="089e082feaa46a19e8056a646fa0" Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2018 23:48:07 -0000 --089e082feaa46a19e8056a646fa0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Indeed. I'm not sure where the "JSON Schema and OpenAPI claim that..." comes from. OpenAPI has an int64 format, presumably because someone has a use for it. I assume it's interoperable enough for that use case, but it does not magically extend JSON's interoperable numeric range. No one is being forced to use that format, though. The outcome of those discussions was that neither JSON Schema (which does not define an int64 format, but does not forbid adding one) nor OpenAPI thought it necessary to forbid such a construct since clearly someone was getting some use out of it. That's all. There's nothing preventing anyone who is using OpenAPI or JSON Schema from simply... not using that format. Or defining a format that encodes very large numbers in JSON Strings. As noted, we're open to improving support for string-encoded numbers on the JSON Schema side if someone would like to submit a PR. This is not even the only weird interoperability edge in JSON. Similar concerns would arise if someone came up with an extension keyword for JSON Schema to describe objects with multiple properties of the same name. This is allowed by RFC 8259, which also notes that behavior of software which encounters such objects is unpredictable. I would personally not put such a keyword into JSON Schema as it would be confusing for many, but if a project (OpenAPI or otherwise) wanted to add one because it works for them... it's allowed by RFC 8259 and it's not the responsibility of the schema system to prevent it. thanks, -henry On Sat, Apr 21, 2018 at 11:21 AM, Tim Bray wrote: > Well, the story, per RFC8259, is pretty clear. JSON numbers are safely > usable inside the numeric universe that's covered by IEEE 754 > double-precision.. Fortunately, that covers probably a large majority of > all use-cases for numbers in computer programming. If you need to go > outside that universe, JSON numbers don't help you. > > On Sat, Apr 21, 2018 at 8:14 AM, Anders Rundgren < > anders.rundgren.net@gmail.com> wrote: > >> One might believe that JSON is a done deal but if you scratch a bit on >> the surface it seems that this is not the case. >> >> The root of the problem is that JSON offers a very limited set of data >> types, poorly matching applications. >> The most problematic data type is the Number type which currently is >> {ab}used in various ways. >> >> The Open API/JSON Scheme folks claim that Number should be used for >> everything that smells like a number including BigInteger, while Microso= ft >> in their .NET implementation serializes a BigInteger as: >> "myBigInteger":{"_bits":[1156841472,1164153218],"_sign":1}. Other >> implementations use everything from Base64-encoding to simply putting su= ch >> numbers within quotes. >> >> The same issue is valid for the monetary (decimal) data type which in >> payment-related standards like Open Banking in the UK and the W3C >> PaymentRequest is expressed as a JSON String "nnnnn.nnn", but in Open >> API/JSON Schema as a JSON Number. >> >> That is, for anything beyond what you can do natively in JavaScript, JSO= N >> offers close to ZERO interoperability. >> >> I-JSON [https://tools.ietf.org/html/rfc7493] was a good start but it >> seems that there is more to do or is the general feeling that it is bett= er >> to slowly deprecate JSON in favor of CBOR [https://tools.ietf.org/html/r >> fc7049] and/or Protocol Buffers [https://developers.google.com >> /protocol-buffers/] ? >> >> Personally, I don't see any fundamental issue using JSON since you can >> map any data type to the String type. This is way more flexible than >> defining hordes of discrete data types (aka "Fixing JSON"). Mapping can = be >> performed programmatically like obj.getBigInteger("myBigInteger") or >> through declarative schemes. However, without defined mapping schemes yo= u >> don't get that far. >> >> WDYT? >> >> //anders >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --=20 - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --089e082feaa46a19e8056a646fa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Indeed.=C2=A0 I'm not sure where the &q= uot;JSON Schema and OpenAPI claim that..." comes from.=C2=A0 OpenAPI h= as an int64 format, presumably because someone has a use for it.=C2=A0 I as= sume it's interoperable enough for that use case, but it does not magic= ally extend JSON's interoperable numeric range.=C2=A0 No one is being f= orced to use that format, though.

The outcome of those di= scussions was that neither JSON Schema (which does not define an int64 form= at, but does not forbid adding one) nor OpenAPI thought it necessary to for= bid such a construct since clearly someone was getting some use out of it.= =C2=A0 That's all.=C2=A0 There's nothing preventing anyone who is u= sing OpenAPI or JSON Schema from simply... not using that format.=C2=A0 Or = defining a format that encodes very large numbers in JSON Strings.=C2=A0 As= noted, we're open to improving support for string-encoded numbers on t= he JSON Schema side if someone would like to submit a PR.

This= is not even the only weird interoperability edge in JSON.=C2=A0 Similar co= ncerns would arise if someone came up with an extension keyword for JSON Sc= hema to describe objects with multiple properties of the same name. This is= allowed by RFC 8259, which also notes that behavior of software which enco= unters such objects is unpredictable.=C2=A0 I would personally not put such= a keyword into JSON Schema as it would be confusing for many, but if a pro= ject (OpenAPI or otherwise) wanted to add one because it works for them... = it's allowed by RFC 8259 and it's not the responsibility of the sch= ema system to prevent it.

thanks,
-henry


On Sat, Apr 21, = 2018 at 11:21 AM, Tim Bray <tbray@textuality.com> wrote:<= br>
Well, the story, per RFC8259, is pretty clea= r. JSON numbers are safely usable inside the numeric universe that's co= vered by IEEE 754 double-precision..=C2=A0 Fortunately, that covers probabl= y a large majority of all use-cases for numbers in computer programming.=C2= =A0 If you need to go outside that universe, JSON numbers don't help yo= u.

On = Sat, Apr 21, 2018 at 8:14 AM, Anders Rundgren <anders.rundgren= .net@gmail.com> wrote:
One might believe that JSON is a done deal but if you scratch a bit on the= surface it seems that this is not the case.

The root of the problem is that JSON offers a very limited set of data type= s, poorly matching applications.
The most problematic data type is the Number type which currently is {ab}us= ed in various ways.

The Open API/JSON Scheme folks claim that Number should be used for everyth= ing that smells like a number including BigInteger, while Microsoft in thei= r .NET implementation serializes a BigInteger as: "myBigInteger":= {"_bits":[1156841472,1164153218],"_sign":1}.=C2=A0= Other implementations use everything from Base64-encoding to simply puttin= g such numbers within quotes.

The same issue is valid for the monetary (decimal) data type which in payme= nt-related standards like Open Banking in the UK and the W3C PaymentRequest= is expressed as a JSON String "nnnnn.nnn", but in Open API/JSON = Schema as a JSON Number.

That is, for anything beyond what you can do natively in JavaScript, JSON o= ffers close to ZERO interoperability.

I-JSON [https://tools.ietf.org/html/rfc7493] was a good = start but it seems that there is more to do or is the general feeling that = it is better to slowly deprecate JSON in favor of CBOR [https://t= ools.ietf.org/html/rfc7049] and/or Protocol Buffers [https://developers.google.com/protocol-buffers/] ?

Personally, I don't see any fundamental issue using JSON since you can = map any data type to the String type.=C2=A0 This is way more flexible than = defining hordes of discrete data types (aka "Fixing JSON"). Mappi= ng can be performed programmatically like obj.getBigInteger("myBigInte= ger") or through declarative schemes. However, without defined ma= pping schemes you don't get that far.

WDYT?

//anders


_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json



--
- Tim Bray (If you=E2=80=99d like to send me a private message, se= e https://keybase.= io/timbray)

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json




--
--089e082feaa46a19e8056a646fa0-- From nobody Sat Apr 21 22:08:06 2018 Return-Path: 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 AED7C12783A for ; Sat, 21 Apr 2018 22:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWtzCOY7krns for ; Sat, 21 Apr 2018 22:08:03 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22012124BFA for ; Sat, 21 Apr 2018 22:08:03 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id f14-v6so32454923wre.4 for ; Sat, 21 Apr 2018 22:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sHL8JbwO1rsYGJGKGfV3L82n3wN1WtAuI0edExOo+j4=; b=qvnyl6swoGSaEJr1tHQiY4bC8DM8PBcHvYRgbY3tVuQ+NP6TMKP9+gBlJaD3lEFCNG 2zD/fv/oLMsRtyZrLIg/Uj1JcrtOvekbnzoQAzIFUbHtASNIOfdfwB9MIINSBoKCdyzO peVx6ReKphGkwam4D8EO66/U7u4rRaZlIutdvsET3CacFjjkM7qKk4iOxbANKqIawvhe z9iEGbh6j6XJK5LjeyVkT4fTjX/uXQ6NPmEfo2XY7Gh5qsNiWrovYYWYIaYYwtHg+o7J FSTtBEiA0J29ZVejSrJiejKCnG8XBLypcZSimSEjpbLs7ZR4OJp2puBhxYKXMaZA7B6x jW+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sHL8JbwO1rsYGJGKGfV3L82n3wN1WtAuI0edExOo+j4=; b=UeDdOs0g6K83RV2CuLivE1oRC6/zDjdaYbujFcELneJd0T+KKoR5ejmMytGOAw6/yA ZZ2VtMMNfFe25ZR3GjYc3HaMZjYte6gC5jnqafZmmxAkiaXf3yNL1lV0sKyO9GrSsRC7 snr7vJGV9KgqMI+zT96QELjaGqNwsPE+QBvjR1YlSNwtP8xkAeIW1omhTRFkL+ina8HS RuPUQ7AYThLlNjaAOy0w+sAY7Y+jOLnUv3ruebdnoDiXm6KJO2DfbZ7Rgc3WJb9H+G+U AHA0ZJgNp91haV9mMnqsuKXIUZ1jnoU03PUztLu4KZmugvuKX/KcgXBTk9dOlGhglweO btZg== X-Gm-Message-State: ALQs6tAsJaPvcGq6k4XCgRPt8n+zsDPGYXPQdqodWXDF+/4LAQXk2A+4 1o2yNBRUBacNbTsSY2Bm2CegSQ== X-Google-Smtp-Source: AIpwx4+rNCyAOeY4OZKbpEYMmZoCPYW4FVBzPZtEqO22DQ3hcDPHHfCA+IYZiZW8kk1Z9HQEw32xGA== X-Received: by 2002:adf:b685:: with SMTP id j5-v6mr13491473wre.10.1524373681298; Sat, 21 Apr 2018 22:08:01 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id b18-v6sm9610256wrb.55.2018.04.21.22.07.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Apr 2018 22:08:00 -0700 (PDT) To: Tim Bray Cc: "json@ietf.org" References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> From: Anders Rundgren Message-ID: <5d83c4b8-ae3c-14ae-79fb-25b71951f4da@gmail.com> Date: Sun, 22 Apr 2018 07:07:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 05:08:06 -0000 On 2018-04-21 20:21, Tim Bray wrote: > Well, the story, per RFC8259, is pretty clear. JSON numbers are safely usable inside the numeric universe that's covered by IEEE 754 double-precision.  Fortunately, that covers probably a large majority of all use-cases for numbers in computer programming.  If you need to go outside that universe, JSON numbers don't help you. Right, but if you need to go outside of that universe including using a "long" integer, you'll find that the most implementations by default indeed ignore this limitation which BTW is neither a SHOULD nor a MUST. That is, a (for practical purposes) pretty major portion of the JSON specification have effectivaly moved into the application space. Anders > > On Sat, Apr 21, 2018 at 8:14 AM, Anders Rundgren > wrote: > > One might believe that JSON is a done deal but if you scratch a bit on the surface it seems that this is not the case. > > The root of the problem is that JSON offers a very limited set of data types, poorly matching applications. > The most problematic data type is the Number type which currently is {ab}used in various ways. > > The Open API/JSON Scheme folks claim that Number should be used for everything that smells like a number including BigInteger, while Microsoft in their .NET implementation serializes a BigInteger as: "myBigInteger":{"_bits":[1156841472,1164153218],"_sign":1}.  Other implementations use everything from Base64-encoding to simply putting such numbers within quotes. > > The same issue is valid for the monetary (decimal) data type which in payment-related standards like Open Banking in the UK and the W3C PaymentRequest is expressed as a JSON String "nnnnn.nnn", but in Open API/JSON Schema as a JSON Number. > > That is, for anything beyond what you can do natively in JavaScript, JSON offers close to ZERO interoperability. > > I-JSON [https://tools.ietf.org/html/rfc7493 ] was a good start but it seems that there is more to do or is the general feeling that it is better to slowly deprecate JSON in favor of CBOR [https://tools.ietf.org/html/rfc7049 ] and/or Protocol Buffers [https://developers.google.com/protocol-buffers/ ] ? > > Personally, I don't see any fundamental issue using JSON since you can map any data type to the String type.  This is way more flexible than defining hordes of discrete data types (aka "Fixing JSON"). Mapping can be performed programmatically like obj.getBigInteger("myBigInteger") or through declarative schemes. However, without defined mapping schemes you don't get that far. > > WDYT? > > //anders > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > > -- > - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray) From nobody Sat Apr 21 23:09:38 2018 Return-Path: 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 9C28C12711A for ; Sat, 21 Apr 2018 23:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 MlO8gdXu6zhZ for ; Sat, 21 Apr 2018 23:09:35 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 6A0EA12025C for ; Sat, 21 Apr 2018 23:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w3M69UwS011938; Sun, 22 Apr 2018 08:09:30 +0200 (CEST) Received: from [192.168.217.102] (p5DC7F793.dip0.t-ipconnect.de [93.199.247.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 40TK1Q3wkQzDXXF; Sun, 22 Apr 2018 08:09:30 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Sun, 22 Apr 2018 08:09:29 +0200 Cc: Tim Bray , "json@ietf.org" , Anders Rundgren X-Mao-Original-Outgoing-Id: 546070166.553134-d4e93d09764676f279df7f7696d82157 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> To: Henry Andrews X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 06:09:38 -0000 On Apr 22, 2018, at 01:47, Henry Andrews wrote: >=20 > objects with multiple properties of the same name. This is allowed by = RFC 8259, which also notes that behavior of software which encounters = such objects is unpredictable. It is =E2=80=9Callowed=E2=80=9D by RFC 8259 approximately as much as my = parents =E2=80=9Callowed=E2=80=9D me to jump off a bridge by telling me = that would be bad for my health. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Apr 22 03:27:29 2018 Return-Path: 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 CC4B81204DA for ; Sun, 22 Apr 2018 03:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHnDZDyzXmxF for ; Sun, 22 Apr 2018 03:27:25 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3092C1243F3 for ; Sun, 22 Apr 2018 03:27:25 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id p18-v6so14311548wrm.1 for ; Sun, 22 Apr 2018 03:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=chMUd/f7EYBGdJOB/S2J/UUTviNoy4J83BhuyCeilb4=; b=kD7VzDVfdPWSg+DiFQr3PeUyBvCKllJtJXS385DPkZbEpAi6UJJ1pmcVAnN7P/SJ2i y+/nWuYnJiGj9e8fGT1WwtdL4/bbSxxUXk0Nh7CTtMYF/hy4ijPMkS5R7A6/x+Av/Wge jB73O9nNRIhcM8THTPVbqyY5XqD663bQJOrsZ08ypeVkir7RAVNRvK2Esh6w2G8u/pKM lhE0NIrby8soi3FvBSwnFJUFBfygwC9Qy90HbaoCcnCswAP/R+yZqx30btDOGWYV6wYi jLDEXnWrvp87tIldZU25iU87e4gfrcgJ+YINu0QJhXQ2oT2e3WAxUxzrQW56mdZbAifI 0kkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=chMUd/f7EYBGdJOB/S2J/UUTviNoy4J83BhuyCeilb4=; b=VOv+vRr+fXZCxxuTs3BBzuMFJ2P057Y5wTO8oxMnoSFxmH5upTVkvOosuCYx2y08e8 G45JqyEmkYbsynTW2AVcqDkLMLh6XWiKwlQUZOKfSK50+L+DboSvitx9kd5XRf6pgFAx STI57h5zCssd3TZ6qbUsbK05riRxX1xOTQTA2rAxmvXeBKV5VbA1gGxyrRhtH6LJfUgf 9wIuSUKhNRsahxhHNOqJdqz8/1rxfr0Uukh6HsDUzEQDlV7ai5xd034fS8n3bgmfbJ6k fj4NxzZEhedOfpLIsS6TvzVUi2v/KyXBsU0NzYqD8jTfqhf5D6WuM0tGq/bxN6fmC3zt /lGQ== X-Gm-Message-State: ALQs6tBo8vhvE0x3rrpQMqPoq6ZxA5e9mXQp1dVWyAioOZwCKoWbKdZv 1L5M57JEgm+OxwvvJ+cm11I= X-Google-Smtp-Source: AIpwx489KcXUWyeTzj58j6qhC7buubXap0jUOh0TQ2n3LZTZxc5Cz/SOGTzGqv+zdF3LNhywE1RUYg== X-Received: by 10.28.230.11 with SMTP id d11mr6603337wmh.129.1524392843657; Sun, 22 Apr 2018 03:27:23 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id y9-v6sm7172648wrh.63.2018.04.22.03.27.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 03:27:22 -0700 (PDT) To: "json@ietf.org" , Henry Andrews References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> From: Anders Rundgren Message-ID: Date: Sun, 22 Apr 2018 12:27:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 10:27:28 -0000 Since the JSON Number universe outside of IEEE-754 double precision has been left to application/platform developers to deal with [*], there are currently multiple incompatible (or incomplete) "standards" out there: https://github.com/OAI/OpenAPI-Specification/issues/845#issuecomment-378139730 https://github.com/javaee/jsonb-spec/blob/master/spec/spec.pdf For .NET I haven't been able obtaining any public information on this topic, so I wrote some code in order to find out what it actually does. Maybe JSON Schema could serve a suitable place for defining a [potential] "real/de-facto" standard? To make such a process even smother, I could imagine moving http://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3 into a separate document but I haven't looked into the consequences of that. Anders *] https://www.ietf.org/mail-archive/web/json/current/msg04294.html From nobody Sun Apr 22 11:21:54 2018 Return-Path: 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 02FF7120227 for ; Sun, 22 Apr 2018 11:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 g0x9tg8odpVH for ; Sun, 22 Apr 2018 11:21:51 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFC8126D45 for ; Sun, 22 Apr 2018 11:21:49 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id v60-v6so35222768wrc.7 for ; Sun, 22 Apr 2018 11:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u+s+BUFsmm+Ru/0e1oGu1aAXkIAcB9SzTvtic0+HuU4=; b=QhUPs04jfIf54U/mU+kH7xxUC8K4ilTnkmYes8IylHg+JLyMl8Fk1jcl1MtdALVZlc 5cvnNU1O+XKx29q5Y4yDbqZRKYoNKgY7szWJnbhM/ZppoqFh9k4MkT5zvChCj9846Vnq LpJ5lJk0RLcuwJVWT/66Ism+8F/w7kzTu3b04= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u+s+BUFsmm+Ru/0e1oGu1aAXkIAcB9SzTvtic0+HuU4=; b=UTBCB5NI4quLR/up7MDlWu8roJtp4UgpACqHKFEWeOncKxQYK+XMx0mVrz8K6iR9aG Un/1NZ9ishm3zY7eF1k7zqrRPdqlqRm7anFlEOf6Tao/os0WPrHEr1i2jp+CT3DRei3b TxRWE3naxlIMBFGP8C83YqqBTr9EmbZ4j0OKKQH2uBbkzCgKP6p2+9EEM32GQoqZ2Xq2 FCKDyroMBnpbGnWmd6GHbbTf3r0HTbNLwca6SIcZQFCq8dFoTD733Oihx4AaGvoKb0jQ sjCip/U73NNkk7LkM/y7plcaxSzhSX/zNOrPbmQ0XGOmmDMxdhAsHQe4jXv7OwvjKCmx mYMg== X-Gm-Message-State: ALQs6tDhcfHqCaOvNANXt+ck7dcrAgCP3DUHsuQwAB+CACHp4cWeOtXZ ADoYi7EuNuEviE7SGc59cs1MqsBWXLIRK0HyL1kQ/A== X-Google-Smtp-Source: AIpwx492YZNFS57EruTtddvMKCttL1tvjxN99H2lrcfUXMS++OpZ2wdeY2NrIIJPsq24vpR2rmoGjjDDKex/yJejrUQ= X-Received: by 2002:adf:b71a:: with SMTP id l26-v6mr15343728wre.115.1524421308402; Sun, 22 Apr 2018 11:21:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.198.79 with HTTP; Sun, 22 Apr 2018 11:21:27 -0700 (PDT) In-Reply-To: References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> From: Henry Andrews Date: Sun, 22 Apr 2018 11:21:27 -0700 Message-ID: To: Anders Rundgren Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary="000000000000936889056a73fe98" Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2018 18:21:54 -0000 --000000000000936889056a73fe98 Content-Type: text/plain; charset="UTF-8" JSON Schema provides tools to describe how people use JSON documents, including imposing structural constraints. While you could write a schema describing the subset of JSON that you wish to use as your "standard", that would be a *use* of JSON Schema, not *part* of JSON Schema. Anders, you seem to want JSON Schema to prevent people from using things that are technically allowed by the spec (as Carsten noted, "allowed" in the sense that no one will stop you, not in the sense that any reasonable person would expect a positive outcome). That is not what JSON Schema, *as a project*, is for. You are more than welcome to use JSON Schema in your own project to advocate for a more interoperable subset of JSON. The section of JSON Schema's validation specification that you reference, about the values for "format", has gotten some discussion around how to manage larger extensibility question such as defining a registry. The issue for that discussion is https://github.com/json-schema-org/json-schema-spec/issues/563 Furthermore, this email list is not the right forum for discussing changes to JSON Schema. This group has previously made it pretty clear that they are at most interested in JSON Schema as one of many possible starting points for a new effort, rather than developing JSON Schema itself into a standards track RFC. I have no objection to that- the IETF is welcome to use or not use our work in whatever way makes sense. I've never gotten anything to RFC myself, and wouldn't presume to know all of the considerations involved. I'll be happy to support anyone who wants to use any JSON Schema ideas in a new effort, but if we're talking about JSON Schema as it is, that's better done through our repo or slack channel. thanks, -henry henry@cloudflare.com andrews_henry@yahoo.com On Sun, Apr 22, 2018 at 3:27 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > Since the JSON Number universe outside of IEEE-754 double precision has > been left to application/platform developers to deal with [*], there are > currently multiple incompatible (or incomplete) "standards" out there: > https://github.com/OAI/OpenAPI-Specification/issues/845# > issuecomment-378139730 > https://github.com/javaee/jsonb-spec/blob/master/spec/spec.pdf > > For .NET I haven't been able obtaining any public information on this > topic, so I wrote some code in order to find out what it actually does. > > Maybe JSON Schema could serve a suitable place for defining a [potential] > "real/de-facto" standard? > > To make such a process even smother, I could imagine moving > http://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3 > into a separate document but I haven't looked into the consequences of that. > > Anders > > *] https://www.ietf.org/mail-archive/web/json/current/msg04294.html > -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --000000000000936889056a73fe98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
JSON Schema provides tools to describe= how people use JSON documents, including imposing structural constraints.= =C2=A0 While you could write a schema describing the subset of JSON that yo= u wish to use as your "standard", that would be a *use* of JSON S= chema, not *part* of JSON Schema.

Anders, you seem to want JSON Sche= ma to prevent people from using things that are technically allowed by the = spec (as Carsten noted, "allowed" in the sense that no one will s= top you, not in the sense that any reasonable person would expect a positiv= e outcome).=C2=A0 That is not what JSON Schema, *as a project*, is for.=C2= =A0 You are more than welcome to use JSON Schema in your own project to adv= ocate for a more interoperable subset of JSON.

The sectio= n of JSON Schema's validation specification that you reference, about t= he values for "format", has gotten some discussion around how to = manage larger extensibility question such as defining a registry.=C2=A0 The= issue for that discussion is https://github.com/json-schema-org/json-schem= a-spec/issues/563
=C2=A0
Furthermore, this email list is no= t the right forum for discussing changes to JSON Schema.=C2=A0 This group h= as previously made it pretty clear that they are at most interested in JSON= Schema as one of many possible starting points for a new effort, rather th= an developing JSON Schema itself into a standards track RFC.=C2=A0 I have n= o objection to that- the IETF is welcome to use or not use our work in what= ever way makes sense.=C2=A0 I've never gotten anything to RFC myself, a= nd wouldn't presume to know all of the considerations involved.=C2=A0 I= 'll be happy to support anyone who wants to use any JSON Schema ideas i= n a new effort, but if we're talking about JSON Schema as it is, that&#= 39;s better done through our repo or slack channel.

thanks,
-henry

a= ndrews_henry@yahoo.com


On Sun, Apr 22, 2018 at 3:27 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
Since the JSON Number universe outside of IEEE-754 d= ouble precision has been left to application/platform developers to deal wi= th [*], there are currently multiple incompatible (or incomplete) "sta= ndards" out there:
https://github.com/OAI= /OpenAPI-Specification/issues/845#issuecomment-378139730
https://github.com/javaee/jsonb-s= pec/blob/master/spec/spec.pdf

For .NET I haven't been able obtaining any public information on this t= opic, so I wrote some code in order to find out what it actually does.

Maybe JSON Schema could serve a suitable place for defining a [potential] &= quot;real/de-facto" standard?

To make such a process even smother, I could imagine moving http://json-schema.org/latest/json-s= chema-validation.html#rfc.section.7.3 into a separate document but= I haven't looked into the consequences of that.

Anders

*] https://www.ietf.org/mail-archive/web/json/current/msg04294.html



--
=
--000000000000936889056a73fe98-- From nobody Sun Apr 22 23:25:36 2018 Return-Path: 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 6188F124BFA for ; Sun, 22 Apr 2018 23:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 i5tD0fC3b94R for ; Sun, 22 Apr 2018 23:25:33 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300E71270AB for ; Sun, 22 Apr 2018 23:25:33 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id h3-v6so37795473wrh.5 for ; Sun, 22 Apr 2018 23:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cifOJygfz0/AC6MdnJVobasC2TZjbd3yTSgOSe14704=; b=tuI5MdCAg3gC/jdfZGmWTYzuDjX+OdLwYCoX2hj/5EKibYGqkym2/yzbmHzPlJtuK+ 73pHMBCleuLacKZkW3k5uWUdumtornPMawSYtgKNe5Ese5hRuD/ywcF6p3xhcE+4rtgi FQong5JVD1nipo5YTipCnGWDAWXL7/FHpORLIwHgYrwZh7Lem5vqVmNuriph1MKma76X si7o5zwoxxokgNV6DSCw1hQsn7mhvm27XEk49zj67FhnpIbxknmwBsj+JSFIsVVRsqqI MpWb3RlJvXlzPtf0WHQrYBMBQIvw+Vmvwecnql/miqH/J1IW+9uam2q4yza+zkPJEfaE ilXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cifOJygfz0/AC6MdnJVobasC2TZjbd3yTSgOSe14704=; b=KuaRk8wkW5tpI8J1No4oTgWIyNs1aCFgTL6tAYt5NUbUqMIFtt6H6tSBRFc2vM7WnU me1ixpK2BL6/gVsaPcHbQ1Kvl34Ebxtrr23gUR5Jq0ByzBx0X/wAL53gUUWoX7ZNbEwa c4DiOiO9dioF0SGEdL1KDUP5VI+KPQ/xzqgimniWCzXd5Cpe2bqbyowJS/BFvC10WGjZ ZvljhGuXrPX3my618tK6EKNaI5CWOOlwS93XUWaL0S4MnCGvRhZoIGxGpmY1hpR9kyqO +uHHoabbq66633wxdBuHHnCHtw2nTKvakfai03oyBHSTtVqTkq/3+Rfh8N+aHRWz1Rt1 4jaQ== X-Gm-Message-State: ALQs6tC/2xOyAjPTYyub+VUSfGaKzNy0i8eNGF7zga0GfpQxe+90fMOz VHqDLiKEcrGmfy5UWdkTsOKCsw== X-Google-Smtp-Source: AIpwx48yqjtexU6kwhcC4FhX6uhHMmqGXKG5gGr0dzjRBUGivWEzvpUzwfBsOQiWjTw0zO5glvYyGw== X-Received: by 10.80.215.7 with SMTP id t7mr26800453edi.104.1524464731283; Sun, 22 Apr 2018 23:25:31 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id b43sm7670410edc.34.2018.04.22.23.25.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Apr 2018 23:25:30 -0700 (PDT) To: Henry Andrews Cc: "json@ietf.org" References: <0326c065-543c-bc78-8c18-d0d9c1d6e0c1@gmail.com> From: Anders Rundgren Message-ID: Date: Mon, 23 Apr 2018 08:25:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON "Number" interoperability issues X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2018 06:25:35 -0000 I'm just saying that the JSON community has interoperability issues: https://github.com/javaee/jsonb-spec/issues/80#issuecomment-383465639 I wouldn't characterize interoperable solutions as JSON "subsets". From an application writer's point of view OpenAPI is more of a subset since it out-of-the-box doesn't support BigInteger which Java and .NET do. Anders On 2018-04-22 20:21, Henry Andrews wrote: > JSON Schema provides tools to describe how people use JSON documents, including imposing structural constraints.  While you could write a schema describing the subset of JSON that you wish to use as your "standard", that would be a *use* of JSON Schema, not *part* of JSON Schema. > > Anders, you seem to want JSON Schema to prevent people from using things that are technically allowed by the spec (as Carsten noted, "allowed" in the sense that no one will stop you, not in the sense that any reasonable person would expect a positive outcome).  That is not what JSON Schema, *as a project*, is for.  You are more than welcome to use JSON Schema in your own project to advocate for a more interoperable subset of JSON. > > The section of JSON Schema's validation specification that you reference, about the values for "format", has gotten some discussion around how to manage larger extensibility question such as defining a registry.  The issue for that discussion is https://github.com/json-schema-org/json-schema-spec/issues/563 > > Furthermore, this email list is not the right forum for discussing changes to JSON Schema.  This group has previously made it pretty clear that they are at most interested in JSON Schema as one of many possible starting points for a new effort, rather than developing JSON Schema itself into a standards track RFC.  I have no objection to that- the IETF is welcome to use or not use our work in whatever way makes sense.  I've never gotten anything to RFC myself, and wouldn't presume to know all of the considerations involved.  I'll be happy to support anyone who wants to use any JSON Schema ideas in a new effort, but if we're talking about JSON Schema as it is, that's better done through our repo or slack channel. > > thanks, > -henry > > henry@cloudflare.com > andrews_henry@yahoo.com > > > On Sun, Apr 22, 2018 at 3:27 AM, Anders Rundgren > wrote: > > Since the JSON Number universe outside of IEEE-754 double precision has been left to application/platform developers to deal with [*], there are currently multiple incompatible (or incomplete) "standards" out there: > https://github.com/OAI/OpenAPI-Specification/issues/845#issuecomment-378139730 > https://github.com/javaee/jsonb-spec/blob/master/spec/spec.pdf > > For .NET I haven't been able obtaining any public information on this topic, so I wrote some code in order to find out what it actually does. > > Maybe JSON Schema could serve a suitable place for defining a [potential] "real/de-facto" standard? > > To make such a process even smother, I could imagine moving http://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3 into a separate document but I haven't looked into the consequences of that. > > Anders > > *] https://www.ietf.org/mail-archive/web/json/current/msg04294.html > > > > > -- > > * > | > > *Henry Andrews*  |  Systems Engineer > henry@cloudflare.com > > > > 1 888 99 FLARE  | www.cloudflare.com > > | > * > From nobody Mon Apr 23 22:39:09 2018 Return-Path: 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 742A812E887 for ; Mon, 23 Apr 2018 22:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_1oVuanBDQR for ; Mon, 23 Apr 2018 22:39:05 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B9312420B for ; Mon, 23 Apr 2018 22:39:05 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id c14-v6so6910881wrd.4 for ; Mon, 23 Apr 2018 22:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=lqUqpqGYAGK0r0eRMs/yXMDGiuT6fcH01PaTk1xv1+4=; b=hBPGfwodDVB6r9Ugn1AixDhGkHfsLI6dMEXzFZ31Z37MdZQnpKB9/yNHdm6VS/dVKb o0vhtQDfvXiZDCwaVQPAJD4KWRBzg3L5fRG6gn+n2zvKP4mM7uLCQN0XXX67tCZ0nRjq UHIugwxE+f5TGD+VRfWDvbaIks4nFLqHoKFnk91LGlxHQF9U0F03rFFcKvLm8jd/IB4j DyCxagtTGBhSXN+9oyNupJ0t4VRy7q7CKyApmpuwAmEyFO2ygGF480pixMAdHDNoIuaW kttM6zYVjGJqic1ygj0U3O65Gxikv88qIVeuTmj4CLha/moMm9ddk20G1eTOGA0E0mVv AVlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=lqUqpqGYAGK0r0eRMs/yXMDGiuT6fcH01PaTk1xv1+4=; b=AODDNEqK+8eLIOf1h6tAEIB5SjAgCrGx4G0M5q+JTdhM9UyYpywPdoZH3636PEXc/J 85saHAxS/arnGQcvzgumbq7XISXFmTZfWlcpqPnbfTZCAUfCF8+wf++6LwNtf4t74ywD wx6U3st1nSCCNZxz9cleKZ+PpwJcTHE2+WpwNB/bR5AfGqhVYrW3A72sncE6CyMR8dUd 3KSoEyowMd8gJnHeg0+WROmbUUcwqLOxCPpKbfoX5N9GrE6J+W+ZhJvh+N2gIc7R7IIg DYzHeR3wjmphCzE1iD5g12NKgCwGVXfGL9RSl6A5MCH9ubNUc3ftODN0u7hg3drTCqij vyiQ== X-Gm-Message-State: ALQs6tAY+bJWd6r+hlQoMOkmh4t4PovIZO+JFhaO1oCueRFBHg8IWjFm CZYoYhOE2Vq1AZiNKKrpcr/VYQ== X-Google-Smtp-Source: AIpwx48AeYvMW5+Wvq/COzEk8kx6kX3GZfD7n39mADxgPbcSvV3pgf+H9GjJg0X4TTa/MsmuIojaTg== X-Received: by 10.167.196.11 with SMTP id j11mr16424595edq.189.1524548343706; Mon, 23 Apr 2018 22:39:03 -0700 (PDT) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 4sm8931557edt.95.2018.04.23.22.39.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Apr 2018 22:39:02 -0700 (PDT) To: "json@ietf.org" From: Anders Rundgren Message-ID: Date: Tue, 24 Apr 2018 07:39:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Json] I-D: ijson-map-schema-4-ext-num-data-types-00 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2018 05:39:07 -0000 No, there is no such I-D, but there will probably be one: https://github.com/OAI/OpenAPI-Specification/issues/1561 Anders