From nobody Sun Nov 13 20:03:15 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B87127058 for ; Sun, 13 Nov 2016 20:03:13 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT6dr6lBeMeA for ; Sun, 13 Nov 2016 20:03:10 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47723129487 for ; Sun, 13 Nov 2016 20:03:10 -0800 (PST) Received: from dhcp-8ca2.meeting.ietf.org (unknown [31.133.140.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AD9B422E1FA for ; Sun, 13 Nov 2016 23:03:03 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Mon, 14 Nov 2016 13:03:01 +0900 To: json@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [Json] I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 14 Nov 2016 04:03:13 -0000 It seems like I-JSON is the answer to many of the issues that have = cropped up with JSON. However, as a protocol designer, it's not terribly useful to specify = I-JSON, because it's very likely that people will just use their = existing JSON tools. A simple answer might be to define a new media type that has a header = that's guaranteed to break a JSON parser prepended, but I-JSON as the = body. It might be that people just strip the header and continue to process as = JSON, but they have to actively do that, which may be enough of a bar to = discourage it (and encourage I-JSON tools to bloom). Of course, we could define a syntax that's more deeply incompatible with = JSON. Not sure if that's necessary, though. Thoughts?=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sun Nov 13 22:23:36 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF41B129420 for ; Sun, 13 Nov 2016 22:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5hZa-uAZ9sB for ; Sun, 13 Nov 2016 22:23:27 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D576D1295D1 for ; Sun, 13 Nov 2016 22:23:26 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id t79so79044276wmt.0 for ; Sun, 13 Nov 2016 22:23: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-transfer-encoding; bh=j4lXyemWG6oSCMgpoRU/enycZpFTwhzvNXP6OR6OH/k=; b=qI34fU/IyXq73yOHRhFi03fjcYBjiL1rnuBapexlx6VT2D2AlZgvYZgUVX/93z6LyP M1CZr9HEyPaLXlKRx/fugU/9+Y5jC8oSiOp0EHDkeChkEvcqcsrMMhrSM8EydaQpSil+ DYCQUrUuzaCKFYGB311sOZnJy2F2qyqFRvbpOlOdYCHKJjnyEn75tUjzDvv5PQdAWQUC cTIDQb9S9r1E1wPGfFz1H/opyyX1wxOgUxieeUzXNGPOYpoG8mEFhRE5T3u3RTGLr5bS 9rLBLkFRaXjMZDUHmLGPGuF8KbAR/wq1bNxuFT3lSPDINFejlUY8vP02BzN2sy8lJHDB qPUQ== 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-transfer-encoding; bh=j4lXyemWG6oSCMgpoRU/enycZpFTwhzvNXP6OR6OH/k=; b=gINyCKz6yJ4HMFC/zrgIhom9kI6bT89YDjJiSFPOI7hxvPZTfLFVcjEUf0Il4j2Rt6 d+vZVzI8gGHYK8Wnu8r653xOeDbB7Im2ZvshIB5hFWoG0g7nbm+9c9OJdBCPxhkKFH8K F41TWHdHlTxIgRdV9U3EicCQ5H4SXKTy94GQnKSYWiStaBXIO+wSCVE1eF74uJa4g8mb QjNAJcaqCi0vM1vOT7JfCWhqeLxKzJbGxdcQnT8oZEUT+2FdWUl/f+9D5jkXGq2OmzXp KFY95yHhKXvd5Zxdlrh6YXURZbpcTWSrBdgGaiEdhJHWcGoX7UUt3DJ1eVnul9IeK70V ypeA== X-Gm-Message-State: ABUngveZFEa2UwUpxZlZt1DFYsLkUiSmeH5rkcuAFm2lfNacg+ejQLDJb6zOkT2v+7x0kw== X-Received: by 10.194.100.225 with SMTP id fb1mr17977293wjb.128.1479104605120; Sun, 13 Nov 2016 22:23:25 -0800 (PST) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id ia7sm26584704wjb.23.2016.11.13.22.23.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Nov 2016 22:23:24 -0800 (PST) To: Mark Nottingham , json@ietf.org References: From: Anders Rundgren Message-ID: <6fb75362-dc25-e5ff-ca0d-587c90f1060e@gmail.com> Date: Mon, 14 Nov 2016 07:23:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 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] I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 14 Nov 2016 06:23:35 -0000 On 2016-11-14 05:03, Mark Nottingham wrote: > It seems like I-JSON is the answer to many of the issues that have cropped up with JSON. > > However, as a protocol designer, it's not terribly useful to specify I-JSON, > because it's very likely that people will just use their existing JSON tools. > > A simple answer might be to define a new media type that has a header that's > guaranteed to break a JSON parser prepended, but I-JSON as the body. > > It might be that people just strip the header and continue to process as JSON, > but they have to actively do that, which may be enough of a bar to discourage it (and encourage I-JSON tools to bloom). > > Of course, we could define a syntax that's more deeply incompatible with JSON. > Not sure if that's necessary, though. > > Thoughts? The differences between I-JSON and a "sensibly use" of traditional JSON appears to minimal. If people really want to go further, TJSON is yet another alternative in the workings: https://www.tjson.org/ Personally I stick to the ES6 definition which is supported by Node.js, Browsers, Java and then some. That ES6 (in contrast to the other variants) also defines property serialization order makes it highly adapted for cryptographic operations like hashing without any "extras." A plain JSON.stringify() suffice. Anders > > > -- > Mark Nottingham https://www.mnot.net/ > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Sun Nov 13 22:44:52 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3F1129459 for ; Sun, 13 Nov 2016 22:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYSsT3z8L8y8 for ; Sun, 13 Nov 2016 22:44:49 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 92EDB129420 for ; Sun, 13 Nov 2016 22:44:49 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f82so79779258wmf.1 for ; Sun, 13 Nov 2016 22:44:49 -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-transfer-encoding; bh=zXxIlwLx0SdtZlN40J5xkkGl+y3B7u5iIqIxzUipdAQ=; b=1DNd9CMfP6Nr4oCBdTgwqHlgFu5vNxN5kAz/yc2gf6jmBqs8EkNydl3UeFPu1QkOdt 8PlM7RLBXgS1mYdmYznnn9ZplIBxjJ/Sx9CYQQptGWV0hkDccZVP/P+5kIqSKl6ZDVoX D54gNcLQQlsgPo22Tu3RKa0+kkSpp+99346Ksz0bsfaSBpfAnxN1MXcftx81nmVHQRlv CMniz5Nmv/eGl+gCjNONYJXINGJdIk2kOXke69gbcMhHo7hIRetRKJ2h1VWTe7YxsjH1 buq0nodhfO/ss17ZGnpKtjtqJSMizZC0aGNi4wMSbV+ryj4jGOX3O33ex5xdQRN0IP7O lbrA== 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-transfer-encoding; bh=zXxIlwLx0SdtZlN40J5xkkGl+y3B7u5iIqIxzUipdAQ=; b=dwxYk7ppk5iAMp/qy99knSX33f+TaFl62cZWwuPrE4qp8oRYvMX9Jk9k0LqH3y8J1m 0wsGO/4nJGZBM+8SwjPNBVN5J4w9JGav+bu5mwQqVXElkNU7Q0Qr3Y8bN0v6lM1gBpx2 /ZYpLzZ4gUwXwS+hryLF6ucNlIkZRFg2q6R15K844wHUgLLO1e4Uqd0mKF8W9JOdwg3R BJMAAvYOEoP6KtS7S9bhvWQpOIQktwlqc2KaaaiZtpgryI2P76Rqy3iipji423dLb+T/ PrugUYDpCoiQK5BEKLaq3hr66/BYNumDfoNufDjMz7Xx7V28eTOrVYz1mTic3l2OmGuN fI7A== X-Gm-Message-State: ABUngvdb6BRQUbzx0EiXT7wyuGTvXxvgVujGIqK4264Qx4xUQl/RrYlvFaCu+df1Aeyx9A== X-Received: by 10.28.26.197 with SMTP id a188mr8522125wma.93.1479105888130; Sun, 13 Nov 2016 22:44:48 -0800 (PST) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id 18sm34280654wmr.5.2016.11.13.22.44.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Nov 2016 22:44:46 -0800 (PST) To: Mark Nottingham , "json@ietf.org" References: From: Anders Rundgren Message-ID: Date: Mon, 14 Nov 2016 07:44:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Json] Mapping scheme? Was: I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 14 Nov 2016 06:44:51 -0000 On 2016-11-14 05:03, Mark Nottingham wrote: > It seems like I-JSON is the answer to many of the issues that have cropped up with JSON. > > However, as a protocol designer, it's not terribly useful to specify I-JSON, because it's very likely that people will just use their existing JSON tools. > > A simple answer might be to define a new media type that has a header that's guaranteed to break a JSON parser prepended, but I-JSON as the body. > > It might be that people just strip the header and continue to process as JSON, but they have to actively do that, which may be enough of a bar to discourage it (and encourage I-JSON tools to bloom). > > Of course, we could define a syntax that's more deeply incompatible with JSON. Not sure if that's necessary, though. > > Thoughts? Hi Mark, As I wrote in the reply to your message I consider ES6 to be a (de-facto) successor to I-JSON. What's maybe missing is a standardized mapping scheme since lots of people need to emulate additional data types on top of a JSON "string". The scientific people want 80-bits IEEE The Java/Python/C# folks want true 64-bit integers The crypto geeks want really big integers The financial guys want big decimals The only change that is needed on the JSON level is making comments a standard so that JSON becomes a logical choice for "config" files as well. It appears to be close to a de-facto standard already. Anders > > > -- > Mark Nottingham https://www.mnot.net/ > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Mon Nov 14 00:31:15 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A9F1295BE for ; Mon, 14 Nov 2016 00:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 T_MmJHczxX-I for ; Mon, 14 Nov 2016 00:31:12 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2E01293E3 for ; Mon, 14 Nov 2016 00:31:12 -0800 (PST) Received: from [10.0.10.26] (unknown [211.44.215.72]) by mail.nic.cz (Postfix) with ESMTPSA id CB0F4613D2; Mon, 14 Nov 2016 09:31:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1479112271; bh=a42EPRb9lCH1C9kgVyEfpZ5yO/iTdVObscMp3G7Vgfk=; h=From:Date:To; b=FAQAz39dksknXI4LmT2g/2KFkkdWvDwH18ccwyJCPuKZ4mURGDanmTRp0zENf57MA SFG0NlF2V/vcTZSlT5nIejlrOnyCmKHsP/YR9CE+/JtWwMfl2GXhLZiMVyGPqOr2BH iJe9i8TNK6ogrtufXW4O8eWl2nBdTEokY5jI+Fsk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 14 Nov 2016 17:31:04 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <541B4A9D-97F4-4335-8B82-49682EE46D78@nic.cz> References: To: Mark Nottingham X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: json@ietf.org Subject: Re: [Json] I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 14 Nov 2016 08:31:14 -0000 > On 14 Nov 2016, at 13:03, Mark Nottingham wrote: >=20 > It seems like I-JSON is the answer to many of the issues that have = cropped up with JSON. >=20 > However, as a protocol designer, it's not terribly useful to specify = I-JSON, because it's very likely that people will just use their = existing JSON tools. My understanding of I-JSON is that it specifically allows people to use = their existing JSON tools. In RFC 7951 we use I-JSON and, for example, = encode 64-bit integers as strings even though it is awkward and adds = extra processing steps in most tools. Lada =20 >=20 > A simple answer might be to define a new media type that has a header = that's guaranteed to break a JSON parser prepended, but I-JSON as the = body. >=20 > It might be that people just strip the header and continue to process = as JSON, but they have to actively do that, which may be enough of a bar = to discourage it (and encourage I-JSON tools to bloom). >=20 > Of course, we could define a syntax that's more deeply incompatible = with JSON. Not sure if that's necessary, though. >=20 > Thoughts?=20 >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Nov 14 09:19:15 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A89129430 for ; Mon, 14 Nov 2016 09:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkBb4p_szstX for ; Mon, 14 Nov 2016 09:19:12 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 62FEA129413 for ; Mon, 14 Nov 2016 09:19:12 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id q124so131544093itd.1 for ; Mon, 14 Nov 2016 09:19:12 -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; bh=uv7L8zeGCyZ6w394RVuMjoX5iQGayH8n4k3Q4lQViLA=; b=O5WeoDEio4UwP4PXItumZBKbnf2ZQghHqccKMRme/5xcnxAkHvnS+iMyi3cvhr2zOT C0qLzq4WLPgiLe+aqMf6Jbj8c6i/xcLMs8G8TCZ79aKPBjvD5WSRxTgPlRhOgVk3Z32O 6GEhtKKhwt8A5PIjYptfZHCHpPCqIv/igbkMVwe2rRsK+4KYf+PfBFR2gCzrR9RSwC9F gFjtC5iAR62I4StO96sJ+weWckccCMHlE0dMt5ppmBSj6L3VbjFZsOAszAcdPxNFH2LY KTv9Fx5GIysXz5zDiYhWS+Z3Nik0NSHUOYWN/qg3YFLCbTETQjyCtzu+mzaS85jQ48vE xgkA== 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; bh=uv7L8zeGCyZ6w394RVuMjoX5iQGayH8n4k3Q4lQViLA=; b=mip5CviEueJC+1WIG1BVoujvOCFDOkY51ZgDa2trx2yKlGizqRfUmU4HpKL1adyItn LoVF48O/M9lh3vGKhuf2zyYd+fxF248b3Y/7F3pHZYGEadXML4hgQ6V8podDm9XWK+q/ h5WX9B7JB+cZp2j3+zfZPasUgBk5Hy+xJXsKaEETL/9dUwlV0ZIeF7dxWVlYaXXAesxa vbS5pOCliThOAsPz6RYmXSKcBErKLfUMUZKOKAE1NiV8werkciifvaBY6u9VdqjHbX/1 raIpOXpenayChPWBKUpIx+jhSXfK706sly8fYxYXCb6FG75ysjcdPiW1QgSbafg4o51F pZMg== X-Gm-Message-State: ABUngvdqw2c1V4o6qrZsFV4rMr/n+0LVKWIrQWi/GtwHhPWNAFVBTN137giFpbtRvvYsbadjb/QA9dRdiu8wGg== X-Received: by 10.36.83.80 with SMTP id n77mr6828811itb.63.1479143951739; Mon, 14 Nov 2016 09:19:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.80.84 with HTTP; Mon, 14 Nov 2016 09:19:10 -0800 (PST) X-Originating-IP: [64.141.86.146] Received: by 10.50.80.84 with HTTP; Mon, 14 Nov 2016 09:19:10 -0800 (PST) In-Reply-To: <541B4A9D-97F4-4335-8B82-49682EE46D78@nic.cz> References: <541B4A9D-97F4-4335-8B82-49682EE46D78@nic.cz> From: Tim Bray Date: Mon, 14 Nov 2016 09:19:10 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11419bcad0c7d30541460934 Archived-At: Cc: Mark Nottingham , json@ietf.org Subject: Re: [Json] I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 14 Nov 2016 17:19:14 -0000 --001a11419bcad0c7d30541460934 Content-Type: text/plain; charset=UTF-8 I would be very happy if some of the popular JSON tools were to implement I-JSON modes. On Nov 14, 2016 12:31 AM, "Ladislav Lhotka" wrote: > > > On 14 Nov 2016, at 13:03, Mark Nottingham wrote: > > > > It seems like I-JSON is the answer to many of the issues that have > cropped up with JSON. > > > > However, as a protocol designer, it's not terribly useful to specify > I-JSON, because it's very likely that people will just use their existing > JSON tools. > > My understanding of I-JSON is that it specifically allows people to use > their existing JSON tools. In RFC 7951 we use I-JSON and, for example, > encode 64-bit integers as strings even though it is awkward and adds extra > processing steps in most tools. > > Lada > > > > > A simple answer might be to define a new media type that has a header > that's guaranteed to break a JSON parser prepended, but I-JSON as the body. > > > > It might be that people just strip the header and continue to process as > JSON, but they have to actively do that, which may be enough of a bar to > discourage it (and encourage I-JSON tools to bloom). > > > > Of course, we could define a syntax that's more deeply incompatible with > JSON. Not sure if that's necessary, though. > > > > Thoughts? > > > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > > > > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --001a11419bcad0c7d30541460934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would be very happy if some of the popular JSON tools were= to implement I-JSON modes.


On Nov 14, 2016 1= 2:31 AM, "Ladislav Lhotka" <l= hotka@nic.cz> wrote:

> On 14 Nov 2016, at 13:03, Mark Nottingham <mnot@mnot.net> wrote:
>
> It seems like I-JSON is the answer to many of the issues that have cro= pped up with JSON.
>
> However, as a protocol designer, it's not terribly useful to speci= fy I-JSON, because it's very likely that people will just use their exi= sting JSON tools.

My understanding of I-JSON is that it specifically allows people to use the= ir existing JSON tools. In RFC 7951 we use I-JSON and, for example, encode = 64-bit integers as strings even though it is awkward and adds extra process= ing steps in most tools.

Lada

>
> A simple answer might be to define a new media type that has a header = that's guaranteed to break a JSON parser prepended, but I-JSON as the b= ody.
>
> It might be that people just strip the header and continue to process = as JSON, but they have to actively do that, which may be enough of a bar to= discourage it (and encourage I-JSON tools to bloom).
>
> Of course, we could define a syntax that's more deeply incompatibl= e with JSON. Not sure if that's necessary, though.
>
> Thoughts?
>
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>
>
>
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
json mailing list
json@ietf.org
https://www.ietf.org/mailman/listinfo/json
--001a11419bcad0c7d30541460934-- From nobody Tue Nov 15 22:33:21 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90EA1294C7 for ; Tue, 15 Nov 2016 22:33:17 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBSYfKTQHnPz for ; Tue, 15 Nov 2016 22:33:14 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 4CE71129498 for ; Tue, 15 Nov 2016 22:33:14 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id m203so7617096wma.3 for ; Tue, 15 Nov 2016 22:33:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=n1+EIpcHG1TKFipxMkSKUuuxsFXqCDi57NcXPg/C0JY=; b=Gg38QxeiZDW7Lh53U/0Dr51yWNw+OlL6HMI7kRsg1XSmAvO6O1qhbav1YWW5RUhAAX ulEcWv7N6S5lXiWLTzgb3N5V2q3at46NrRncjGhZLPH84xSHbJQS/U8yNMx/RDyxVHVi xwTOS/N8rbaqfIgSbzULv29PCR2RFkDmCaVDXqTRIOxESWqW0xNanlZUB0nJkOUiWT2O VTEHwI7CYsN9bm0nEzF2EFMpLmxTrybbU5Jq3rNZ8lupM9Wck9ps/ANfugQVES2HRP64 US58HnhfKbvuIL3dtiG6KrRhPYup0+7vbqJurOt3qZhwaEVsaipJ9P1PqvEwVqzKcHdH 1K3g== 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:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=n1+EIpcHG1TKFipxMkSKUuuxsFXqCDi57NcXPg/C0JY=; b=ZvDCe1HdshYq2g3007VDewiQv1FzPQxkZAx4OlxZPy24aMRcyeZSAvis1xWERxmZE7 W2qzUR2rwKUwcXK6twN+BFXqFzhpEw1vp8wlDQbljfXcz3wZaFwrcm67/8i6dKlBdSJR MLS4lLa2w6fHSCf2VMUHtcuyvaHiKOLpDe+pfji9ZzW5FyrfuBjgSzSOceDUEEpueXg2 ouco7DVWh8IJTITOoL9L4goWuJzemZEQkXmg1/f5BxHd8JKjtmcJLYu/72OwxDGVaWYT osW29pAs64MNLAIf/d9eR9AgIv9vBnEpm5VrupP6ZHhJzjz9lvnVDojDKGZ0X6sS1amL 65YQ== X-Gm-Message-State: ABUngvcHR8zG9asBaZGl0qXcK8vQd8b+tOGdNa/CV+7TjDMjtVMHqoVIJFdc1cNjFSiHOA== X-Received: by 10.28.173.4 with SMTP id w4mr7183027wme.70.1479277992629; Tue, 15 Nov 2016 22:33:12 -0800 (PST) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id 6sm14087901wjt.5.2016.11.15.22.33.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 22:33:12 -0800 (PST) From: Anders Rundgren To: Tim Bray , Ladislav Lhotka References: <541B4A9D-97F4-4335-8B82-49682EE46D78@nic.cz> Message-ID: Date: Wed, 16 Nov 2016 07:33:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Mark Nottingham , json@ietf.org Subject: Re: [Json] I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 06:33:18 -0000 On 2016-11-14 18:19, Tim Bray wrote: > I would be very happy if some of the popular JSON tools were to implement I-JSON modes. That's easier said than done. In my maybe-not-so-popular JSON toolkit[1], I-JSON compatible strictness is achieved by performing JSON syntax checking during parsing but deferring Number conversions until the actual fetch of a value like getInt("counter"). This presumes that the argument text is preserved in order to flag "weird" integers like 156.0 which probably isn't the most common way of doing things. I'm not entirely convinced that the "Must-Ignore Policy" is universally applicable. For example there are security-related JSON constructs like JOSE where you shouldn't find any unknown properties. In the mentioned JSON toolkit this is addressed through: - checkForUnread() : Explicit deep check for unread properties - scanAway("property") : Setting a property as "read" (including possible child elements) which typically would be applied to specific "extension" sections. For long-lived sophisticated peer-to-peer applications, I doubt that any of these measures suffice because unrecognized or unread properties still means that the sender and receiver are not completely on the same page. To cope with that I'm looking into publishing objects describing entities' state wrt to extensions so that a sender never emits "garbage" or may even conclude (in advance) that it cannot communicate with the intended receiver at all. For details see "Extending Protocols" in: https://cyberphone.github.io/doc/defensive-publications/authority-objects.pdf Anders 1] https://cyberphone.github.io/doc/openkeystore/javaapi/org/webpki/json/package-summary.html > > > On Nov 14, 2016 12:31 AM, "Ladislav Lhotka" > wrote: > > > > On 14 Nov 2016, at 13:03, Mark Nottingham > wrote: > > > > It seems like I-JSON is the answer to many of the issues that have cropped up with JSON. > > > > However, as a protocol designer, it's not terribly useful to specify I-JSON, because it's very likely that people will just use their existing JSON tools. > > My understanding of I-JSON is that it specifically allows people to use their existing JSON tools. In RFC 7951 we use I-JSON and, for example, encode 64-bit integers as strings even though it is awkward and adds extra processing steps in most tools. > > Lada > > > > > A simple answer might be to define a new media type that has a header that's guaranteed to break a JSON parser prepended, but I-JSON as the body. > > > > It might be that people just strip the header and continue to process as JSON, but they have to actively do that, which may be enough of a bar to discourage it (and encourage I-JSON tools to bloom). > > > > Of course, we could define a syntax that's more deeply incompatible with JSON. Not sure if that's necessary, though. > > > > Thoughts? > > > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > > > > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Wed Nov 16 05:19:35 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5CF1297A8 for ; Wed, 16 Nov 2016 05:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rwdt7mY5QIv for ; Wed, 16 Nov 2016 05:19:33 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 01C4412966E for ; Wed, 16 Nov 2016 05:19:32 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id t125so122887360ywc.1 for ; Wed, 16 Nov 2016 05:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7ULY6zAaFNiuHqma6CpxF9qjzM3mTIabixhdbMz2GHc=; b=Xt8o+1i1TjbgHzwf0q4ZXwQqYSfJtRWsk9s9PUPxZHZCwgn17TAvOOR4+k9qimgzRm pEdI0SCastFpDL24VwH+8AWwAvHm0RggT2Puzfm/5vcLc9JhFV0rYUaJ717E7n8jmF1b Holth7njfgxjq8jShwllTLNClDaPfq13UhFmT5+KYPlCIkaI0r3x69n5H6INecfoSk/e SBIcSYUsb6n4DMpkwpkr/kWj7xmQfMXVridRaDSi79sBvcgQf/sXbxhS0fkpJjAsh5kk a0HampFIUBJkJnNNQ2pyA/8HYyFugJonh+gACGTOuP8SUebeocI8Us/3rZAfINEimwzz XIgQ== 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; bh=7ULY6zAaFNiuHqma6CpxF9qjzM3mTIabixhdbMz2GHc=; b=DBW98dymH92Jve7pB+WsdAwTIvGV1z31y2tZ0FWHPNIaWPDnqBge7cI+NdPeNK+RA9 CCcghDY4b1vTKy1kYUAU09Mi+rRIAYPYPxglCzSyT9tJVe7hfwZmnNvNhk9CailXLiWn 6ZxmVodjGVlsapjmmA/v/eKo+Y4ldZXgQWSgJJnVKDVxeF4uPljDJqfHWmviqg+1YPVs LW6yEx0HXXk84hPTkjGlnhDKybyn8PsnkIKOrGY5kCE3uilJg+NOGsMxiBOQGmp1F5fF YWNlkSnW7/mLMqEzmh9zoQnnl/Lq2zrIvODtoRfRZq5f7oYnmx+w1Tz330nu3xc71m6L QJpw== X-Gm-Message-State: ABUngve7rmskbOFaQ5HNtXOOzgw6LMwjzHcCYw3/OmFkSr+60n0NtNsxI/FEH7xDmiEoGB1OgXNu6lsm9qnf69BP X-Received: by 10.13.218.131 with SMTP id c125mr2397508ywe.341.1479302372168; Wed, 16 Nov 2016 05:19:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.110.67 with HTTP; Wed, 16 Nov 2016 05:19:11 -0800 (PST) In-Reply-To: References: <541B4A9D-97F4-4335-8B82-49682EE46D78@nic.cz> From: John Cowan Date: Wed, 16 Nov 2016 08:19:11 -0500 Message-ID: To: Anders Rundgren Content-Type: multipart/alternative; boundary=94eb2c081308690d9e05416aecf6 Archived-At: Cc: Mark Nottingham , Tim Bray , Ladislav Lhotka , json@ietf.org Subject: Re: [Json] I-JSON X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 13:19:34 -0000 --94eb2c081308690d9e05416aecf6 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 16, 2016 at 1:33 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: For long-lived sophisticated peer-to-peer applications, I doubt that any of > these > measures suffice because unrecognized or unread properties still means > that the > sender and receiver are not completely on the same page. > If the application is truly peer-to-peer (and not master-to-slave), then there is no reason why the sender and receiver should be on the same page. If you send me documents full of deep and meaningful facts, and all I do is count them and post the running total on a Web page, well, you are not the boss of me. -- John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org I suggest you solicit aid of my followers or learn the difficult art of mud-breathing. --Great-Souled Sam --94eb2c081308690d9e05416aecf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 16, 2016 at 1:33 AM, Anders Rundgren <anders.rundg= ren.net@gmail.com> wrote:
For long-lived sophi= sticated peer-to-peer applications, I doubt that any of these
measures suffice because unrecognized or unread properties still means that= the
sender and receiver are not completely on the same page.
=

If the application is truly peer-to-peer (and not maste= r-to-slave), then there is no reason why the sender and receiver should be = on the same page.=C2=A0 If you send me documents full of deep and meaningfu= l facts, and all I do is count them and post the running total on a Web pag= e, well, you are not the boss of me.

--=C2=A0
John Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://vrici.lojban.org/~cowan =C2=A0 =C2=A0 =C2=A0 = =C2=A0cowan@ccil.org
I sugg= est you solicit aid of my followers or learn the difficult art
of= mud-breathing. =C2=A0--Great-Souled Sam=C2=A0


--94eb2c081308690d9e05416aecf6-- From guerinp@magic.fr Fri Nov 18 07:29:21 2016 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6F912958D for ; Fri, 18 Nov 2016 07:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwnOArF1UwNg for ; Fri, 18 Nov 2016 07:29:20 -0800 (PST) Received: from smtp26.services.sfr.fr (smtp26.services.sfr.fr [93.17.128.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60C7128B37 for ; Fri, 18 Nov 2016 07:29:19 -0800 (PST) Received: from [192.168.10.1] (104.161.147.77.rev.sfr.net [77.147.161.104]) by msfrf2626.sfr.fr (SMTP Server) with ESMTP id AA80C1C001018 for ; Fri, 18 Nov 2016 16:29:17 +0100 (CET) Received: from [192.168.10.1] (104.161.147.77.rev.sfr.net [77.147.161.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: patrice.guerin20@sfr.fr) by msfrf2626.sfr.fr (SMTP Server) with ESMTPSA for ; Fri, 18 Nov 2016 16:29:17 +0100 (CET) Authentication-Results: sfr.fr; auth=pass (PLAIN) smtp.auth=patrice.guerin20@sfr.fr Message-ID: <582F1E4C.20406@magic.fr> Date: Fri, 18 Nov 2016 16:29:16 +0100 From: Patrice =?iso-8859-1?q?Gu=E9rin?= User-Agent: Mozilla/5.0 (Windows NT 5.0; rv:12.0) Gecko/20120429 Firefox/12.0 SeaMonkey/2.9.1 MIME-Version: 1.0 To: json@ietf.org X-sfr-mailing: LEGIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Sat, 19 Nov 2016 17:54:30 -0800 Subject: [Json] Question regarding RFC 7159 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 15:38:57 -0000 Hello, In section 4 - Objects, member name is specified as string. Is there any limitations in this case ? For example, is a name beginning with a number valid or not ? Thank you. Kind regards, Patrice.