From nobody Fri Feb 26 03:02:31 2021 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 3B5283A130F for ; Fri, 26 Feb 2021 03:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 DwRoNMXvCKmq for ; Fri, 26 Feb 2021 03:02:28 -0800 (PST) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (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 AB2E93A130E for ; Fri, 26 Feb 2021 03:02:27 -0800 (PST) Received: (qmail 20798 invoked from network); 26 Feb 2021 11:02:25 +0000 Received: from host31-49-16-155.range31-49.btcentralplus.com (HELO ?192.168.1.72?) (31.49.16.155) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 26 Feb 2021 11:02:25 +0000 To: "json@ietf.org" From: Pete Cordell Message-ID: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> Date: Fri, 26 Feb 2021 11:02:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 11:02:30 -0000 Quick question if I may... When defining new IETF standards that want to use JSON, are they referencing JSON (RFC8259) or I-JSON (RFC7493)? Thanks, Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Fri Feb 26 04:03:47 2021 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 DEBD73A140D for ; Fri, 26 Feb 2021 04:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 V-tr8DaZhbdm for ; Fri, 26 Feb 2021 04:03:43 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD893A140C for ; Fri, 26 Feb 2021 04:03:43 -0800 (PST) Received: from [192.168.217.152] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Dn7bc48WqzysL; Fri, 26 Feb 2021 13:03:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Carsten Bormann In-Reply-To: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> Date: Fri, 26 Feb 2021 13:03:40 +0100 Cc: "json@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6E254975-F9A7-4563-9C12-4FE52180C56A@tzi.org> References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> To: Pete Cordell X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 12:03:46 -0000 > Quick question if I may... >=20 > When defining new IETF standards that want to use JSON, are they = referencing JSON (RFC8259) or I-JSON (RFC7493)? The answer requires Science (grep through rfc8[3-9]??.txt, so no-one = references 7159): 7493 only 8259 only both 7493 and 8259 -------------------------------------- rfc8366.txt rfc8414.txt rfc8416.txt rfc8427.txt rfc8428.txt rfc8460.txt rfc8485.txt rfc8520.txt rfc8522.txt rfc8555.txt rfc8572.txt rfc8576.txt rfc8610.txt rfc8618.txt rfc8620.txt rfc8628.txt rfc8639.txt rfc8688.txt rfc8693.txt rfc8725.txt rfc8727.txt rfc8734.txt rfc8742.txt rfc8743.txt rfc8747.txt rfc8783.txt rfc8785.txt rfc8790.txt rfc8801.txt rfc8805.txt rfc8827.txt rfc8844.txt rfc8877.txt rfc8895.txt rfc8896.txt rfc8908.txt rfc8921.txt rfc8927.txt rfc8935.txt rfc8936.txt rfc8941.txt rfc8949.txt rfc8977.txt No indent is 7493 only, one indent is 8259 only, and double indent is = both. (Of course, RFC 8610 and RFC 8949 reference both, one for the JSON = format and one for the I-JSON limitations.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Feb 26 04:49:49 2021 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 56FC93A14E9 for ; Fri, 26 Feb 2021 04:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 VGbmiyTe11un for ; Fri, 26 Feb 2021 04:49:43 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 075033A14E2 for ; Fri, 26 Feb 2021 04:49:43 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id w7so7337750wmb.5 for ; Fri, 26 Feb 2021 04:49:42 -0800 (PST) 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=gEKWqTN3mU3XDbAsC4ISZgerioyX6wBnWkthMHEzByA=; b=tVrt4GQU6l3vslZOU+8kaGOh7uEaLEeauU5dAXDRFO6Vu5LWD3CwQiJARRwNprHmW8 lslPz9kDEFQwWdJ5uHnS+UEb5zcLlvOKwVBMGLTGEB3cIaCreegMvFRjWjEDUX7j4tgT lFR001hfkciMfAGkBg+osgtGFnpNsHx8rpDvH4PCV8pGJcmEy5zdhUUVPzYrVtTAbTkZ THCHGh3t6wqfFQpfD4tGOlvkL3rLWZTGaaQa61yMBtrk1FkNDbqp3qe6P8gTNOsceJDv 6Z4Iu5i15zt9Mv9VHEWt27GWcGSXCOmM7FrugzSAj0XMID0XXx56AIdU+JJP9cFbzeh+ tI7w== 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=gEKWqTN3mU3XDbAsC4ISZgerioyX6wBnWkthMHEzByA=; b=BYnepkI70dncH7S5mJXwxP+85LrjRXzljZkiMlQ5Vtr9+EPyqqihWfjZsZhMggJV8x B0Dw5gTVKJaeHNHbnK4cdyN9Tt/khMVeVfXoaZO94GiroZV+ks+8jnIOUBhpg8JiVd4D 0P6hQKHWeRsXJ4G+w1GXQ/1sLL0DB27pD4/QHKOixJ6d7o0EOH0gJujv7KEVSPyz+KcW hnGcTLVPNF/OLODKswvUZ6W1uXf+IFs+vAgM06vHsuywH4KxbW8qWr0d2i87z/T1PgM1 Arke8SrXL+vPzvH9jwzDc7/ECHtoqIl8XTGjwhFrJzlb5rB6vP7mQi8frNaOClXa/fay hOIw== X-Gm-Message-State: AOAM531be7BUrno0slUWFrHSsalRv0N6GsuCCMGFgi8cNBkHnaKxxjcf tGpET/WBS5YWZbopjufHUeQkm1wlzdFIiQ== X-Google-Smtp-Source: ABdhPJwMPnegBY/zmfz63XQdE/PK8eQx6Qr05RaQsenKkM4qLsdnhAIfgfMiuuy5IpCSi0JF6cpKcw== X-Received: by 2002:a1c:c257:: with SMTP id s84mr1529632wmf.96.1614343780978; Fri, 26 Feb 2021 04:49:40 -0800 (PST) Received: from [192.168.1.67] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id v9sm13493516wrn.86.2021.02.26.04.49.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Feb 2021 04:49:40 -0800 (PST) To: Pete Cordell , "json@ietf.org" References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> From: Anders Rundgren Message-ID: <1c819bc9-283d-e36b-7de2-507553420faa@gmail.com> Date: Fri, 26 Feb 2021 13:49:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 12:49:48 -0000 On 2021-02-26 12:02, Pete Cordell wrote: > Quick question if I may... > > When defining new IETF standards that want to use JSON, are they > referencing JSON (RFC8259) or I-JSON (RFC7493)? If the standard-to-be is supposed to interoperate with browsers and node.js the only viable option is RFC7493. If the standard-to-be also targets the financial market, further constraints apply since floating point arithmetic is ill-suited for monetary operations. E.g. a monetary amount of 46.99 should be represented in JSON as the string "46.99". Anders > > Thanks, > > Pete. > From nobody Fri Feb 26 06:00:05 2021 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 0BF493A0B60 for ; Fri, 26 Feb 2021 06:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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=ccil-org.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 HJbf11rs_Anu for ; Fri, 26 Feb 2021 06:00:01 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 635CE3A0B68 for ; Fri, 26 Feb 2021 05:59:59 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id h8so9083037qkk.6 for ; Fri, 26 Feb 2021 05:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=66CL6jXGaV3vIA1giLYZ4k7a6dGlZyWrpIyhk5WBROg=; b=ieaZy19iZcqynOkT3z3koVbuiAdRHJmztDXaEgiFarCLHOFd1K6XOEmelhztPdu0Dw BvnXF7TbeQnBBAhlTgGCBsreXlDAK+6I8SXe1Ci+VZBmDIU5EHu0C44a5waQ0oJVzbbo FU474w94VAiv98CtxNpvN0Z1LS93Dq7SqVPofXZBIKUTRP47no/OsVVxIhCVv7U32I0l LNHLWhDQIuN/x1XyRECbiKjmjNp+xMiL+bf2+SQq+N9DrNBhzfrURjAxN9/nHqRwXqEA AvW/0rXCqeQPgoncMDCyIeOwjAdcm4i/188pjRFET6V4Vm/VT1iknLXROGeBC/VBQin8 +1iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=66CL6jXGaV3vIA1giLYZ4k7a6dGlZyWrpIyhk5WBROg=; b=dpLTogywREpVZjrDLsrRFolg9gv23N4KiTuag4sa7Mq7WVCe9Q4w44q0HR0LddCtXa tqJLEFg+fC//ZHuM41cWlF8xD/Ibpej7PQMDGcTL053yluBSGvoMuoiHO2Mi8Sf/7FD+ Pmv9LBDi3ySKdIt52OS1/TPV4C89P4M01MfFNh2nYMW+vK0L0Gv2dxWb7JfDEZ8NMGvC OAU75D+9eG5NXVhMGnO4pFudu8TNK2WEHTFUZHIUVmmNwRl52LYKrG/VlTz1m/M3/PDy A/rjPzTC9AazOG+TqLdScFMmIeMiLHq/vvjy7MP41qu6O8EXwVON6oqAiTzYwS4pM6Wy Vjgg== X-Gm-Message-State: AOAM5325oFTlpfxmLQYd31ZtaefIKPm/I/jDGEGRl/CLQ33djWmXfxl3 ggou0hdcVi+SxnM16rbQFhkTmrk61y1+wodaoerBQg== X-Google-Smtp-Source: ABdhPJxhb1hEulaPmeaZGjv0QTXEdKzux/1buG6DfFZoKdq/V0kYU4Q5Ng+EW8bFZ5NUSxiDahPY7jpE4JMz0Ldg9co= X-Received: by 2002:a37:4a49:: with SMTP id x70mr2659497qka.118.1614347998322; Fri, 26 Feb 2021 05:59:58 -0800 (PST) MIME-Version: 1.0 References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> <1c819bc9-283d-e36b-7de2-507553420faa@gmail.com> In-Reply-To: <1c819bc9-283d-e36b-7de2-507553420faa@gmail.com> From: John Cowan Date: Fri, 26 Feb 2021 08:59:47 -0500 Message-ID: To: Anders Rundgren Cc: Pete Cordell , "json@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fbf61205bc3dae63" Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 14:00:03 -0000 --000000000000fbf61205bc3dae63 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > If the standard-to-be is supposed to interoperate with browsers and > node.js the only viable option is RFC7493. > > If the standard-to-be also targets the financial market, further > constraints apply since floating point arithmetic is ill-suited for > monetary operations. E.g. a monetary amount of 46.99 should be represented > in JSON as the string "46.99". > RFC 8259 incorporates all of the restrictions of 7493 as interoperability warnings, including the one above. That way it stays compatible with ECMA-404 (which has no such restrictions or warnings) but still steers you away from the dark corners of JSON. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org The Imperials are decadent, 300 pound free-range chickens (except they have teeth, arms instead of wings, and dinosaurlike tails). --Elyse Grasso --000000000000fbf61205bc3dae63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 26, 2= 021 at 7:49 AM Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
=C2=A0<= /div>
If the standard-to-b= e is supposed to interoperate with browsers and node.js the only viable opt= ion is RFC7493.

If the standard-to-be also targets the financial market, further constraint= s apply since floating point arithmetic is ill-suited for monetary operatio= ns. E.g. a monetary amount of 46.99 should be represented in JSON as the st= ring "46.99".

RFC 8259 incorporates all of the restrictions of 7493 as interoperabi= lity warnings, including the one above.=C2=A0 That way it stays compatible = with ECMA-404 (which has no such restrictions or warnings) but still steers= you away from the dark corners of JSON.


John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= http://vrici.lojban.org/~cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0cowan@ccil.= org
The Imperials are decadent, 300 pound free-range chickens (excep= t they have
teeth, arms instead of wings, and dinosaurlike tails). =C2= =A0--Elyse Grasso

--000000000000fbf61205bc3dae63-- From nobody Fri Feb 26 06:44:53 2021 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 427AE3A045E for ; Fri, 26 Feb 2021 06:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 uu5-tcekGjyY for ; Fri, 26 Feb 2021 06:44:49 -0800 (PST) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (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 ACBA13A040F for ; Fri, 26 Feb 2021 06:44:47 -0800 (PST) Received: (qmail 22747 invoked from network); 26 Feb 2021 14:44:44 +0000 Received: from host31-49-16-155.range31-49.btcentralplus.com (HELO ?192.168.1.72?) (31.49.16.155) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 26 Feb 2021 14:44:44 +0000 To: Carsten Bormann Cc: "json@ietf.org" References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> <6E254975-F9A7-4563-9C12-4FE52180C56A@tzi.org> From: Pete Cordell Message-ID: <9c1b04a1-f8e5-5ff4-06a4-9e5b8599128e@codalogic.com> Date: Fri, 26 Feb 2021 14:44:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <6E254975-F9A7-4563-9C12-4FE52180C56A@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 14:44:51 -0000 On 26/02/2021 12:03, Carsten Bormann wrote: >> Quick question if I may... >> >> When defining new IETF standards that want to use JSON, are they referencing JSON (RFC8259) or I-JSON (RFC7493)? > > The answer requires Science (grep through rfc8[3-9]??.txt, so no-one references 7159): > > 7493 only > 8259 only > both 7493 and 8259 > -------------------------------------- > rfc8366.txt > rfc8414.txt > ... > > No indent is 7493 only, one indent is 8259 only, and double indent is both. > (Of course, RFC 8610 and RFC 8949 reference both, one for the JSON format and one for the I-JSON limitations.) > > Grüße, Carsten Many thanks, Carsten. I noticed a few 8259 only ones mentioned it under "Informative References" (not Normative) and others were only interested in the MIME type registration parts. So it's perhaps not so surprising that 7493 is not as prevalent as you might at first hope. I guess which you reference of 7493 and 8259 may also depend on which end of the Postel Principle you are on :-) Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Fri Feb 26 06:55:30 2021 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 CB9003A08ED for ; Fri, 26 Feb 2021 06:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 d671YxuY26gG for ; Fri, 26 Feb 2021 06:55:27 -0800 (PST) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (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 8AE7D3A08E4 for ; Fri, 26 Feb 2021 06:55:26 -0800 (PST) Received: (qmail 24250 invoked from network); 26 Feb 2021 14:55:24 +0000 Received: from host31-49-16-155.range31-49.btcentralplus.com (HELO ?192.168.1.72?) (31.49.16.155) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (AES128-SHA encrypted, authenticated); 26 Feb 2021 14:55:24 +0000 To: John Cowan , Anders Rundgren Cc: "json@ietf.org" References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> <1c819bc9-283d-e36b-7de2-507553420faa@gmail.com> From: Pete Cordell Message-ID: Date: Fri, 26 Feb 2021 14:55:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 14:55:29 -0000 On 26/02/2021 13:59, John Cowan wrote: > > > On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren > > > wrote: > > If the standard-to-be is supposed to interoperate with browsers and > node.js the only viable option is RFC7493. > > If the standard-to-be also targets the financial market, further > constraints apply since floating point arithmetic is ill-suited for > monetary operations. E.g. a monetary amount of 46.99 should be > represented in JSON as the string "46.99". > > > RFC 8259 incorporates all of the restrictions of 7493 as > interoperability warnings, including the one above.  That way it stays > compatible with ECMA-404 (which has no such restrictions or warnings) > but still steers you away from the dark corners of JSON. RFC 8259 tells you "that way lies madness" but doesn't actually tell you to not to go that way! RFC 7493 makes it explicit not to go that way for those that might otherwise say "well you didn't tell me not to...". Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Fri Feb 26 07:03:32 2021 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 E85163A0990 for ; Fri, 26 Feb 2021 07:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=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 x_SrEzNFxRrN for ; Fri, 26 Feb 2021 07:03:28 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 F29E43A098D for ; Fri, 26 Feb 2021 07:03:27 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id q23so10930035lji.8 for ; Fri, 26 Feb 2021 07:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qBIPbSHxKHAmJFpd4486aDVMbNDYpL3DyZgfTPCLQrk=; b=ukIidPMwBoKPFLNgYUp+SAvvBFrgp3nobm2cO6Nt2IuCHgX04HzPwabL3liZzHnvsC Fbf4KT9E/dD3lEE0Fp36zMUH3bI677jScWRY8+yA8pw3nLWcG9QYW0T7T/t7yrzNVheJ fhZfSq4B/Gz4A0Ax8+w7maVlmewZc5R9NyAfLeXuPc9UAqooIkxgI18K3TLPSQjuTwVh wpIbaraI1t0MdL3pni2rs3SpIMyHUONjF1Xy9blcNpYBZp4A+YASMsKt3jFu7UaZD0ot 9Gmz7dirxhSJkPr6Nru20bV1R0Zq1rLfQwcOibYnpRQ13DAGi9zfxT976KxxhRo/1cZ6 JQjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qBIPbSHxKHAmJFpd4486aDVMbNDYpL3DyZgfTPCLQrk=; b=DZQV2rXh/8G8ksUQo79OQw6e0lUwgY20UesWC8O1zJEVrVlsez23I/abqgNo18/Mqp QMUmN5Z9v9XyY+6yYZG8uS0juuR5hHdb1rf8+1QAu10C5q/6X8503qHEOtU9JBlTShJZ 4RAlLklKiXRs7lW/B/vEUG2EQ+AOAdo929DeteEqoc6ax1jSMPLUSp7uLoCS1EPwuul1 LM7ljXUszw9NuauPvfQai3ZxilcMXZtF3lagC0kIpMAb6FvTGbQmtJkkU4wi5ddFhBWc YWWj3mf82F3YeRY0HRtzSy6eRwIkKo6+r7uW0wCvXBXe+to7ld/v+NNGcOU5zALLcvZE QMcA== X-Gm-Message-State: AOAM533DC3bS+d4aHEJTH1SXB2QgoW7vogNaTqbDBEgYIH6z41Cx60Tc D5nJr2nOwhUkxAeApTRno1hy7Sa9OUGVWjofyLLuXyw/p7Jj/A== X-Google-Smtp-Source: ABdhPJwjz2vJaQM80ojFoIty7dy+41JIXCNtvvglCEcSVCh+ytQs6RKuAWvIdmzjF4tAYNPmMjbIWMloS2QSMYvOX48= X-Received: by 2002:a2e:b80c:: with SMTP id u12mr2008841ljo.154.1614351804299; Fri, 26 Feb 2021 07:03:24 -0800 (PST) MIME-Version: 1.0 References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> <1c819bc9-283d-e36b-7de2-507553420faa@gmail.com> In-Reply-To: From: Tim Bray Date: Fri, 26 Feb 2021 07:03:12 -0800 Message-ID: To: Pete Cordell Cc: John Cowan , Anders Rundgren , "json@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d6909105bc3e9176" Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 15:03:30 -0000 --000000000000d6909105bc3e9176 Content-Type: text/plain; charset="UTF-8" I personally would use I-JSON if possible because it has useful MUSTs in it to help resolve arguments between implementors. [But then, I edited the RFC, so I would.] There's one downside, which is that as far as I know, there's little software that actually enforces the I-JSON constraints. On Fri, Feb 26, 2021 at 6:55 AM Pete Cordell wrote: > On 26/02/2021 13:59, John Cowan wrote: > > > > > > On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren > > > > > wrote: > > > > If the standard-to-be is supposed to interoperate with browsers and > > node.js the only viable option is RFC7493. > > > > If the standard-to-be also targets the financial market, further > > constraints apply since floating point arithmetic is ill-suited for > > monetary operations. E.g. a monetary amount of 46.99 should be > > represented in JSON as the string "46.99". > > > > > > RFC 8259 incorporates all of the restrictions of 7493 as > > interoperability warnings, including the one above. That way it stays > > compatible with ECMA-404 (which has no such restrictions or warnings) > > but still steers you away from the dark corners of JSON. > > RFC 8259 tells you "that way lies madness" but doesn't actually tell you > to not to go that way! RFC 7493 makes it explicit not to go that way > for those that might otherwise say "well you didn't tell me not to...". > > Pete. > -- > --------------------------------------------------------------------- > Pete Cordell > Codalogic Ltd > C++ tools for C++ programmers, http://codalogic.com > Read & write XML in C++, http://www.xml2cpp.com > --------------------------------------------------------------------- > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --000000000000d6909105bc3e9176 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I p= ersonally would use I-JSON if possible because it has useful MUSTs in it to= help resolve arguments between implementors. =C2=A0[But then, I edited the= RFC, so I would.] =C2=A0There's one downside, which is that as far as = I know, there's little software that actually enforces the I-JSON const= raints.=C2=A0

On Fri, Feb 26, 2021 at 6:55 AM Pete Cordell <petejson@codalogic.com> wrote:
On 26/02/2021 13:59, John Cowan wrote:
>
>
> On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren
> <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>= >
> wrote:
>
>=C2=A0 =C2=A0 =C2=A0If the standard-to-be is supposed to interoperate w= ith browsers and
>=C2=A0 =C2=A0 =C2=A0node.js the only viable option is RFC7493.
>
>=C2=A0 =C2=A0 =C2=A0If the standard-to-be also targets the financial ma= rket, further
>=C2=A0 =C2=A0 =C2=A0constraints apply since floating point arithmetic i= s ill-suited for
>=C2=A0 =C2=A0 =C2=A0monetary operations. E.g. a monetary amount of 46.9= 9 should be
>=C2=A0 =C2=A0 =C2=A0represented in JSON as the string "46.99"= .
>
>
> RFC 8259 incorporates all of the restrictions of 7493 as
> interoperability warnings, including the one above.=C2=A0 That way it = stays
> compatible with ECMA-404 (which has no such restrictions or warnings) =
> but still steers you away from the dark corners of JSON.

RFC 8259 tells you "that way lies madness" but doesn't actual= ly tell you
to not to go that way!=C2=A0 RFC 7493 makes it explicit not to go that way =
for those that might otherwise say "well you didn't tell me not to= ...".

Pete.
--
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--000000000000d6909105bc3e9176-- From nobody Fri Feb 26 09:41:16 2021 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 1C3963A1393 for ; Fri, 26 Feb 2021 09:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xhcUwAeL7VVy for ; Fri, 26 Feb 2021 09:41:13 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 55BFD3A1392 for ; Fri, 26 Feb 2021 09:41:13 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id h17so10538304oih.5 for ; Fri, 26 Feb 2021 09:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OTT7QcMSn9BmySjjCFPeG1nk+J/EJKRjJeqbIJzzfEs=; b=rZyqwVHlTC4ub91xyj8R2QVfXwB3KUBEeQ8t0wfm+AoCxraBGvozRaLCdBw/aHAA2j x4cZw756xhEqJQfzy6HDvkTmxdH5g9q8JyrX63EBLCp7wCgzYhFfsZEDr2+ZEfSTo7Fg 2gSy63kQQp5pZODFYmwnmNegqJ1az/lEjD/eNfFeMoLrAQt942H6oh5nGo/aPPlHEFem vuDBY6iBPYZM9g592MMUEdJT2oVakqD2ZpD+kmgr7VzialiFqR8RmZZERVT+ziwP3rn/ 7QH/7jayB5+tTDqSbk0i0+5NAF4CC2MGm3YcGXuUSB6RUSSDG9YFuxvaHicHWUPDZ4KX /Hig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OTT7QcMSn9BmySjjCFPeG1nk+J/EJKRjJeqbIJzzfEs=; b=jjTRPDIqEc4LUM9BP7MVWG9LrmDE7BQLab01VcKk4LKlEphnaQ1tY36cbRaHksf+Ym W55oB2s3occSJSR0zqHSViVAs6nwULQ+PP23u4ljtVjYV7yyjlQPEqcwvEQaip5V0PEo Gcffv+BndCh7qwSnDkqwdSoj2GRcAjh+VR6IVn5M8OqKVYx5yW4SiqKDeCPIbM9T/Adr LyDqpBSnnQJO/1EB2TJQuq1fwqBd4TjLu/TNK5oi2JNvOFmReE4+jFwGrTJy+aAttzi9 yTlcqiDZvoYtGXK1iLZXwnrr9XYYTWwlnXKh27ypUjYTZjWoz+s2qQf/QsZtEvUV6bXX 6mpw== X-Gm-Message-State: AOAM5332qjUbeBsh1l14KGFagLlOLZDrg90A1+1bxnV1eH/aIeV421bA v/f6SxyyiIXX4azv6XQ0tsXPNfBpvOHBh56M46Q= X-Google-Smtp-Source: ABdhPJxRqxBzV6ZdCLTzLJaR6uB6KRRDbHkrV29bwwIW6r7IGdbY5AdmL5Ol9n2+ay47tAnjSWWLlB2UFOa0KF3SC2I= X-Received: by 2002:aca:bd85:: with SMTP id n127mr2848822oif.178.1614361272594; Fri, 26 Feb 2021 09:41:12 -0800 (PST) MIME-Version: 1.0 References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> <1c819bc9-283d-e36b-7de2-507553420faa@gmail.com> In-Reply-To: From: David Kemp Date: Fri, 26 Feb 2021 12:41:00 -0500 Message-ID: To: Tim Bray Cc: Pete Cordell , "json@ietf.org" , John Cowan , Anders Rundgren Content-Type: multipart/alternative; boundary="0000000000003137f705bc40c6a3" Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 17:41:15 -0000 --0000000000003137f705bc40c6a3 Content-Type: text/plain; charset="UTF-8" Most of the I-JSON constraints are good for interoperability, and as Anders points out, the lack of a distinct Integer type means that some applications must use String rather than Number to represent Integers. But section 4.2 ("must-ignore") is anathema to security, and the fact that that is not even discussed in RFC 7493's security considerations is negligent. If you are designing a protocol that uses, for example, Reputons ( https://tools.ietf.org/html/draft-ietf-repute-media-type-13#section-3.1), and a Reputon can contain megabytes of malware, or mpegs of cats being cute, or 14th century pornography ( https://github.com/oasis-tcs/openc2-usecases/blob/master/Cybercom-Plugfest/TestData/slpf%2Bacme/commands/bad/create_poetry.json), that isn't necessarily a good thing for the Internet. Dave On Fri, Feb 26, 2021 at 10:03 AM Tim Bray wrote: > I personally would use I-JSON if possible because it has useful MUSTs in > it to help resolve arguments between implementors. [But then, I edited the > RFC, so I would.] There's one downside, which is that as far as I know, > there's little software that actually enforces the I-JSON constraints. > > On Fri, Feb 26, 2021 at 6:55 AM Pete Cordell > wrote: > >> On 26/02/2021 13:59, John Cowan wrote: >> > >> > >> > On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren >> > > >> > wrote: >> > >> > If the standard-to-be is supposed to interoperate with browsers and >> > node.js the only viable option is RFC7493. >> > >> > If the standard-to-be also targets the financial market, further >> > constraints apply since floating point arithmetic is ill-suited for >> > monetary operations. E.g. a monetary amount of 46.99 should be >> > represented in JSON as the string "46.99". >> > >> > >> > RFC 8259 incorporates all of the restrictions of 7493 as >> > interoperability warnings, including the one above. That way it stays >> > compatible with ECMA-404 (which has no such restrictions or warnings) >> > but still steers you away from the dark corners of JSON. >> >> RFC 8259 tells you "that way lies madness" but doesn't actually tell you >> to not to go that way! RFC 7493 makes it explicit not to go that way >> for those that might otherwise say "well you didn't tell me not to...". >> >> Pete. >> -- >> --------------------------------------------------------------------- >> Pete Cordell >> Codalogic Ltd >> C++ tools for C++ programmers, http://codalogic.com >> Read & write XML in C++, http://www.xml2cpp.com >> --------------------------------------------------------------------- >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --0000000000003137f705bc40c6a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Most of the I-JSON constraints are good for interoperabili= ty, and as Anders points out, the lack of a distinct Integer type means tha= t some applications must use String rather than Number to represent Integer= s.=C2=A0 But section 4.2 ("must-ignore") is anathema to security,= and the fact that that is not even discussed in RFC 7493's security co= nsiderations is negligent.

If you are designing a protocol that uses= , for example, Reputons (https://tools.ietf.org/html/draft-ietf-re= pute-media-type-13#section-3.1), and a Reputon can contain megabytes of= malware, or mpegs of cats being cute, or 14th century pornography (https://github.co= m/oasis-tcs/openc2-usecases/blob/master/Cybercom-Plugfest/TestData/slpf%2Ba= cme/commands/bad/create_poetry.json), that isn't necessarily a good= thing for the Internet.

Dave

On Fri, Feb 26, 2021 at 10:03 AM Tim Br= ay <tbray@textuality.com>= wrote:
I personall= y would use I-JSON if possible because it has useful MUSTs in it to help re= solve arguments between implementors. =C2=A0[But then, I edited the RFC, so= I would.] =C2=A0There's one downside, which is that as far as I know, = there's little software that actually enforces the I-JSON constraints.= =C2=A0

On Fri, Feb 26, 2021 at 6:55 AM Pete Cordell <petejson@codalogic.com>= ; wrote:
On 26/0= 2/2021 13:59, John Cowan wrote:
>
>
> On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren
> <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>= >
> wrote:
>
>=C2=A0 =C2=A0 =C2=A0If the standard-to-be is supposed to interoperate w= ith browsers and
>=C2=A0 =C2=A0 =C2=A0node.js the only viable option is RFC7493.
>
>=C2=A0 =C2=A0 =C2=A0If the standard-to-be also targets the financial ma= rket, further
>=C2=A0 =C2=A0 =C2=A0constraints apply since floating point arithmetic i= s ill-suited for
>=C2=A0 =C2=A0 =C2=A0monetary operations. E.g. a monetary amount of 46.9= 9 should be
>=C2=A0 =C2=A0 =C2=A0represented in JSON as the string "46.99"= .
>
>
> RFC 8259 incorporates all of the restrictions of 7493 as
> interoperability warnings, including the one above.=C2=A0 That way it = stays
> compatible with ECMA-404 (which has no such restrictions or warnings) =
> but still steers you away from the dark corners of JSON.

RFC 8259 tells you "that way lies madness" but doesn't actual= ly tell you
to not to go that way!=C2=A0 RFC 7493 makes it explicit not to go that way =
for those that might otherwise say "well you didn't tell me not to= ...".

Pete.
--
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------

_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--0000000000003137f705bc40c6a3-- From nobody Fri Feb 26 14:12:34 2021 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 133013A0D63 for ; Fri, 26 Feb 2021 14:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=ccil-org.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 DmTn_hvJz6GJ for ; Fri, 26 Feb 2021 14:12:31 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 D4A2C3A0D66 for ; Fri, 26 Feb 2021 14:12:30 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id x124so10769031qkc.1 for ; Fri, 26 Feb 2021 14:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wesPHJKBkqRUQQTghaGi4Jmwjt8BZxgadYhQW+YU7AE=; b=vs78WgynOpe43IBJZdlsryER5wgjlztLkh/NNlRKy59FyKiOeF8bAaDSn5wWtKc6du vLMEG10t3tjul3HzBKROC48yUfINueRJrhft0A76eo1KLZ4mdHJI0xz8ChP5B+3qIEFU HqgMBZQMdsZH5aSAFO0ckF9uG1fllWQ2F766YiLv7c3KshAGiUkjKbUzBck4Pi0zX8Pb P2zgEft0oLtdHr4RRNUfNqe/lf9oc1yTQbCDXDjTO9FPeNrnzrMednhdaR8J2CGeIBxt z+6WIZxXAzBxdntI/S9tig6t96CvSVNUW2yFvpiWZxmLus4I19nRot34AHKTklakw4B4 g6tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wesPHJKBkqRUQQTghaGi4Jmwjt8BZxgadYhQW+YU7AE=; b=fE3IhM3rFn/cV3T3R7V1qHAWSXJRGkVKj0UY9CWCtJCmBGcbghRfV8wB2ugG3nHVl0 dWiUP5V3SoOlQhlA82I/wbRvw+sTpHolR8Aa6aVOUzi/TkIGawfw+wqATQpSffZcftm3 vOABrd8twMMNU39yaVamR4tSE4FTMgo9lLei1kNPETfbImAPTsMhoqId7jjlRVFDYvNW T7XSiOk4WglFvsdnGqM76BLdfzoPrwyjEG7xwWjP0cr2No7tR5DFJp7fvsOOTuOkZk6H D511qEk9cVqCcvzKSdYr/YR5fKwS4n5kyQdZTY11gM/2bOTSj+bmO9s6UUk5vpe7esHe LWiw== X-Gm-Message-State: AOAM530DToFxyIjUkLRwJI7/pw2IZFE6UdPyOKHYzKFL8kcNqU4v12df Hnf5T8pMIEJGOf4111GX8sjA0NWrJThSuEiRUeCDpA== X-Google-Smtp-Source: ABdhPJxBxVWMKWDpWsOGBtzjho4pNxcn+nxA15bwkaK9o8GvSYMc83AlUJ5EmGaK3O9Ik0IMp/J+7wVfGyxCaL3G/1w= X-Received: by 2002:a37:a151:: with SMTP id k78mr4772386qke.359.1614377549757; Fri, 26 Feb 2021 14:12:29 -0800 (PST) MIME-Version: 1.0 References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> <1c819bc9-283d-e36b-7de2-507553420faa@gmail.com> In-Reply-To: From: John Cowan Date: Fri, 26 Feb 2021 17:12:18 -0500 Message-ID: To: David Kemp Cc: Tim Bray , Pete Cordell , "json@ietf.org" , Anders Rundgren Content-Type: multipart/alternative; boundary="00000000000063482505bc44906b" Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 22:12:33 -0000 --00000000000063482505bc44906b Content-Type: text/plain; charset="UTF-8" On Fri, Feb 26, 2021 at 12:41 PM David Kemp wrote: If you are designing a protocol that uses, for example, Reputons ( > https://tools.ietf.org/html/draft-ietf-repute-media-type-13#section-3.1), > and a Reputon can contain megabytes of malware, or mpegs of cats being > cute, or 14th century pornography ( > https://github.com/oasis-tcs/openc2-usecases/blob/master/Cybercom-Plugfest/TestData/slpf%2Bacme/commands/bad/create_poetry.json), > that isn't necessarily a good thing for the Internet. > Nevertheless, there are many contexts where must-ignore is entirely appropriate. If I am checking your ID card against a list of authorized visitors, all I need to know is how to find your picture and your name: whatever other fields may be present are quite irrelevant to me. (Not always so easy: probably a hundred traffic tickets were written in Ireland in 2006-09 in the name of Prawo Jazdy, which is, alas, merely the Polish for "driver's license".) In any case, simple limitations on the length or nesting depth of a structured document should be enough to eliminate all the problems you mention. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org "Mr. Lane, if you ever wish anything that I can do, all you will have to do will be to send me a telegram asking and it will be done." "Mr. Hearst, if you ever get a telegram from me asking you to do anything, you can put the telegram down as a forgery." --00000000000063482505bc44906b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 26, 2= 021 at 12:41 PM David Kemp <dk190a@g= mail.com> wrote:

If you= are designing a protocol that uses, for example, Reputons (https://tools.ietf.org/html/draft-ietf-repute-media-type-13#sec= tion-3.1), and a Reputon can contain megabytes of malware, or mpegs of = cats being cute, or 14th century pornography (https://github.com/oa= sis-tcs/openc2-usecases/blob/master/Cybercom-Plugfest/TestData/slpf%2Bacme/= commands/bad/create_poetry.json), that isn't necessarily a good thi= ng for the Internet.

Nevertheless, there are many contexts where must-ignore is entirel= y appropriate.=C2=A0 If I am checking your ID card against a list of author= ized visitors, all I need to know is how to find your picture and your name= : whatever other fields may be present are quite irrelevant to me.=C2=A0 (N= ot always so easy: probably a hundred traffic tickets were written in Irela= nd in 2006-09 in the name of Prawo Jazdy, which is, alas, merely the Polish= for "driver's license".)

=
In any case, simple limitations on the leng= th or=C2=A0nesting depth of a structured document should be enough to elimi= nate all the problems you mention.



<= div class=3D"gmail_default" style=3D"font-family:"times new roman"= ;,serif;font-size:large">John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://vrici.lojban.org/~cowan = =C2=A0 =C2=A0 =C2=A0 =C2=A0cowan@ccil.org=
=C2=A0 =C2=A0 "Mr. Lane, if you ever wish anything that I can = do, all you will have
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to do will be to send = me a telegram asking and it will be done."
=C2=A0 =C2=A0 "Mr. = Hearst, if you ever get a telegram from me asking you to do
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 anything, you can put the telegram down as a forgery.&quo= t;
--00000000000063482505bc44906b-- From nobody Fri Feb 26 15:14:48 2021 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 E6C913A13D2 for ; Fri, 26 Feb 2021 15:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 HzVWmFg5MR6H for ; Fri, 26 Feb 2021 15:14:45 -0800 (PST) Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) (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 19D593A13D1 for ; Fri, 26 Feb 2021 15:14:45 -0800 (PST) Received: by mail-yb1-f176.google.com with SMTP id l8so10485587ybe.12 for ; Fri, 26 Feb 2021 15:14:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PkRK713FofJRPpXsCnNDTp5+pDBQ4dR7oGiIP9rUCj0=; b=qlIy4ANT4V0YAAVVkgDhHLWIptUmbqTOMGiFt3rgEq4rOK8+lR0Gvm2Hnjm8gdMcas 5s7ObZz91dI64BuT0u0ijzMQryFbBlHiN/J96a3j8804KFyVcAQ6RilAaAUKlXcbXjEx Xn06efhDcexZguthBYKvwgCzyAdZgBLXmdzrhEQRiCvbeKD/H33N8NkEuX1y/IaYKVmP LbQffV1ZnkaJ8gg4ogLBr8ldIW3xrJ2aDEbOooM34otDeGodNb1yQoG+PL6/436hkqbV +vNPZhYjpQZTau1GPDZ+Mq5I0yiPlKgWyquHWAEf91sM/yIyoVHKyRuK0v9Kb3Ojos42 fxUg== X-Gm-Message-State: AOAM533LwIA3aFKOlLlREf8GTSaMVmJRdksYrGWptxb59uZ0k3wnY2AQ aJLJMF0h73g5fDL+C/4BBQWROMN2f+INTx05nfA= X-Google-Smtp-Source: ABdhPJxllUN4ZgWqT3q9tJL706f/ilkbSFb+EWa848EmsNFJp1oZGIzr2WcJqtkyr4a1eMnIxl7RY2LURKOPYldCOS8= X-Received: by 2002:a25:dbc6:: with SMTP id g189mr8552778ybf.273.1614381284160; Fri, 26 Feb 2021 15:14:44 -0800 (PST) MIME-Version: 1.0 References: <90cddfc3-c320-5ac0-210b-c77636383a6b@codalogic.com> <1c819bc9-283d-e36b-7de2-507553420faa@gmail.com> In-Reply-To: From: Phillip Hallam-Baker Date: Fri, 26 Feb 2021 18:14:33 -0500 Message-ID: To: Tim Bray Cc: Pete Cordell , "json@ietf.org" , John Cowan , Anders Rundgren Content-Type: multipart/alternative; boundary="000000000000f9779605bc456ed8" Archived-At: Subject: Re: [Json] JSON or I-JSON? X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 26 Feb 2021 23:14:47 -0000 --000000000000f9779605bc456ed8 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 26, 2021 at 10:03 AM Tim Bray wrote: > I personally would use I-JSON if possible because it has useful MUSTs in > it to help resolve arguments between implementors. [But then, I edited the > RFC, so I would.] There's one downside, which is that as far as I know, > there's little software that actually enforces the I-JSON constraints. > I take I-JSON as giving a concrete example of how to be conservative in what you send. I also use it in some of my stuff to be hyper-restrictive in what is accepted for purposes of conformance testing (and the corresponding generator is liberal in what it sends). > On Fri, Feb 26, 2021 at 6:55 AM Pete Cordell > wrote: > >> On 26/02/2021 13:59, John Cowan wrote: >> > >> > >> > On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren >> > > >> > wrote: >> > >> > If the standard-to-be is supposed to interoperate with browsers and >> > node.js the only viable option is RFC7493. >> > >> > If the standard-to-be also targets the financial market, further >> > constraints apply since floating point arithmetic is ill-suited for >> > monetary operations. E.g. a monetary amount of 46.99 should be >> > represented in JSON as the string "46.99". >> > >> > >> > RFC 8259 incorporates all of the restrictions of 7493 as >> > interoperability warnings, including the one above. That way it stays >> > compatible with ECMA-404 (which has no such restrictions or warnings) >> > but still steers you away from the dark corners of JSON. >> >> RFC 8259 tells you "that way lies madness" but doesn't actually tell you >> to not to go that way! RFC 7493 makes it explicit not to go that way >> for those that might otherwise say "well you didn't tell me not to...". >> >> Pete. >> -- >> --------------------------------------------------------------------- >> Pete Cordell >> Codalogic Ltd >> C++ tools for C++ programmers, http://codalogic.com >> Read & write XML in C++, http://www.xml2cpp.com >> --------------------------------------------------------------------- >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --000000000000f9779605bc456ed8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 26, 2021 at 10:03 AM Tim Bray <tbray@textuality.com> wrote:
<= /div>
I personally would use I-JSON if possible becau= se it has useful MUSTs in it to help resolve arguments between implementors= . =C2=A0[But then, I edited the RFC, so I would.] =C2=A0There's one dow= nside, which is that as far as I know, there's little software that act= ually enforces the I-JSON constraints.=C2=A0
<= br>
I take= I-JSON as giving a concrete example of how to be conservative in what you = send.

I also use it in so= me of my stuff to be hyper-restrictive in what is accepted for purposes of = conformance testing (and the corresponding generator is liberal in what it = sends).



=C2=A0
On Fri, Feb 26, 2021 at 6:55 AM Pete Cor= dell <petejs= on@codalogic.com> wrote:
On 26/02/2021 13:59, John Cowan wrote:
>
>
> On Fri, Feb 26, 2021 at 7:49 AM Anders Rundgren
> <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>= >
> wrote:
>
>=C2=A0 =C2=A0 =C2=A0If the standard-to-be is supposed to interoperate w= ith browsers and
>=C2=A0 =C2=A0 =C2=A0node.js the only viable option is RFC7493.
>
>=C2=A0 =C2=A0 =C2=A0If the standard-to-be also targets the financial ma= rket, further
>=C2=A0 =C2=A0 =C2=A0constraints apply since floating point arithmetic i= s ill-suited for
>=C2=A0 =C2=A0 =C2=A0monetary operations. E.g. a monetary amount of 46.9= 9 should be
>=C2=A0 =C2=A0 =C2=A0represented in JSON as the string "46.99"= .
>
>
> RFC 8259 incorporates all of the restrictions of 7493 as
> interoperability warnings, including the one above.=C2=A0 That way it = stays
> compatible with ECMA-404 (which has no such restrictions or warnings) =
> but still steers you away from the dark corners of JSON.

RFC 8259 tells you "that way lies madness" but doesn't actual= ly tell you
to not to go that way!=C2=A0 RFC 7493 makes it explicit not to go that way =
for those that might otherwise say "well you didn't tell me not to= ...".

Pete.
--
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------

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