From nobody Thu Feb 4 06:59:44 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3281B30D1 for ; Thu, 4 Feb 2016 06:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 Rghjw0AdEm_L for ; Thu, 4 Feb 2016 06:59:42 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 548C71B30C6 for ; Thu, 4 Feb 2016 06:59:42 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id j78so37900565lfb.1 for ; Thu, 04 Feb 2016 06:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=NOO6jrxHj/PXJKerdHwiBZs5jj5cslhOuU9S3vs4ANE=; b=yaM44Bg1O0YJGyrcaP2HPb6RavHYRv06dZtVD/lnom7PLBNKMiFl0v83oRMcP0XZma 3L4LnNaHDCda9FuOaeio2Ba31NO3MtArC4cubug9R8rXz+zeIA6IQTnEYHjQn/6AIVoJ Cm8u4CHTuVsvbUTrBpitjmmXtfxa/VjsmA2x04KbgP0mq2P+cQoWP2PdfVG/s8cMNBK7 +D2orL+cXebR5Jku+hA1N9CMqe10PbwwsaqQsbpG9ZdHPVBZDh7efmhZPi+pwVinjLAQ wBQUyXkUJr1YAmlrVDP/ft0mN+bZElOVuFhZz7IVgOKPScdm+wp2pcEnQgrfe5m4Nfqc J0CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=NOO6jrxHj/PXJKerdHwiBZs5jj5cslhOuU9S3vs4ANE=; b=hQC9lLcl2Rj6MwnUbu6+yI3J4AUuaknn6iEePk1AtSFndEBG0kVPnWOwfk0BaXhTVq YDz+j5iqg0YtNcTPcDiSxFeMv1EgYB5P8joAQb12tJ76kz8oDDwcm1DXgSzUCFWOwbtv mVtyZNU9gtcGystkmGP6K6P/2KlkNokGwUcmph+IDy38L5SiVNaoQ6wv3wscerDGu3pn 8Bid6QinI/jAtxTXdzfJgAwOUOjVz/JgmpriCBvGmGFkfc/WCPVPHGQ9JdAICF/Od1tO 4onTHrXuHK6ukQsJb6Y+NXRRIUEf+HLfboE2MaP9R9OHCeuxAvT/zy83USbjK1nhJHFh wNxA== X-Gm-Message-State: AG10YOSHluGCOBEl5glbRofshsPRP4YggBXzyc5otAUg3EEmOISg68lg3MkNjkgstm2vmWW8EgcV7FTc953JfA== MIME-Version: 1.0 X-Received: by 10.25.170.203 with SMTP id t194mr3065429lfe.48.1454597980608; Thu, 04 Feb 2016 06:59:40 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Thu, 4 Feb 2016 06:59:40 -0800 (PST) Date: Thu, 4 Feb 2016 09:59:40 -0500 X-Google-Sender-Auth: i2PDX0PGuqGxc3XhOKC6298GlSY Message-ID: From: Phillip Hallam-Baker To: JSON WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Feb 2016 14:59:43 -0000 I think it would be helpful to have a style guide to encourage styles of JSON use that impose the fewest constraints on serialization/deserialization design. For example, lets say that we have a protocol that has two types of request, A and B. There are two common ways that this can be represented in JSON: Nested style: { "A" : { "field1" : "value1", "field2" : "value2", "field3" : "value3" } } Flat style: { "Type" :"A" , "field1" : "value1", "field2" : "value2", "field3" : "value3" } They both look similar, the only difference is that there is an extra layer of nesting in the first case which means that the label "A" will always precede the data it describes. This isn't the case for the second which can also be written : { "field1" : "value1", "field2" : "value2", "Type" : "A" , "field3" : "value3" } While the issue comes up with requests, it isn't limited to requests, it can happen anywhere that you have a need to tag an object to describe the type. If you are using a scripting language, you parse the data to a DOM tree and which is the in-memory representation of the data. But those of us who use strongly typed languages like C# and Java don't work of DOM trees. We map the data to objects in our implementation language. and we type check and validate all our inputs before we begin processing. Because that is best practice for minimizing attack surface from an invalid input. Nested style allows us to build fast, single pass deserialization tools that require no additional buffering. A constrained device can build the parse tree on the fly without buffering a whole message before it starts processing. Flat style requires us to buffer the data and do a two pass approach. It is very much less efficient as a result. Comments? From nobody Thu Feb 4 07:24:31 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F551B3163 for ; Thu, 4 Feb 2016 07:24:29 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 qJoYYSB8QiZ1 for ; Thu, 4 Feb 2016 07:24:27 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 D89481B3164 for ; Thu, 4 Feb 2016 07:24:26 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id 128so32116502wmz.1 for ; Thu, 04 Feb 2016 07:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=Hj5SQo8ZKqC9Qo4QickQ/GEEbQI3B/OegEaEuDrPrA8=; b=XP3pWz5FES4CKR3IPaKvA66+3GoTjw7PFMyl8HkUSxwugU3IPi+jzn5j9dqdn5jBiz Xyz/7DwyTiV5qfWqf7FApFT33/to1qEs/TAYMItxiqB+PK2hp4qiBiXDGwNfx/yZ+knG DCtH27KJdua6/ZE21V11LN9FJe4LfzKV3/bjW3/NZ3kTIJEDfVQB2yJaYVXR0UaGcB36 wuUcni8reOsrVezS3/gwVe89Vbvpwi70jTKP2z/12+n7D+2QCcNvsvwcDSvHNL1SDeS9 Is2gN61qSLi23Zcpl84S8IeZPX2YcZC2z2Tg/KycBcbMQ+q5/9B+73EJ+7n/lXBiEPCr LxeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Hj5SQo8ZKqC9Qo4QickQ/GEEbQI3B/OegEaEuDrPrA8=; b=TqEkJaucaRfOUxURRmldhNiOC5tg0setsd3pnjJS4nIIVgcESd224NNoabBUb0zOy6 SYRebXnyl0X7zchjL+9j2ddYXUe17SwmdNXiZfQIj6XIRbzJT+2ceEORfKDkDLfd8ClN kcEKuGO9qG0O/YvMu6ZdPXSMa7KbT9Wvbkb+4wW6jMJWvCLoZI9vGJs2tAk6R7fc3nsI N/J7zAcx8Kt6JpkzVZlzYXC7zaDhQNlMfbhrPY6eksQgIkjDvi2AXDyjDsPiL1DWlPuD mplNNsRyxrkSPs4p9IoAUGh+ON9RnYxPVhFHFREoiMjIzBn6aUxZrzaoosu/dVwQYvoy 3paA== X-Gm-Message-State: AG10YOR7cvHec0rssCZGJtmNMQ39W7/mVMb4blP9BHC/sFpkrWIpXHowPoy1iGiWj6X8xA== X-Received: by 10.194.119.161 with SMTP id kv1mr8845077wjb.135.1454599465481; Thu, 04 Feb 2016 07:24:25 -0800 (PST) Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id lc3sm11801857wjb.7.2016.02.04.07.24.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 07:24:24 -0800 (PST) To: Phillip Hallam-Baker , JSON WG References: From: Anders Rundgren Message-ID: <56B36D15.1030306@gmail.com> Date: Thu, 4 Feb 2016 16:24:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Feb 2016 15:24:29 -0000 On 2016-02-04 15:59, Phillip Hallam-Baker wrote: > I think it would be helpful to have a style guide to encourage styles > of JSON use that impose the fewest constraints on > serialization/deserialization design. By pure coincidence I wrote this (somewhat related) paper today: http://webpki.org/papers/AppNote-XML2JSON-Migration.pdf Using your nested design, the outermost property could be something like "https://json.standards.org/payments/PaymentRequest" Not ultra-pretty but certainly workable. Using JCS an embedded signature would preferably be applied to the outermost object. Anyway, isn't CBOR what people are targeting for constrained devices? > > For example, lets say that we have a protocol that has two types of > request, A and B. There are two common ways that this can be > represented in JSON: > > Nested style: > > { "A" : > { "field1" : "value1", "field2" : "value2", "field3" : "value3" } } > > Flat style: > > { "Type" :"A" , "field1" : "value1", "field2" : "value2", "field3" : "value3" } > > They both look similar, the only difference is that there is an extra > layer of nesting in the first case which means that the label "A" will > always precede the data it describes. This isn't the case for the > second which can also be written : > > { "field1" : "value1", "field2" : "value2", "Type" : "A" , "field3" : > "value3" } > > While the issue comes up with requests, it isn't limited to requests, > it can happen anywhere that you have a need to tag an object to > describe the type. > > If you are using a scripting language, you parse the data to a DOM > tree and which is the in-memory representation of the data. > > But those of us who use strongly typed languages like C# and Java > don't work of DOM trees. We map the data to objects in our > implementation language. and we type check and validate all our inputs > before we begin processing. Because that is best practice for > minimizing attack surface from an invalid input. > > > Nested style allows us to build fast, single pass deserialization > tools that require no additional buffering. A constrained device can > build the parse tree on the fly without buffering a whole message > before it starts processing. > > Flat style requires us to buffer the data and do a two pass approach. > It is very much less efficient as a result. > > > Comments? > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Thu Feb 4 07:39:22 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343CC1B31A7 for ; Thu, 4 Feb 2016 07:39:21 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 nlvaTNJ7fcsx for ; Thu, 4 Feb 2016 07:39:19 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5302C1B319E for ; Thu, 4 Feb 2016 07:39:19 -0800 (PST) Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id E35ABC5A7B; Thu, 4 Feb 2016 16:39:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eB4LaLd4On6u; Thu, 4 Feb 2016 16:39:16 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 4B851C5AB0; Thu, 4 Feb 2016 16:39:15 +0100 (CET) Message-ID: <56B370A1.1050508@tzi.org> Date: Thu, 04 Feb 2016 16:39:13 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Anders Rundgren References: <56B36D15.1030306@gmail.com> In-Reply-To: <56B36D15.1030306@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Feb 2016 15:39:21 -0000 Anders Rundgren wrote: > Anyway, isn't CBOR what people are targeting for constrained devices? Yes, but the desire to be able to do sequential (as opposed to DOM-based) processing goes beyond constrained devices. But talking about those: The original design of SenML had a top level map (what is called "object" in JavaScript, but then arrays are also objects in JavaScript) of the form: { "metadata1": "value", "metadata2": 4711, "contents": [ ... potentially many measurements ... where the interpretation of those ... depends on the metadata. ] } This looks deceptively sequential on a napkin, and it creates no problems for a DOM-based receiver implementation (until the measurements don't fit into memory any more). For an implementation that tries to do sequential processing, this structure is a big problem: The metadata may occur before or after the measurement array, depending on the whims of the encoder, so you may not have what you need to process the measurements sequentially at the place they occur. Requiring the encoder to send data in a particular sequence is theoretically possible, but in practice just means you lose that part of the ecosystem that happens not to do that, and often you don't even get a guarantee (order may be dictated by hash values that may be randomized in a good implementation). So we are moving SenML to something like: [ { ... metadata blob ... }, ... measurements ... ] (the details are still being discussed). Of course, in CBOR we could do: { { ... metadata blob ... }: [ measurements ] } i.e., use the metadata as the key for the map. Which is essentially what PHB is proposing, but that works in JSON only if the metadata happens to be a single string (which is the case in the example given by PHB). Back to the discussion about representation style: Preferring { "foo": { ... } } over { "type": "foo", ... } may or may not be compatible with the "struct"-style (see section 2 of for a definition of various styles of using JSON-like data models), depending on whether "foo" happens to be a constant in your implementation or you expect to encounter new values as you go along. Grüße, Carsten From nobody Thu Feb 4 07:52:49 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FDD1B31E6 for ; Thu, 4 Feb 2016 07:52:47 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 rxoXRn_YB2iu for ; Thu, 4 Feb 2016 07:52:46 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 317691B31E5 for ; Thu, 4 Feb 2016 07:52:46 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id r129so218299762wmr.0 for ; Thu, 04 Feb 2016 07:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=pP7G62in3Rwf5uaZaZMYW9djcfSbvIeCtVwHsht/I8Q=; b=LZJ+5K0FPV8bEgBikjMCCmZ4BQF1vXhneoac8PbMVcg/aMdailURieFvYxebmXVTFa xxReH3EpyKTU5eaEmQUIpeN+GvKDgy34/RusYfVNVDPpM/AlxO6iFlSWW7FgFpxYTglB UYmxZIuIPN1qGQRa0TR+rozuZQnLa5JHH2rt7dUXJXZ0vTVaUMu2LPRSZf3ojwq9GzJM dKXDdphFkFWdmrSD3pQeMZdeWySi0kUKrVHBQHmSYXMPuiwdiWWb5p82BNVwNLxkfEzy Y0Yf1h+j502SvN6pp8ynMjn7KFIF+DsJP/IuVwAXh1i1m/qpun01s0b4hUDBQonY9HDw tfxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pP7G62in3Rwf5uaZaZMYW9djcfSbvIeCtVwHsht/I8Q=; b=f6O1Q/KHOTtupDhJiPXuqy8KBqtD6lNcnl2qbH7nP924q3l4+J8mW2WvYSbRc1Lo1a TRENCkKyPthJxGJ0GH9LkBHJd6/ekE3bxbl6kGwuiz+8Xsvf6rRuWi0b3xXO2sPyTH0+ BE+ten6iJs7m7QFsePRHSP6MMVxiVndBSiafJvW9+jV0hZ5FJfmfk/Fk/1ghmUUC2WPl mA9MnKI+lObETp+gMlx1uTV73qe51JMonvOkCx0JwzG2uZsrbJ9x6ypeDBGGkf1Oji+S oAnQzb4FwHrTZsSbrniHcN/utjPttqdaXNbWDECd5wFZU2OYNV2x/fqScv5pQHgZuu5Q i6mw== X-Gm-Message-State: AG10YORh9wr99rcCcp2p1GY2LL4KcjDZy8wKdrN+OTE9ktb59AwVz4Gfdth9jsGPaQJXyg== X-Received: by 10.28.72.197 with SMTP id v188mr26601377wma.34.1454601164759; Thu, 04 Feb 2016 07:52:44 -0800 (PST) Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id z65sm3038622wmg.1.2016.02.04.07.52.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 07:52:44 -0800 (PST) To: Carsten Bormann References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> From: Anders Rundgren Message-ID: <56B373B8.7040305@gmail.com> Date: Thu, 4 Feb 2016 16:52:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B370A1.1050508@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Phillip Hallam-Baker , JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Feb 2016 15:52:48 -0000 On 2016-02-04 16:39, Carsten Bormann wrote: > Requiring the encoder to send data in a particular sequence is > theoretically possible, but in practice just means you lose that part of > the ecosystem that happens not to do that This ecosystem is rapidly diminishing since ECMAScript nowadays mandates strict insertion/declaration order for serialization. In addition, if you deal with signed data like specified by JWS, don't you anyway lose the ability to do smart sequential processing? That is, there are undoubtedly a bunch of applications where a nested scheme like proposed by PHB is the wat to go, but claiming universality would IMO be a bit of a stretch. Anders From nobody Thu Feb 4 07:58:16 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEA71B3088 for ; Thu, 4 Feb 2016 07:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 IYIBBQzOSE6A for ; Thu, 4 Feb 2016 07:58:14 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 B81CE1B31FE for ; Thu, 4 Feb 2016 07:58:13 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id m1so39787505lfg.0 for ; Thu, 04 Feb 2016 07:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RKoMh8XVdjrUEFHy5rvxKHipG+YrQgPNzYwqpZwVl/M=; b=fQkDag6iMRMRh6poK/bS7dBdAaqXlXgXOPdqExpEYkpJ6Yo+1I5KtU1hSY8ZgerSrn dzo/wMs9I4u6BLO9aGo1PHAjVNTTM3pbcUBn3W3B4lUfwhOvIHfd1OOcUGKCMfT4TzA5 B9R/lK6ufuooSbvtwXIa2jK/9N1DLFDWt13v8cmn0qs/+nqfeWjTnMKo072168pn7725 WQ5RFYvI6SggXMfOFhxpFkvZnV0tkTufBnlG2vH7FDq+Y79IZ6FZ/leY0lhq03uNrnOy 1glGNeic3XBquAhxv6rU2T2spUlYGmGkASp/SoE/mGYLbng/Bsg5Umz+TNQjoFIZ5zDh d9ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RKoMh8XVdjrUEFHy5rvxKHipG+YrQgPNzYwqpZwVl/M=; b=DK0IGUFS/+cnJuptej0CogbUhIieOLfJcxxiswEbokfOuGYWjaTjANFrOi+wxFp+pe RV5+5cq4do+d+b0bhE099BkIuK2YTtm0TmySA7X9j6+63PWadiLPtmPg2rwZLtLSGxhC 9KCI3rmfSJEOGzOOunZeMNiuLoj3Ckvu+Z0aGAba5U1A6EhsPYQpFOqFo2iskhhB86eS Quo3hE16uIK7l/Pfr4i2OYZlrFxl7AJupYUZ9PgjiM/iun4kldHidJf8QbGpsREtPEP1 JMO9QTU1rKqhvvvoLQvjUJXL8hxTIhh9dRDNe0O5iof9ZI3qgu8smcetSWY5k4Y40YQH wpDw== X-Gm-Message-State: AG10YORTCf9XU1uXgFHz90ahEIU/m/n0zjhyTtXKVCuMY5UXYKcG0N0xwgtraaii7j2TApJ8IlprKd8n1cqhZw== MIME-Version: 1.0 X-Received: by 10.25.22.231 with SMTP id 100mr3771565lfw.153.1454601491948; Thu, 04 Feb 2016 07:58:11 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Thu, 4 Feb 2016 07:58:11 -0800 (PST) In-Reply-To: <56B370A1.1050508@tzi.org> References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> Date: Thu, 4 Feb 2016 10:58:11 -0500 X-Google-Sender-Auth: 1nHtrsHsjan07Lk2nQC1mOjl4-0 Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: JSON WG , Anders Rundgren Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Feb 2016 15:58:15 -0000 On Thu, Feb 4, 2016 at 10:39 AM, Carsten Bormann wrote: > Anders Rundgren wrote: >> Anyway, isn't CBOR what people are targeting for constrained devices? > > Yes, but the desire to be able to do sequential (as opposed to > DOM-based) processing goes beyond constrained devices. Exactly. Every device is constrained when you send it a big enough problem. I did think of mentioning CBOR but for another reason. A lot of times you are going to want to apply a protocol that has already been designed for JSON to a constrained device. This is one of the reasons I argued that there should have been a WG to design an efficient binary encoding. My objective was to be able to indicate the 'binary' version by specifying application/json-b without having to make any other change. I think it likely that people will want to do the same with CBOR. But that is a lot harder if doing so requires the structure of the parse tree to be 'messed about'. I would much rather that we have a style guide that guides people towards an approach that is flexible. Carsten's example does demonstrate a more general version of the same problem. But I don't think it is quite as critical. Because what I am talking about here is mapping JSON data to objects in strongly typed languages. And all the strongly typed declarative languages I am familiar with (and I know a very large number) have a type system that can be reduced to text label. [Yes, I did functional programing, we did Orwell. But I have yet to unpack a widely used open source tool to find that it was written in F#, Oberon, or any other from that family] From nobody Thu Feb 4 16:17:28 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381E71ACDD0 for ; Thu, 4 Feb 2016 16:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 7oNKYmew6z6X for ; Thu, 4 Feb 2016 16:17:25 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134791ACDCC for ; Thu, 4 Feb 2016 16:17:24 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1aRU5N-0003vN-TN; Thu, 04 Feb 2016 19:17:18 -0500 Date: Thu, 4 Feb 2016 19:17:17 -0500 From: John Cowan To: Anders Rundgren Message-ID: <20160205001717.GC2997@mercury.ccil.org> References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B373B8.7040305@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Carsten Bormann , Phillip Hallam-Baker , JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 00:17:26 -0000 Anders Rundgren scripsit: > This ecosystem is rapidly diminishing since ECMAScript nowadays mandates > strict insertion/declaration order for serialization. That affects only ECMAscript implementations, though, so there are no such guarantees on the server side, or server-to-server, unless Node.js or something similar is being used. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org If you have ever wondered if you are in hell, it has been said, then you are on a well-traveled road of spiritual inquiry. If you are absolutely sure you are in hell, however, then you must be on the Cross Bronx Expressway. --Alan Feuer, New York Times, 2002-09-20 From nobody Thu Feb 4 17:09:59 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391BF1B2BAE for ; Thu, 4 Feb 2016 17:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 tfCfmzKsW0gV for ; Thu, 4 Feb 2016 17:09:57 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 180F71B2BA2 for ; Thu, 4 Feb 2016 17:09:57 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id j78so47839328lfb.1 for ; Thu, 04 Feb 2016 17:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=BNH/hnN0TnRcAR6DRcvLHLSnEEq+xtVAzxBKzTm+Xl0=; b=jmKarLewHbJZ/vLgitwee1PS9K4GbjiFuvekkjnBH/PlT+EDLM5oM7jKGNRdMDge0G d08HLRk6req6dQCV3aRtE7vVChRlX1T0aT/IAhM2waQacCWNfaOXTNcXlVLIoKNMYmB9 54T0ZJWEW3FLm/6ugPQR2mPEu7WVh/NxNkDM7s6FftQy9H8WlwS1O050QnKsYff4ZcgL Vtw+mpEwscG8dYpWKyLftHqeBxRGn47tFp2t41MywmmPyQrfhULiJ5p8aj/97yC+NwAy R0YdPCzExL1f5YJKkHJG6yn5l4TPiuxyN9H80lhBOnBB9vkaJgGUqPFYp6dpYs9GB6+t gU6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BNH/hnN0TnRcAR6DRcvLHLSnEEq+xtVAzxBKzTm+Xl0=; b=UCwy0HbFi3HymuTXS7JhSqCtC1w3MkzPTAbWVpdAZ88KGs8BwLred8vR/tEPyttldC RafoEjVQpQd9THHeCEcCAgM55LadijlQGyv1AE/Enxy6MG17MeF22UdAPhs/hp8aHxYR x6Da7ixbLFpLoimv8GgPmSpvHYf5t4SPusTFQn8NCo6pQJhInNn753yy4cG60gHK6zlB TrBeNbovJtt823gpEgTyYsu1bpVztEt9uTGThZLESoOgAo3mN5bn4aFbd4RtZfA46/B4 rJRSg8IaBYsEG3iXHsZnBX8zyW+aDCqIz5NS9kutwYybkRfmKyvuVuZiWZNSb+b2qnSI 6SjA== X-Gm-Message-State: AG10YORz2pIJ24KO11L3mzmzdZ1bSDogAt3dnI4Ai/FC0/gFvUFDcicl4IP7ykL5LreyOJNxZqyR1EUnr3AGKw== MIME-Version: 1.0 X-Received: by 10.25.156.198 with SMTP id f189mr4777925lfe.70.1454634595299; Thu, 04 Feb 2016 17:09:55 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Thu, 4 Feb 2016 17:09:55 -0800 (PST) In-Reply-To: <20160205001717.GC2997@mercury.ccil.org> References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> Date: Thu, 4 Feb 2016 20:09:55 -0500 X-Google-Sender-Auth: vFIRpeyZUfqZm3MuQ85k-xwmuBk Message-ID: From: Phillip Hallam-Baker To: John Cowan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Carsten Bormann , JSON WG , Anders Rundgren Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 01:09:58 -0000 On Thu, Feb 4, 2016 at 7:17 PM, John Cowan wrote: > Anders Rundgren scripsit: > >> This ecosystem is rapidly diminishing since ECMAScript nowadays mandates >> strict insertion/declaration order for serialization. > > That affects only ECMAscript implementations, though, so there are no such > guarantees on the server side, or server-to-server, unless Node.js or > something similar is being used. +1 We are doing RFC7159 JSON. Order is not guaranteed. A sender can emit the request in any order they like. Code that depends on the order of elements within an object is broken. From nobody Thu Feb 4 22:23:37 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62D01B3658 for ; Thu, 4 Feb 2016 22:23:35 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 dzpzIGWi6DT9 for ; Thu, 4 Feb 2016 22:23:34 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 EE92C1B3657 for ; Thu, 4 Feb 2016 22:23:33 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id 128so56956021wmz.1 for ; Thu, 04 Feb 2016 22:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=pfQ47WiLLw2qa0Tn254nf9RkUhbJ91vEixroqLpwJns=; b=XikGoraWVAajBB4bspsRyG+7oYD8M85nJUF68pvMrm2X/z9jVW995SKk4oo62xpQEM VYkU5utBy6sRshJj6K9m+UgAcwe6D4rayjiuFCXD9uGGi/ijxVQp4UDj4JtOdW0slboO sy4fWSLqLI0mTwFIGBYpIzI7uBX+EFK9y7kGMZ+t8X/QOi10p8NapkZiiL0odvYnKq// 54B/KRyvYTCRUj/39xRBuFOPXbCjXcooqHzxaJnBeSwwsjjAhp9Eeib0tqZ+8N8Jv83X kUYet0O1wgMPUSnxO0T/r8+spiu3XQn8xlOy2/J6FzCDjhB7+Fm8iD5TPR+SbUUTMi5h 4k/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=pfQ47WiLLw2qa0Tn254nf9RkUhbJ91vEixroqLpwJns=; b=BTXwKem8BcczyRghhZdFKWOS7h4FA3dB3+SYZeVbUXTyxQ9QRMeaIRlxU3bcxaxK4C vng3EpDIluozaLFsMa5efnfw20o8Z1hdKrhj78/Bd8Y4tJLZeFrBrAuNQQ69uLzhxkB3 N1ZizjfcMfdgr+XR5Kc7FMRKzMyfLDAUqve2RARolxqajJPYZPP3FSD9zOHnnb+Urt4e BtCNsWecE8Tk3I8iKH0FCx5OeRuhqIHH1wAtULswb92lRUcscIlbMXaWCp0E9kHQ6VVt /0TMgvuZTvy12PucInsdlUrs3NUG2ExhsfomImp4T6dE4WqNsOCjwN+4BvF9X0N732Su 9edA== X-Gm-Message-State: AG10YOTKus7mg3NnnncaZqXadIoNoq4VkiugiY17m/jSkzVXSgabc3TTn/uQ5FOYMjztvw== X-Received: by 10.194.21.101 with SMTP id u5mr14076174wje.53.1454653412569; Thu, 04 Feb 2016 22:23:32 -0800 (PST) Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id w136sm29394100wmw.0.2016.02.04.22.23.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 22:23:31 -0800 (PST) To: Phillip Hallam-Baker , John Cowan References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> From: Anders Rundgren Message-ID: <56B43FCE.6080408@gmail.com> Date: Fri, 5 Feb 2016 07:23:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Carsten Bormann , JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 06:23:35 -0000 On 2016-02-05 02:09, Phillip Hallam-Baker wrote: > On Thu, Feb 4, 2016 at 7:17 PM, John Cowan wrote: >> Anders Rundgren scripsit: >> >>> This ecosystem is rapidly diminishing since ECMAScript nowadays mandates >>> strict insertion/declaration order for serialization. >> >> That affects only ECMAscript implementations, though, so there are no such >> guarantees on the server side, or server-to-server, unless Node.js or >> something similar is being used. > > +1 > > We are doing RFC7159 JSON. Order is not guaranteed. A sender can emit > the request in any order they like. Code that depends on the order of > elements within an object is broken. Well, the W3C Web Payment IG/WG folks who claim they are working with a new (and presumable secure) system for the Web Payments have not yet begun dealing with how they are going to sign their JSON messages. This will be a litmus test, not for RFC7159, but for RFC7515: https://github.com/golang/go/issues/14135#issuecomment-177265555 In the meantime, I'm helping JSON tool-vendors providing support for "Predictable Serialization" a la ES6/V8. With the sole exception of "Number", this is not rocket science and that particular rocket has already been built by Google and the blueprints are readily available as well. Maybe we can come back to this issue in 18 months and see where it went? Anders From nobody Thu Feb 4 23:35:35 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611BD1A0062 for ; Thu, 4 Feb 2016 23:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 KsDKQ75Vn_O3 for ; Thu, 4 Feb 2016 23:35:32 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 B39791A0060 for ; Thu, 4 Feb 2016 23:35:32 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id g73so120366056ioe.3 for ; Thu, 04 Feb 2016 23:35:32 -0800 (PST) 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:content-type; bh=K1Iq3xXyDyikDlSBoOWDIQW0g2zItjCCtEYcamL+tUY=; b=KIZe5O4CFLXk8WkH3yk/nX6TRS8rQ10Nulv40hbMW2UJ+8VpRF5sMGscoNmwZ6zi5J shgqip3YGebdYuVIV+HUCv3PLkonq2cOoG/loE0BhonYm59a7yhPI7TzLOtI/Ko6BINh ht1hi3A+K2G4C1WSQktPVtGiKvvvMqruax2dgDy6dEfG+H91rDjBm7kL7LGhOqdpMDB4 ncJyc7mhyVf6A6DZngrdiA+q6ltBEL0NItl/9VcmzsS2ttPbZcp8M5myxz5F24x8iYKE OCbPDSYnnXchBb5vDMoHtutwoZxg7p+BtMAldHKfn5v5kfX91kEZnd1Hlp9KQX/Klz0V D2Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=K1Iq3xXyDyikDlSBoOWDIQW0g2zItjCCtEYcamL+tUY=; b=WdhCx+LO/t4Ecn3Efjvskq8y1XA6WR8up8cdQj96f8zZVTZhc4qZ1wU9fiVYzFVJS5 LXfrZ46SVh/6PPWUgxzAaT09qXERnQNbA8vi1ZlcIekAdB4Mw0K/RJyw/IVzk3xMDBzU PUjPw0D0FTOmrLzWQYsy0xpJaZ/sEc4eRe6Mu0uZE2nR2p9wq+WSNySNkCBNhfO3WKAT YvdS7Nb5CRe+9DpXb3nuD0joUBDB4ogDf33GUKvEJ9e27NGSENOL+PpS8V5Vzgn4DF+4 Y73PdfjPRmR1DMuGpGNMzweFsqpg54bPiPkL7Nh0GURRyYhLoUHdJXm7gGKWgna8q0oa v/VA== X-Gm-Message-State: AG10YOSD/ZKgCw3uOURcJL39ZqzOPd58jZMFYdwAUcw5nfsli59t2XNCUBTJJ3eiDrTTTRKhu0VoVTED3giJLQ== X-Received: by 10.107.47.227 with SMTP id v96mr15589751iov.65.1454657732093; Thu, 04 Feb 2016 23:35:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.90.68 with HTTP; Thu, 4 Feb 2016 23:35:12 -0800 (PST) X-Originating-IP: [24.84.248.61] In-Reply-To: <56B43FCE.6080408@gmail.com> References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <56B43FCE.6080408@gmail.com> From: Tim Bray Date: Thu, 4 Feb 2016 23:35:12 -0800 Message-ID: To: Anders Rundgren Content-Type: multipart/alternative; boundary=001a11c168fa644bd5052b00e5ac Archived-At: Cc: Carsten Bormann , Phillip Hallam-Baker , John Cowan , JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 07:35:34 -0000 --001a11c168fa644bd5052b00e5ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, over at AWS, I=E2=80=99ve just helped launch an experiment in doing t= hings at a large scale exactly the way PHB recommends against :) Check out our =E2=80=9CCloudWatch Events=E2=80=9D JSON at http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CloudWatc= hEventsandEventPatterns.html We have millions & millions & millions of these flowing through the pipes already, with many more to come. On Thu, Feb 4, 2016 at 10:23 PM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2016-02-05 02:09, Phillip Hallam-Baker wrote: > >> On Thu, Feb 4, 2016 at 7:17 PM, John Cowan >> wrote: >> >>> Anders Rundgren scripsit: >>> >>> This ecosystem is rapidly diminishing since ECMAScript nowadays mandate= s >>>> strict insertion/declaration order for serialization. >>>> >>> >>> That affects only ECMAscript implementations, though, so there are no >>> such >>> guarantees on the server side, or server-to-server, unless Node.js or >>> something similar is being used. >>> >> >> +1 >> >> We are doing RFC7159 JSON. Order is not guaranteed. A sender can emit >> the request in any order they like. Code that depends on the order of >> elements within an object is broken. >> > > Well, the W3C Web Payment IG/WG folks who claim they are working with > a new (and presumable secure) system for the Web Payments have not yet > begun dealing with how they are going to sign their JSON messages. > > This will be a litmus test, not for RFC7159, but for RFC7515: > https://github.com/golang/go/issues/14135#issuecomment-177265555 > > In the meantime, I'm helping JSON tool-vendors providing support for > "Predictable Serialization" a la ES6/V8. With the sole exception of > "Number", this is not rocket science and that particular rocket has alrea= dy > been built by Google and the blueprints are readily available as well. > > Maybe we can come back to this issue in 18 months and see where it went? > > 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) --001a11c168fa644bd5052b00e5ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wel= l, over at AWS, I=E2=80=99ve just helped launch an experiment in doing thin= gs at a large scale exactly the way PHB recommends against :) =C2=A0Check o= ut our =E2=80=9CCloudWatch Events=E2=80=9D JSON at=C2=A0http://docs.aws.amazon.com/AmazonCloudWatch/latest/De= veloperGuide/CloudWatchEventsandEventPatterns.html =C2=A0

We have millions & millions & = millions of these flowing through the pipes already, with many more to come= .

On T= hu, Feb 4, 2016 at 10:23 PM, Anders Rundgren <anders.rundgren= .net@gmail.com> wrote:
On 2016-02-05 02:09, Phillip Hallam-Baker wrote:
On Thu, Feb 4, 2016 at 7:17 PM, John Cowan <cowan@mercury.ccil.org> wrote:
Anders Rundgren scripsit:

This ecosystem is rapidly diminishing since ECMAScript nowadays mandates strict insertion/declaration order for serialization.

That affects only ECMAscript implementations, though, so there are no such<= br> guarantees on the server side, or server-to-server, unless Node.js or
something similar is being used.

+1

We are doing RFC7159 JSON. Order is not guaranteed. A sender can emit
the request in any order they like. Code that depends on the order of
elements within an object is broken.

Well, the W3C Web Payment IG/WG folks who claim they are working with
a new (and presumable secure) system for the Web Payments have not yet
begun dealing with how they are going to sign their JSON messages.

This will be a litmus test, not for RFC7159, but for RFC7515:
https://github.com/golang/go/issues/= 14135#issuecomment-177265555

In the meantime, I'm helping JSON tool-vendors providing support for "Predictable Serialization" a la ES6/V8.=C2=A0 With the sole exce= ption of
"Number", this is not rocket science and that particular rocket h= as already
been built by Google and the blueprints are readily available as well.

Maybe we can come back to this issue in 18 months and see where it went?

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)
--001a11c168fa644bd5052b00e5ac-- From nobody Thu Feb 4 23:41:28 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94C71A009F for ; Thu, 4 Feb 2016 23:41:27 -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] autolearn=ham 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 D9XKleb4LImx for ; Thu, 4 Feb 2016 23:41:26 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CCA51A009E for ; Thu, 4 Feb 2016 23:41:26 -0800 (PST) Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 9435941C09C; Fri, 5 Feb 2016 08:41:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ArhRVSEgcytD; Fri, 5 Feb 2016 08:41:23 +0100 (CET) X-Originating-IP: 93.199.254.229 Received: from nar.local (p5DC7FEE5.dip0.t-ipconnect.de [93.199.254.229]) (Authenticated sender: cabo@cabo.im) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id AF1FA41C089; Fri, 5 Feb 2016 08:41:22 +0100 (CET) Message-ID: <56B45220.7080602@tzi.org> Date: Fri, 05 Feb 2016 08:41:20 +0100 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Anders Rundgren References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <56B43FCE.6080408@gmail.com> In-Reply-To: <56B43FCE.6080408@gmail.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 07:41:28 -0000 Anders Rundgren wrote: > 18 months JSON has been around for more than a decade. It would take another decade for a change that goes so deep into the fundamentals to become widespread (and sufficiently debugged* on enough platforms to become reliable). Wake me up when, say, ArduinoJson supports your form of canonicalization. Grüße, Carsten *) Decimal number representation code is hard. (I'm too lazy to look up the CVEs to provde this.) Even sorting text is not exactly easy. From nobody Fri Feb 5 00:53:54 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BB81A90B4 for ; Fri, 5 Feb 2016 00:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nedTxZQKVwYz for ; Fri, 5 Feb 2016 00:53:51 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A491A90AB for ; Fri, 5 Feb 2016 00:53:51 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1aRc9E-0005dP-Qn; Fri, 05 Feb 2016 03:53:48 -0500 Date: Fri, 5 Feb 2016 03:53:48 -0500 From: John Cowan To: Carsten Bormann Message-ID: <20160205085348.GA20086@mercury.ccil.org> References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <56B43FCE.6080408@gmail.com> <56B45220.7080602@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B45220.7080602@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: JSON WG , Anders Rundgren Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 08:53:52 -0000 Carsten Bormann scripsit: > *) Decimal number representation code is hard. (I'm too lazy to look up > the CVEs to provde this.) Even sorting text is not exactly easy. Decimal number representations are a well-solved problem in the Scheme community. See for the code. The references provide the background. For canonicalization, sorting text based on lexicographical code point order is the Right Thing, and that's well-understood too. The only trick is to make sure not to sort by 16-bit code units, as it gives a different answer when comparing characters above U+FFFF with those in the range E000-FFFF. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org But you, Wormtongue, you have done what you could for your true master. Some reward you have earned at least. Yet Saruman is apt to overlook his bargains. I should advise you to go quickly and remind him, lest he forget your faithful service. --Gandalf From nobody Fri Feb 5 01:06:36 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F901A910E for ; Fri, 5 Feb 2016 01:06:35 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 SXrxq1xbnGk4 for ; Fri, 5 Feb 2016 01:06:33 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 6AB3E1A90EE for ; Fri, 5 Feb 2016 01:06:33 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id p63so17017929wmp.1 for ; Fri, 05 Feb 2016 01:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=HNeRb3mp5ELHQ0DjUTHuXJCJ3EOeRHwb8jD4ZljAXcM=; b=urwBRpp5JoWxrwSt0VLqakip5DLmgMVmSKCciHh7jKJFXm/Nyt8Kf5nVPwETRxiApd Zuc4/R/S8BnF+CYwd/bwr+NjOt6gnFg4aUQrnTZ2LRfrILaweQG1+h2bDAozhvd+LctW qSXRWle7thHFjBrA58WuZd2mcjtBhhb9BkMhS5LBgGtjkZ7sV2EG1NYiuC+ATys4SXo9 CMy668+64RJJ7vIrt7V4IY74bR9gjLRfU/nWRl/24XFjdq845WVbNuro/ZWKkklk4VBO p9SKmh2cDrJ1b0SaTxnDq5QQocTi91IHkYKT9aST3phdx2U74k0S3cv3a3Q3EE5fv/wb tIug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=HNeRb3mp5ELHQ0DjUTHuXJCJ3EOeRHwb8jD4ZljAXcM=; b=DpDbeTfC1sR6OJ1qENGCAJJLj9OquOH6DoLyfU+sllfefpiqpQ+Nlu+5Ln62r2MaNy onbWGtEwnLpfrQUAAumjE/dwfH18TVr2/htpXq+m20zUblXEzWMlZc7DApyz/z3wL+JG mqbhCtozil94Za7n+MWS7hCIKcQM1idXOTVWvQkubYL2RucjotqQ+UMKLG/W4OU+2k5p E5QP7ro648DvwCxrO8T6ir7A3RQqpMQpwfqMRXQ6Lp4Oqc1chFSJehK0S6XU8jF66klG IVeA4TxT5YjLEZOooDGjcniyI9nSr2//xyNotr6GujXJu+dXLCrrq4tiSepA9mW2EKJY 39/A== X-Gm-Message-State: AG10YOS2Nx6U06Lfl4fdcsh9WmQ8szNVzB6nvuwwiMVR91Rc/PLtUARczIkGRjCQ5frBNQ== X-Received: by 10.194.104.198 with SMTP id gg6mr12001307wjb.84.1454663191981; Fri, 05 Feb 2016 01:06:31 -0800 (PST) Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id kb5sm14995376wjc.22.2016.02.05.01.06.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 01:06:31 -0800 (PST) To: Carsten Bormann References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <56B43FCE.6080408@gmail.com> <56B45220.7080602@tzi.org> From: Anders Rundgren Message-ID: <56B46602.6090901@gmail.com> Date: Fri, 5 Feb 2016 10:06:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B45220.7080602@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 09:06:35 -0000 On 2016-02-05 08:41, Carsten Bormann wrote: > Anders Rundgren wrote: >> 18 months > > JSON has been around for more than a decade. It would take another > decade for a change that goes so deep into the fundamentals to become > widespread (and sufficiently debugged* on enough platforms to become > reliable). I have successfully tested Chrome, Firefox, Safari, My Java library, and a Python patch against a file with 100M of random and selected IEEE 64-bit values. > Wake me up when, say, ArduinoJson supports your form of canonicalization. There are different markets with different needs and traditions. Must they all use the same standard(s)? An acquaintance of mine working for a major IoT vendor (who is very active in the IETF/JSON space), claims that the IoT market rather will go for CBOR. FWIW, I'm claiming that the Payment industry won't buy into JOSE, they will probably build something of their own and ES6/V8 serialization makes that a viable option. PHB also seems to be experimenting with ways to get around the Base64URL dogma: https://mailarchive.ietf.org/arch/msg/acme/hLmlH1lEEQ2GgkhgDnl5bbhhNXQ Standards are fun...the more the merrier! :-) https://xkcd.com/927/ Regards Anders > > Grüße, Carsten > > *) Decimal number representation code is hard. (I'm too lazy to look up > the CVEs to provde this.) Even sorting text is not exactly easy. > From nobody Fri Feb 5 06:02:00 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D041B3918 for ; Fri, 5 Feb 2016 06:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 Ze27lxlCPxpS for ; Fri, 5 Feb 2016 06:01:58 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::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 A73EA1B3917 for ; Fri, 5 Feb 2016 06:01:57 -0800 (PST) Received: by mail-lb0-x231.google.com with SMTP id bc4so49988448lbc.2 for ; Fri, 05 Feb 2016 06:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=9bCHkAD4GiazVcxz0bxeDFcLbJVjrnH5Y0POfK6EPkw=; b=PQFrmyfzSyPHtom62qakf9vQ9L992rO8n+DtN4u6Xq/UeyoARet+iOBcfrNenlcIjm NOYibiHUPAGtseXnfozY9MFrb8lw+4jZnPdgwTaOJeU3FH9vgC0cirM5CpLfWfnoWcvZ NyN57Wt6SizgTuaxfUqLCJHFoSMfqES1Slz9KV25u52xUK5Swzp/bdXm4TZF6cP+RpKB KZNyS6bOKuUw8o6Haya1Gej2ik2Q1EYQNlO8rCP5gm945j4XeK8mSYWllLZPhCwPi/3H gXqCsR6odM6+JH4SGKTr4ql4YMrRexg4QlGM0i0CUT7U3T02qE7wFCQ5pH43szc59svU 1i4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9bCHkAD4GiazVcxz0bxeDFcLbJVjrnH5Y0POfK6EPkw=; b=e0HSGRmp6/inRx+O4rq6pr6lAbjnKewlKs2P/KhYbmsq6QMyTdOZ8gAnYf8ZYEknFl vA4NDZYlXQrp7LSJHtk4/t32E9LlpVj7RfMOzpCERhITe5y6phFwnO8kXmKLGzYiojBA IVLko/UwySIS9tQ3TJSSx3Z8j0lKaTdVGDUFHahl1sbgDJAIH/Rak9HJft3SU3YMO7X5 08pgsGBMTT1qsw8Ib+QfGKNakcmarvlhRFMJvCCCEWlF1cr2JBJOd8/Z+mNn5iPRiXLg 2TllOJHtvToo1eRg4mWUbYdHwldGV3g2QuuY1qNPfbkRtgoQiSiF5NUwaQNeKVY4eyvq eLYQ== X-Gm-Message-State: AG10YOTaLcN0HAzFTk5VQuZMKDYJgzGvOAbgemyNo5nWZ/E0s5leyZXOiYKS9t16azyib9msTIX4MAjlXbyurQ== MIME-Version: 1.0 X-Received: by 10.112.141.97 with SMTP id rn1mr6446061lbb.80.1454680915872; Fri, 05 Feb 2016 06:01:55 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Fri, 5 Feb 2016 06:01:55 -0800 (PST) In-Reply-To: References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <56B43FCE.6080408@gmail.com> Date: Fri, 5 Feb 2016 09:01:55 -0500 X-Google-Sender-Auth: QWJHPjQ3BUVjGOlynyvAkyQVeoE Message-ID: From: Phillip Hallam-Baker To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Carsten Bormann , JSON WG , John Cowan , Anders Rundgren Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 14:02:00 -0000 On Fri, Feb 5, 2016 at 2:35 AM, Tim Bray wrote: > Well, over at AWS, I=E2=80=99ve just helped launch an experiment in doing= things at > a large scale exactly the way PHB recommends against :) Check out our > =E2=80=9CCloudWatch Events=E2=80=9D JSON at > http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CloudWa= tchEventsandEventPatterns.html > > We have millions & millions & millions of these flowing through the pipes > already, with many more to come. If you use a particular tool and that is the only one you understand, you won't see the problem. This is a standards organization. So the architecture should impose the fewest constraints on implementation as possible. Very small changes in implementation can make a huge impact on implementation. The reason ASN.1 is hated with a passion by pretty much all crypto folk who have implemented it is one line in the definition of DER encoding. The use of definite length encoding over indefinite length had virtually no impact on X.509v1. Either could have been chosen as canonical. The one they chose has a dramatic impact on complexity of the implementation in X.509v3. What you are arguing for is that you want to write your structures like thi= s struct fred { int a, int b, int c} { "a" : 1, "b" : 2, "type" : "fred", "c" : 3} Now you might think that is a reasonable way to present the data in a spec but most of us would say that it is hard to follow. The important information of the type of the structure is buried in the serialization stream. What is hard for a human to work out imposes unnecessary constraints on computer implementations. It makes JSON a special case for no good reason. I have a tool that can serialize/deserialize to JSON, ASN.1 or XML from a schema that is essentially just a description of the data types to be passed on the wire. It doesn't support unrestricted XML and implementing PKIX requires the schema to be decorated with additional information to define encoding details. The reason I like JSON is precisely the fact that right now, it does not require any decoration and the only constraint it imposes is that the tag to describe the data structure precede the data being described. From nobody Fri Feb 5 07:10:47 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D031B3A3E for ; Fri, 5 Feb 2016 07:10:45 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 TQWNpra9lvap for ; Fri, 5 Feb 2016 07:10:39 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 89F8A1B3A37 for ; Fri, 5 Feb 2016 07:10:39 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g62so52077457wme.0 for ; Fri, 05 Feb 2016 07:10:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=7LSjKb/UFa4A91ObKx9JSz7nohATFyXUo1K1dsU+NxY=; b=ItqKWJruBg3tzMwVvgo3sKUmNyI61KXllsCNnzfLuEU2QCV6ENnmKK4TsDEJn84PG+ +A7S0mYpMzyNfoHstHc9D2vUHwTOK2PIkRyQIEYwjLBpU1YrWY2E2O5LPDbc8Hr1u3+A ObunEDaiu1EAmReuhGUOI1DvtspmOa9kdwKoK1jbA5z8Khmp0xBed2EWRdfajYqZaPnH /tdN5pAvyZvgSFfM2Xzxnp4WEiBOR2Jyf/ddzCKx3JhCKkKrFKBJYvjbz+SeXGEm70g/ Pqneyl7IYFUwMy6mVRfHJrweSS9dwu0Dml95OHz9/E+ex+HCaG3XnolLIEWEqpnfy/C0 86tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=7LSjKb/UFa4A91ObKx9JSz7nohATFyXUo1K1dsU+NxY=; b=OyzXWJvmevGylm36dLGq5EiuaikiM6bFqZrBo7HX0aDuEBs5cgpVj52Thf3ibIKZmw D/LqdQV7YZdyCSsG5WVT5+ipe5Vkx0AS2QGTLi9v/wZ7P5k+30B1JZDTJnKBqOrqnocg S13p7yyCYYv6e/1zjjY+9byNaX7WmLFevTaw0yC/6xb8RSB3hWt33T3c9XRCaA6QQntf 7rJZcqI1APhV+KKv9NjbIwKeJy8QfSzhCRkVexUsns31E/kst8IyBF4dRYNLd6P6+oLl 21QWthOsRT3koFx8sAZpp2pSgUF43Z1cTXDm0eDzZXYGnNRREjBxguZyD0JTu3L7S4/x ghDg== X-Gm-Message-State: AG10YOSNtPItfwDxk7XeWUYKio2Ha6/11FO1Ccov7wuBnQK1jRndHzT6nBtKFB7VNaT91Q== X-Received: by 10.194.117.169 with SMTP id kf9mr14741760wjb.122.1454685038167; Fri, 05 Feb 2016 07:10:38 -0800 (PST) Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id uo9sm16285561wjc.49.2016.02.05.07.10.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 07:10:37 -0800 (PST) To: Phillip Hallam-Baker , Tim Bray References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <56B43FCE.6080408@gmail.com> From: Anders Rundgren Message-ID: <56B4BB58.4010104@gmail.com> Date: Fri, 5 Feb 2016 16:10:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Carsten Bormann , John Cowan , JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 15:10:45 -0000 On 2016-02-05 15:01, Phillip Hallam-Baker wrote: > What you are arguing for is that you want to write your structures like this > > struct fred { int a, int b, int c} > > { "a" : 1, "b" : 2, "type" : "fred", "c" : 3} > > Now you might think that is a reasonable way to present the data in a > spec but most of us would say that it is hard to follow. The important > information of the type of the structure is buried in the > serialization stream. I fully buy into the efficiency aspect of the nested encoding style (which I honestly had never thought of), but when it comes to "hard to follow", predictable serialization a la ES6 seems like a more universal solution since this also sucks: { "city": "Paris", "name": "John Doe", "country": "FR", "zip": 245333 } ES6 serialization and the nested encoding style scheme can easily be combined, hopefully bringing out the best of both worlds! Anders From nobody Fri Feb 5 08:27:56 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B01B31EA for ; Fri, 5 Feb 2016 08:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 ToACebwD1OqI for ; Fri, 5 Feb 2016 08:27:53 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 70CAA1B31E5 for ; Fri, 5 Feb 2016 08:27:53 -0800 (PST) Received: by mail-lb0-x234.google.com with SMTP id cw1so52494015lbb.1 for ; Fri, 05 Feb 2016 08:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UTkG16+QdMYEWaP0gjOYW7wj2GmlkOFX52iTGab39mM=; b=QUqiyUflJtNMfayx/xrywfUr0+AKBiavTJ4eRKMdF6CvtoZHx6TuwyNtC2CvMEcYTt FOSt7Ts5kqKpUVpQ3gA+hER+PEp5t5V7Qw2R1LBH5S7EWkggtCDcwJeKI/0xZ5V+/ZOA 3PLHNua3Lghsy0vg27NHAB0LY6y9PPt6NeLfmpfNTjpU8fB3CsFbfbemuoU8tFF5BR6Y D9V3IAsfn8+xkulyR7W+0xqRGDjatePeA5souLcT27QdxfwPt1uy2p8btCByGveeQ9qe kXSPPsUR97Q4IGhWT/uRPIMunR39lZxJ+7tfeeu5z73gU9kGzTkTA79kHkcuvkiamGhZ 9bng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UTkG16+QdMYEWaP0gjOYW7wj2GmlkOFX52iTGab39mM=; b=bOih84kuKfhK4VVsntRKCDYF0wlFCChYnImLDweR3xNk5h8VErxfVrUnRiJmZpr2r8 jDFCJN37+huZ1x9XurUJa/+jr8kF71lhtn7h5+vwkETt0G/ACxowgfIB93P50oiqjc/S 2CNJiixBAxFPU1/muESGu6Ayu+OoNhntf90Sk3CtjaQYZQcAfHiVwkqMrwTheC1XWZJP pbbuikQeC2gWkHwfzaI9pIctSNr3UXluG4MOmjGS0PTTtXiXJCz6MU9XTZGrVqqz1W4g g8TS/bkOVwYKtIQD8uosKws5NyuZt+q3WvqQizXYelJIdfmSINEoKbevXXFTaOu4lUXH Zqvw== X-Gm-Message-State: AG10YOTDdQnYYfo5tP8Vbb/mz/YmrkB3zMh4YPUfSp2A1M2x9QoQYpdQjT1JpuDGmzPCN/NzdNiDZl/qk25lOA== MIME-Version: 1.0 X-Received: by 10.112.166.100 with SMTP id zf4mr6365711lbb.58.1454689671664; Fri, 05 Feb 2016 08:27:51 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Fri, 5 Feb 2016 08:27:51 -0800 (PST) In-Reply-To: <56B4BB58.4010104@gmail.com> References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <56B43FCE.6080408@gmail.com> <56B4BB58.4010104@gmail.com> Date: Fri, 5 Feb 2016 11:27:51 -0500 X-Google-Sender-Auth: DFgnnMX-B-HUyGrLlLu1tDHVBKU Message-ID: From: Phillip Hallam-Baker To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John Cowan , Carsten Bormann , Tim Bray , JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 05 Feb 2016 16:27:55 -0000 On Fri, Feb 5, 2016 at 10:10 AM, Anders Rundgren wrote: > On 2016-02-05 15:01, Phillip Hallam-Baker wrote: > >> >> What you are arguing for is that you want to write your structures like >> this >> >> struct fred { int a, int b, int c} >> >> { "a" : 1, "b" : 2, "type" : "fred", "c" : 3} >> >> Now you might think that is a reasonable way to present the data in a >> spec but most of us would say that it is hard to follow. The important >> information of the type of the structure is buried in the >> serialization stream. > > > I fully buy into the efficiency aspect of the nested encoding style (which I > honestly had never thought of), but when it comes to "hard to follow", > predictable > serialization a la ES6 seems like a more universal solution since this also > sucks: > { > "city": "Paris", > "name": "John Doe", > "country": "FR", > "zip": 245333 > } > > ES6 serialization and the nested encoding style scheme can easily be > combined, > hopefully bringing out the best of both worlds! There are probably valid use cases for a canonical serialization format. And that is probably more viable in JSON than in XML. However, I am very very skeptical of the benefit of canonicalization for digital signatures. I have been in countless meetings where this has been asserted as a requirement and I have never once heard a plausible argument. Emit the bits then sign them. BTW, yes I am working on a way to avoid the wrapped Base64-url encoding: https://tools.ietf.org/html/draft-hallambaker-json-web-service-01 This is part of The Mathematical Mesh which is described at http://prismproof.org/ I have a scheme to get rid of the Base64-url encoding in JSON as well. But the result isn't JSON, it is JSON-B. Which is simply JSON with some additional code points defined for sending binary data as length-data chunks. The reason I want this is that I use cryptography at multiple levels in the Mesh and I want to use the JSON data model as my only encoding regardless of the layer I am at in my protocol stack. You can't meet requirements for meta-data protection and end-to-end security with a single layer of crypto. A 33% increase in data volume for each crypto pass is unacceptable. So I have these schemes, but they are not JSON encoding. I call them JSON-B, JSON-C and JSON-D. The simplest, JSON-B just adds binary encoding for numbers and length delimited strings and binary data. JSON-C adds tag compression and JSON-D adds in more floating point formats such as you might need for scientific data. I suggest that you write up the canonical serialization as a separate draft and get it an assigned content-type. We could call it JSON-F (for fixed) or something like that. From nobody Fri Feb 5 18:41:40 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FBD1A88F0 for ; Fri, 5 Feb 2016 18:41:38 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 8g8vcqi1xcG2 for ; Fri, 5 Feb 2016 18:41:37 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 A3ADF1A88EB for ; Fri, 5 Feb 2016 18:41:36 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id p63so50330816wmp.1 for ; Fri, 05 Feb 2016 18:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=aO+ysJPm3XhPDfjJGK94VfOPwiHNC2mu/CGEfYlfOx4=; b=Ay6alxMhUZVV5k414czccjZdeQRVQA7ErhJvtpEr8yoErXBnIYlfGRllsDy9a07BPC 1xLKuSyschzG3U7F99e8hVDDE4/lDNf4BVrO1fO3San7p5B5jkiP6qeVWn/RgNSqRkrt aqC6edgkZfE/55UukY8wF+bl/UmSd0jvA/kBiKGXOC47dsUJXL/N7baTCLgjfsRokxQ8 e0wdwv1zEyHlapXR8zuXvT7XVfNCLPYOAHuba0Mm27Fj6WkgNwD8bBtYtyYIFTFeHk81 oHk5a+jHShGMqFksPwnWhn02dW0zqpkPRoluEpnc+ZvZ4wCqfxQvu6sKmXqh++xilVGM nVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=aO+ysJPm3XhPDfjJGK94VfOPwiHNC2mu/CGEfYlfOx4=; b=Gyk0Gt7AV4hHSQLr1wGv+d1K4y/SPdDllm0R1LeirChMUs8Oe/lyqSnEOsJqj87BQ1 0DVDkYmHInhuIHHaRk7Wv+vrLfLUr1yN1yO6XO12VOlMz4aeuY8T6WdZLRv6oeXJjFZw JlTktsYZxP6JDY9NxlF9cA3TDIJaZDGwmsw2Q+/vsBFmN7ysgdv5O16ZAB1ptPKh+KLx eiY+DMBBJW1Sq90hAcOvPGduwcuuASk7538gWbSujFL/jHS8+7KkcnhwE/s2a2r1fecn R9Uaa05SHpszryx4TPuwwCUILRFF8dmHn8h9XiYXPjOa4oRchXt+ce/tTzn72SxPbd4N pw1w== X-Gm-Message-State: AG10YOQwbWvKte3ZYbC8DwWhUcYgf1Xg9j1s1jbWysebBWoCjnjddV7noJuVYJ3KFqBXaA== X-Received: by 10.194.235.4 with SMTP id ui4mr16465123wjc.177.1454726495272; Fri, 05 Feb 2016 18:41:35 -0800 (PST) Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id q75sm1210718wmd.6.2016.02.05.18.41.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Feb 2016 18:41:34 -0800 (PST) To: Phillip Hallam-Baker References: <56B36D15.1030306@gmail.com> <56B370A1.1050508@tzi.org> <56B373B8.7040305@gmail.com> <20160205001717.GC2997@mercury.ccil.org> <56B43FCE.6080408@gmail.com> <56B4BB58.4010104@gmail.com> From: Anders Rundgren Message-ID: <56B55D5C.8050303@gmail.com> Date: Sat, 6 Feb 2016 03:41:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: John Cowan , Carsten Bormann , Tim Bray , JSON WG Subject: Re: [Json] On flat vs nested JSON encoding style X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 06 Feb 2016 02:41:38 -0000 On 2016-02-05 17:27, Phillip Hallam-Baker wrote: >> >> I fully buy into the efficiency aspect of the nested encoding style (which I >> honestly had never thought of), but when it comes to "hard to follow", >> predictable >> serialization a la ES6 seems like a more universal solution since this also >> sucks: >> { >> "city": "Paris", >> "name": "John Doe", >> "country": "FR", >> "zip": 245333 >> } >> >> ES6 serialization and the nested encoding style scheme can easily be >> combined, hopefully bringing out the best of both worlds! > > There are probably valid use cases for a canonical serialization > format. And that is probably more viable in JSON than in XML. I have gradually lost faith in standardization as the best way forward for stuff that is close to applications. It takes too long time, and there are usually multiple roads to (virtually) the same goal. The IMO worst thing is that WGs do not generally care about changes in the market, or the availability of new technology although this could motivate charter updates and sometimes even abandoning the work-item altogether. And if you are Google you can do set standards for the rest of the world which also makes standardization anything but a level playing field. By building on a Google standard (V8) for JSON normalization (not canonicalization), I feel quite safe that this concept (rather than my signature definition verbatim), will become a de-facto standard. That's perfectly satisfactory for my work which simply is helping the payment industry converting to JSON. Anders https://cyberphone.github.io/openkeystore/resources/docs/jcs.html#ECMAScript_Compatibility_Mode From nobody Sun Feb 21 20:21:28 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D23721A1B74 for ; Sun, 21 Feb 2016 20:21:26 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 F8UdJKWc1oMx for ; Sun, 21 Feb 2016 20:21:25 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 F24D91A1A2F for ; Sun, 21 Feb 2016 20:21:24 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id a4so145091820wme.1 for ; Sun, 21 Feb 2016 20:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=4jvTKOpOXQ53Awaz+fsKJNDkb8Oiv4GZNZBySen5a4U=; b=UqTupDH4Qrbh7vI6EQ/K/CyG7yNyqA6FMGFlE9uarcbAKGyAwQRCV38MVP9pm8cpA2 3pTdpQRtvLFc2YixPeb4Do+ou5lAMD7fqkh5aKf4hVugWi/XGqt0XJy8mjBSmHGIlq/d Y58ZSy6H3B8K8uVfeYvwYq1kBWGvq4W13vfae+869ethOPIt8wjtaVr9jHXPmVs0cnpb pzrV1p8g4aVuRoH2RPJw+HOgcw93WV/T3bLlrPbak1VzORA8HyYzYFxGYRaAay8irR6W goDW+CzCfVf5ZZNcBaeSyDv7AuSA5i2QbQkgBKrz4JhjId/Kril9mIdspFQkX9XDEf80 vSiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=4jvTKOpOXQ53Awaz+fsKJNDkb8Oiv4GZNZBySen5a4U=; b=cYlhUNa+winmjvBUkpqDws/GNOU89sGy3G8vSBcCtACu8zxLIelM2gaGHH7B0Ec94J KJr9MvnkYs6PTFMgrgOqzcNR/zLOh5uuGQPwIYkIXo5gl67OGBTRAFzPh/DtYT6iUXSL DTN3xerq9WDMLDt79CF+jFL+mJwCHaSaLci2eJOwkJrw7MPvFycF699KXNW32P67lfd9 AJPUUS/rEtyUoDipZ8FzDS51z3iBUMmDVXj3CJBa76qr8yJ/OMD4TMxpUvaQYu0Ou0mF ePsb7789/yxkcpP4uDJcv30hzPLyZGEh1+oMkfLuEGY7oq46UIKxQgje2F2mb3cJ0Rd0 SkxA== X-Gm-Message-State: AG10YORAILnbZ9Fu9IU6vtOj51k9o7GZOfb3mSqSdLzBT4nfuyXQYh8ewTuY8yg/hZ0urA== X-Received: by 10.194.184.234 with SMTP id ex10mr24100951wjc.8.1456114883593; Sun, 21 Feb 2016 20:21:23 -0800 (PST) Received: from [192.168.1.79] (9.197.130.77.rev.sfr.net. [77.130.197.9]) by smtp.googlemail.com with ESMTPSA id 74sm19203571wmn.17.2016.02.21.20.21.22 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 21 Feb 2016 20:21:22 -0800 (PST) From: Anders Rundgren To: "json@ietf.org" Message-ID: <56CA8CB3.2050602@gmail.com> Date: Mon, 22 Feb 2016 05:21:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] JSON Signatures for Financial Messaging X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 22 Feb 2016 04:21:27 -0000 A minute whitepaper. https://cyberphone.github.io/openkeystore/resources/docs/jsonsignatures.html JSON tools will (hopefully) be upgraded to accommodate this mode of operation: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8149075 https://github.com/cyberphone/jsondotnet https://github.com/golang/go/issues/14135#issuecomment-177265555 https://bugs.php.net/bug.php?id=71473 https://github.com/simplejson/simplejson/issues/133#issuecomment-177272525 https://github.com/Microsoft/ChakraCore/issues/149 Rationale: If you specify/declare/parse properties A,B,C it is not particularly logical if they are serialized as C,B,A. The update allows you to create "Crypto Safe" (hashable) JSON objects. This is a new JSON feature. Anders From nobody Mon Feb 22 21:49:22 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B70C1AC3A2 for ; Mon, 22 Feb 2016 21:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=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 BJcq88tfZUMO for ; Mon, 22 Feb 2016 21:49:19 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9081A92DC for ; Mon, 22 Feb 2016 21:49:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,488,1449493200"; d="scan'208,217";a="149830335" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 23 Feb 2016 16:49:16 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,8083"; a="82226972" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcavi.tcif.telstra.com.au with ESMTP; 23 Feb 2016 16:49:15 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([fe80::b5b0:1190:625a:50ad%22]) with mapi; Tue, 23 Feb 2016 16:49:02 +1100 From: "Manger, James" To: "json@ietf.org" Date: Tue, 23 Feb 2016 16:49:00 +1100 Thread-Topic: Nested JSON encoding style too likely to be insecure Thread-Index: AdFt/eCeCuwAKQZ4RlKTYc7/eVnwCA== Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BBADBF674WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Subject: [Json] Nested JSON encoding style too likely to be insecure X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2016 05:49:22 -0000 --_000_255B9BB34FB7D647A506DC292726F6E13BBADBF674WSMSG3153Vsrv_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm a bit late to the party on the "On flat vs nested JSON encoding style" = thread... The nested style that Phillip was encouraging is: { "A" : { "field1" : "value1", "field2" : "value2", "field3" : "value3" } } It looks like messages in this style (requests and responses) would always = have a top-level JSON object with a single member identifying the type of m= essage ("A" in this example). An app might get this member from an iterator= over the object (eg in Java when using a Map to represent a JSON object: o= p =3D map.entrySet().iterator().next();). But what happens if a message (maliciously) has two elements in the top-lev= el object? { "READ" : { "field1" : "value1", "field2" : "value2", "field3" : "value3" }, "DELETE": { "field1" : "value1", "field2" : "value2", "field3" : "value3" } } A receiving app (expecting 1 element) could easily pick either "READ" or "D= ELETE" and ignore the other. If an authorization layer picks "READ" and all= ows the message through, then the backend picks "DELETE" and acts according= ly... ouch. This nested style looks cute, but is probably too cute as "obvious" ways to= implement it can easily be insecure. If we want to ensure a message type to come before its content then we shou= ld use a JSON array: [type, content]. -- James Manger --_000_255B9BB34FB7D647A506DC292726F6E13BBADBF674WSMSG3153Vsrv_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’= m a bit late to the party on the “On flat vs nested JSON encoding sty= le” thread…

 

The nested style that Phillip was encouraging is:=

 

{ "A" :

   { &quo= t;field1" : "value1", "field2" : "value2"= ;, "field3" : "value3" } }

 

It looks like messages in = this style (requests and responses) would always have a top-level JSON obje= ct with a single member identifying the type of message (“A” in= this example). An app might get this member from an iterator over the obje= ct (eg in Java when using a Map to represent a JSON object: op =3D map.entr= ySet().iterator().next();).

 <= /o:p>

But what happens if a message (maliciously) h= as two elements in the top-level object?

 

{ "READ" :<= /p>

   { "field1" : "value1&qu= ot;, "field2" : "value2", "field3" : "va= lue3" },

  "DELETE":=

   { "field1" : &qu= ot;value1", "field2" : "value2", "field3"= ; : "value3" } }

 

A receiving app (expecting 1 element) could ea= sily pick either “READ” or “DELETE” and ignore the = other. If an authorization layer picks “READ” and allows the me= ssage through, then the backend picks “DELETE” and acts accordi= ngly… ouch.

 

<= p class=3DMsoNormal>This nested style looks cute, but is probably too cute = as “obvious” ways to implement it can easily be insecure.<= /o:p>

If we want to ensure a message type to come b= efore its content then we should use a JSON array: [type, content].

--

James Manger

 

= --_000_255B9BB34FB7D647A506DC292726F6E13BBADBF674WSMSG3153Vsrv_-- From nobody Mon Feb 22 21:54:22 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C0B1ACD1C for ; Mon, 22 Feb 2016 21:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 SJyG9YA21ViH for ; Mon, 22 Feb 2016 21:54:20 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 A90BD1ACEB6 for ; Mon, 22 Feb 2016 21:54:19 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id l143so108472886lfe.2 for ; Mon, 22 Feb 2016 21:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3SDYOb66To7p52eDx6wi8Denn/KHfbsmfayvF94fzH4=; b=gqMQBfblgpGXC+SDemtEd1IVXNXe62O2HAxGfWy4eqcynLWEikJdfI/YlobZq/nDKz rhWUJu1ve14OJ6wx+U0RJsctWbziy58W2g/1s7dJDXkbmY2HylzaQYqX30v8XlilGDVb MjRKAqFO+HXzz+2xrr8VQZF61J/pkeMQpFfg7L3S7UcwXzYFnYk4YigqnednLu8mhj4h qFtA/XeOi90sObonnc/VDPMJs7aZlpmSS1b7cdchDh9rR1cLD9BHXGOeXDf/gLO9aErV S7Hf9ULIY1zzVFHPHSVetksIiBkP5BwH3XSvXuzn6OvEstU862mLgZr2OvvsMGnnTtM5 9q5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3SDYOb66To7p52eDx6wi8Denn/KHfbsmfayvF94fzH4=; b=TvCGOhX9vlJ9a47b7mvo4d+R8oXsWa/5WG2i0Ai+sySzfgphGj1IvpzGMfN8Fehx7X 4yCpZLGGgZ6T8i9fEXUn5LlZQxTj68zeUlRuJi79TtDYbX3vOefn7yQoPfoJwaN3iH/A hBuuVjQQTSu9JPWiyPXUZZams42y+uDV2qEwTCx7/cY8BKMgdDbtU/YQyL4Dt/+CbAVr Se9SGqnTaRDYVV418kIexKZtjo3yVdDMQE1D8rRJNWABMMutgacCDy0mh7wpXFFl09sj uA5p6lwM1Vr0LfN3tnCmpl+DujAyy3oH9GqzDDUlItnhEGrcerKFuGehzJE0d2iJZQ3A BTAg== X-Gm-Message-State: AG10YOQaxGlB2vHJ0mN0ViDduK+5d2uGMqH+E0GLmdxxb62o5iDGYA6clyOHjvXjYni/LORPhx1JEuBkLFQb9w== MIME-Version: 1.0 X-Received: by 10.25.205.7 with SMTP id d7mr11700571lfg.70.1456206857900; Mon, 22 Feb 2016 21:54:17 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Mon, 22 Feb 2016 21:54:17 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 23 Feb 2016 00:54:17 -0500 X-Google-Sender-Auth: 0qJYXTijqOXASLX6ODUR1i7vcpQ Message-ID: From: Phillip Hallam-Baker To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Nested JSON encoding style too likely to be insecure X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2016 05:54:21 -0000 On Tue, Feb 23, 2016 at 12:49 AM, Manger, James wrote: > I=E2=80=99m a bit late to the party on the =E2=80=9COn flat vs nested JSO= N encoding style=E2=80=9D > thread=E2=80=A6 > > > > The nested style that Phillip was encouraging is: > > > > { "A" : > > { "field1" : "value1", "field2" : "value2", "field3" : "value3" } } > > > > It looks like messages in this style (requests and responses) would alway= s > have a top-level JSON object with a single member identifying the type of > message (=E2=80=9CA=E2=80=9D in this example). An app might get this memb= er from an iterator > over the object (eg in Java when using a Map to represent a JSON object: = op > =3D map.entrySet().iterator().next();). > > > > But what happens if a message (maliciously) has two elements in the > top-level object? > > > > { "READ" : > > { "field1" : "value1", "field2" : "value2", "field3" : "value3" }, > > "DELETE": > > { "field1" : "value1", "field2" : "value2", "field3" : "value3" } } > > > > A receiving app (expecting 1 element) could easily pick either =E2=80=9CR= EAD=E2=80=9D or > =E2=80=9CDELETE=E2=80=9D and ignore the other. If an authorization layer = picks =E2=80=9CREAD=E2=80=9D and > allows the message through, then the backend picks =E2=80=9CDELETE=E2=80= =9D and acts > accordingly=E2=80=A6 ouch. > > > > This nested style looks cute, but is probably too cute as =E2=80=9Cobviou= s=E2=80=9D ways to > implement it can easily be insecure. > > If we want to ensure a message type to come before its content then we > should use a JSON array: [type, content]. You need to limit the toplevel to one element. That is fairly easy to do th= ough. From nobody Mon Feb 22 22:08:47 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDC41B2A20 for ; Mon, 22 Feb 2016 22:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.997 X-Spam-Level: X-Spam-Status: No, score=0.997 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=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 EgV4maoFNxnw for ; Mon, 22 Feb 2016 22:08:45 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFB71B2A1B for ; Mon, 22 Feb 2016 22:08:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,488,1449493200"; d="scan'208";a="60302853" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 23 Feb 2016 17:08:43 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,8083"; a="84100463" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbni.tcif.telstra.com.au with ESMTP; 23 Feb 2016 17:08:43 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([fe80::4455:9840:ced2:23fa%12]) with mapi; Tue, 23 Feb 2016 17:08:43 +1100 From: "Manger, James" To: Phillip Hallam-Baker Date: Tue, 23 Feb 2016 17:08:30 +1100 Thread-Topic: [Json] Nested JSON encoding style too likely to be insecure Thread-Index: AdFt/qSDFXT8xwuCTxCV5XOL6E30uwAAEvOw Message-ID: <255B9BB34FB7D647A506DC292726F6E13BBADBF6C2@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Nested JSON encoding style too likely to be insecure X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2016 06:08:46 -0000 PiBZb3UgbmVlZCB0byBsaW1pdCB0aGUgdG9wbGV2ZWwgdG8gb25lIGVsZW1lbnQuIFRoYXQgaXMg ZmFpcmx5IGVhc3kgdG8gZG8gdGhvdWdoLg0KDQpFYXN5IHRvIGRvOyBidXQgZXZlbiBlYXNpZXIg bm90IHRvIGRvLiBEb2VzIHlvdXIgY29kZSBhbHJlYWR5IGRvIHRoaXM/DQpUaGlzIGlzIG5vdCB0 aGUgc29ydCBvZiBjaGVjayBJIHdhbnQgdG8gcmVseSBvbiBkZXZlbG9wZXJzIG1ha2luZy4gSXQg aXMgbm90IG9idmlvdXMgdGhhdCB0aGUgY2hlY2sgaXMgbmVlZGVkOyBjZXJ0YWlubHkgbm90IGZy b20gbG9va2luZyBhdCBhIGZldyBzYW1wbGUgbWVzc2FnZXMuDQoNCkNoZWNraW5nIHRoZXJlIGlz IG9ubHkgMSB0b3AtbGV2ZWwgZWxlbWVudCBjYW4ndCBiZSBkb25lIHVudGlsIHlvdSBnZXQgdG8g dGhlIGVuZCBvZiB0aGUgZmlyc3QgZWxlbWVudOKAmXMgdmFsdWUg4oCUIHdoaWNoIHNlZW1zIHRv IGNsYXNoIHdpdGggeW91ciByYXRpb25hbGUgZm9yIHRoZSBuZXN0ZWQgc3R5bGUuDQoNCkEgSlNP TiBhcnJheSBzdGlsbCBsb29rcyBiZXR0ZXIuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From nobody Tue Feb 23 04:08:55 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BC41B40C9 for ; Tue, 23 Feb 2016 04:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.093 X-Spam-Level: X-Spam-Status: No, score=0.093 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 wy4gxg4vIvqI for ; Tue, 23 Feb 2016 04:08:53 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A591AC402 for ; Tue, 23 Feb 2016 04:08:53 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1aYBll-0004SU-1W; Tue, 23 Feb 2016 07:08:45 -0500 Date: Tue, 23 Feb 2016 07:08:44 -0500 From: John Cowan To: "Manger, James" Message-ID: <20160223120844.GJ20304@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E13BBADBF6C2@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBADBF6C2@WSMSG3153V.srv.dir.telstra.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: Phillip Hallam-Baker , "json@ietf.org" Subject: Re: [Json] Nested JSON encoding style too likely to be insecure X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2016 12:08:54 -0000 Manger, James scripsit: > A JSON array still looks better. I agree; but JSON validation is better yet. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org De plichten van een docent zijn divers, die van het gehoor ook. --Edsger Dijkstra From nobody Tue Feb 23 05:21:16 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA52D1B2BD7 for ; Tue, 23 Feb 2016 05:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 Ug6fmt2Eu32V for ; Tue, 23 Feb 2016 05:21:13 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 855B91B2BD4 for ; Tue, 23 Feb 2016 05:21:13 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id bc4so100599918lbc.2 for ; Tue, 23 Feb 2016 05:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JTafPuQKaILDo89/eP8bnejaR5SbxqbYzNIPo8VNQWc=; b=Rb/O0lq7BQl2VsNlfAIcLwhkj3gpp1wGNfZCm2GJ8R92IR2WwiPGVTFS1+VWMSf62Y vt60wIIwoJj/q8aMOph7oqZ98ihZzKrYHfekXBFgfjVLe5cGoOtidIarGlX3HqCRNk71 mSOFpFN/F3ap7Apx4wAHGE43Syqzc7scegbph9NW3JMM9Ns0aqTb+K/mC6iTieuEuNq0 UvoVJnu1NdoDINE7kEn/XfmXg8frVFXlTmHpH71rFiV6xcbenXyCfbyPIO+uTf5G8Ah9 G4/BhoNMzMljyIBcp5/r4HW/pLc+p50ZUk/EgdopMtqGRGecQqcAs1/fCfKi39RcIo8b vmtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JTafPuQKaILDo89/eP8bnejaR5SbxqbYzNIPo8VNQWc=; b=X0spJIpxiwrYZGhXS3ALN7qeQgX8oaGdaI+YsroB5l4GDP/0oQp5N0zTtQ6h6FcStt zAFwdukWf0WLY7TwaFwtdJEjYRB9/AsaYfcnKaEBP/IDUjOFbf7LRWPZ5vdziODz2dL7 ZOlzjaKziAEeGMbn3dAd1KiFGszcSy4pqS0Atp84bANSIniBFcq8guKr9vkAis5FaAfE +GWNanYioAeRXS4BG/DadmGBmAOKDKQOxfUH/mefPdA0HzIvfgdXz2QtCbF29TI0/MmH Iznin8zQ5XD1qlzaj/HxFhopKzQcoW2vIdnSTzjQqM+drgXXW1Wmy5em4hX51Kx8jd5B 7GkA== X-Gm-Message-State: AG10YOTx97wKEiohuw7mnYv7woqMEtPGjhWctiyZyxrybAN88G2D2VPJ3lpo3xRHrGT1TgS8jQQimDuso0woEA== MIME-Version: 1.0 X-Received: by 10.112.30.144 with SMTP id s16mr12245935lbh.112.1456233671758; Tue, 23 Feb 2016 05:21:11 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Tue, 23 Feb 2016 05:21:11 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBADBF6C2@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E13BBADBF6C2@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 23 Feb 2016 08:21:11 -0500 X-Google-Sender-Auth: w3VUmKv5GZfOKglcWG2S_AbhTQ4 Message-ID: From: Phillip Hallam-Baker To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "json@ietf.org" Subject: Re: [Json] Nested JSON encoding style too likely to be insecure X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2016 13:21:15 -0000 On Tue, Feb 23, 2016 at 1:08 AM, Manger, James wrote: >> You need to limit the toplevel to one element. That is fairly easy to do= though. > > Easy to do; but even easier not to do. Does your code already do this? > This is not the sort of check I want to rely on developers making. It is = not obvious that the check is needed; certainly not from looking at a few s= ample messages. > > Checking there is only 1 top-level element can't be done until you get to= the end of the first element=E2=80=99s value =E2=80=94 which seems to clas= h with your rationale for the nested style. > > A JSON array still looks better. Lets look at the 'attack' you are proposing here - a maliciously formatted request. Does it really make sense? This isn't the normal buffer overrun type malicious request, you are postulating one of the requests is valid and the other isn't. How is an attacker meant to inject the second attack? From nobody Tue Feb 23 06:00:44 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603D01B2DB6 for ; Tue, 23 Feb 2016 06:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 vhrAPW1DDvSu for ; Tue, 23 Feb 2016 06:00:39 -0800 (PST) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C258F1B2DAE for ; Tue, 23 Feb 2016 06:00:39 -0800 (PST) Received: from cowan by earth.ccil.org with local (Exim 4.72) (envelope-from ) id 1aYDVw-0007lQ-Ko; Tue, 23 Feb 2016 09:00:33 -0500 Date: Tue, 23 Feb 2016 09:00:32 -0500 From: John Cowan To: Phillip Hallam-Baker Message-ID: <20160223140032.GP20304@mercury.ccil.org> References: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E13BBADBF6C2@WSMSG3153V.srv.dir.telstra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: John Cowan Archived-At: Cc: "Manger, James" , "json@ietf.org" Subject: Re: [Json] Nested JSON encoding style too likely to be insecure X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 23 Feb 2016 14:00:42 -0000 Phillip Hallam-Baker scripsit: > This isn't the normal buffer overrun type malicious request, you are > postulating one of the requests is valid and the other isn't. How is > an attacker meant to inject the second attack? As I understand it, the idea is that there is a service which permits anyone to read, but requires credentials of some kind in order to write. There is a two-stage pipeline consisting of a validator and an execution agent. A hybrid (invalid) request containing both read and write is sent by the black hat. The validator by chance looks at the read request and passes the hybrid through without checking any credentials. The execution agent, however, by chance sees the write request and acts on it, assuming that the validator has properly checked it. Oops. Obviously the problem is that the validator is too liberal in what it accepts, and should ensure that the request is well-formed before applying its rules. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org Eric Raymond is the Margaret Mead of the Open Source movement. --Bruce Perens, a long time ago From nobody Sun Feb 28 22:54:59 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537841A6FFE; Sun, 28 Feb 2016 22:54:57 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 2alRBtrsLrz9; Sun, 28 Feb 2016 22:54:55 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 5010D1A6FF9; Sun, 28 Feb 2016 22:54:55 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id p65so54900182wmp.1; Sun, 28 Feb 2016 22:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=ZHunIkA8c4ZFxHXXLF9ZfgI7PNfSTNvLl/fEu4Nlbv0=; b=jv3GMVl4dTc8pGuFiN4jsVHEP1a1EMThPStBgUg3cicOXCVCchs2n7I+/wLdPEx52Y x1SD7LEwIbsdF/myNa6ipQhOclQ5PA75tNiP4BGZKBsrTvJWp/kYlw91sRHe3YEh7RPE /iKke1abDXMiskvppBX9eeOk+oXJqRJvyQ0ltcVUGsXARDJSgyNKyZkmRDtfsFsQre8G UkzywI+R4tStj38RAblVxCU4yd715IpyN6TI3BXZ1Y/Z3gVfJRKJPe86UibqN2A8cU+M uJuesws0DL9maPdzb71eBWUGiXIMaFVPA7NBi+h1AFRPLl5AwUr/k2q1iuGj8R//awk7 arLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=ZHunIkA8c4ZFxHXXLF9ZfgI7PNfSTNvLl/fEu4Nlbv0=; b=ZEl+PdBYM/+UfapL+wyGhlQBoL2oMc6FA8EkfJLyMcNK6tcg0LtDiQ/7SzpYC6B8WY gjFpmCBqdNJPMxpOzo379791/W+6n6SpPC651UTVcGwifxdN1T7NrWe/qgAqF9g4FH5d Vdc/KYSUl8xx4g4mr6AccAuoUvCnbRwzMFjAXaIf8rnqHCyL+qCwW1CFsjF3hUKtgJ/T /SXK1+rLX67L+FXWcA38KzBt1CKq6GCCJ0MZHckvlAItfMuQyD0lAjiyMRpuHS5ywKec /2D2IgwetltkCmeyyyqm+2tldaRGFfHU/u2gwoJASh8GgjryQUaoEJA+uYqzD97KPn1i 6i4A== X-Gm-Message-State: AD7BkJLbdjiqsYX6PEFI0u4HPg70XqRLtJEHbS/9tPhTRtJFOLT1jMf1gl2/D/A/jJtekg== X-Received: by 10.28.107.140 with SMTP id a12mr10546231wmi.77.1456728893847; Sun, 28 Feb 2016 22:54:53 -0800 (PST) Received: from [192.168.1.79] (83.203.130.77.rev.sfr.net. [77.130.203.83]) by smtp.googlemail.com with ESMTPSA id ka4sm24375640wjc.47.2016.02.28.22.54.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 22:54:53 -0800 (PST) To: "jose@ietf.org" , "json@ietf.org" From: Anders Rundgren Message-ID: <56D3EB25.90502@gmail.com> Date: Mon, 29 Feb 2016 07:54:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] JCS for "node,js" X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 06:54:57 -0000 F.Y.I. https://github.com/cyberphone/node-webpki.org/blob/master/README.md#jcs-json-cleartext-signature-for-nodejs Enjoy! Anders