From nobody Fri Dec 8 21:00:10 2017 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 35D061286AB; Fri, 8 Dec 2017 21:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrlyIWhowbh7; Fri, 8 Dec 2017 21:00:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 4FE22120726; Fri, 8 Dec 2017 21:00:06 -0800 (PST) Received: from [192.168.178.20] ([93.217.68.121]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M3igT-1fE7jF2o09-00rKf2; Sat, 09 Dec 2017 06:00:00 +0100 To: Alexey Melnikov , json@ietf.org Cc: jsonbis-chairs@ietf.org References: <150669032129.14118.1441258768913961205.idtracker@ietfa.amsl.com> <14b239c8-e17c-0ca2-561b-83b2bbd57516@gmx.de> <0a167b10-bb3b-7bac-2906-63c459230645@isode.com> <1510238425.3520771.1167030728.53A2E4C7@webmail.messagingengine.com> From: Julian Reschke Message-ID: Date: Sat, 9 Dec 2017 06:00:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1510238425.3520771.1167030728.53A2E4C7@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:GQfaR8xyBahKIfCx516UCRyArs/6YWQajKYM/0e7pHw7IFj/yUs 4ucmbuU26yhRKiEIZ2A/NNwATkHS5bVK/1404TinUKksJrL80qagFt5aznIXFochkQK7ErD lUF8tpytEAhB5lX59R6qU5PbTaAXlghMqno+f7HoUoGVQLNsdrsTC+YrFOAt8R5SvBPvG7r AOLwI1zcRYFAvKvGtWEfw== X-UI-Out-Filterresults: notjunk:1;V01:K0:kuFJJMvsZFc=:yqsjbVazJNKfXlARuKN9M/ sIHfO4kLrh/aNrdBtXqSzQ7APREfEMuHlfXhJ4M1Kw7SrGLTIRIoNJdkzULWxL73fOcbFxnfb toZLkHY5oshOxzAr5i2rE/EMwVNYcMrF3biF4V+wEC3mtOrusCWBVoFPo+AUqpya3N2wCGyw4 d+K/zI417Z0llXBOupjIebVEpNz3dCI4ta1JgmI44/59hkLHyb8OCTKbvuc4/OzIzu7me7AJr GCu+hjdZx+DAAQvigaRz1zvDnz6ploW2hWYTITIEQtaNJXpOozyycdGY+Y4IcT+O9MhhLNg5F BWjg6qu8nLhJEDuOCUGpAKpwuPoaZbNYdlh27yoUlH8hTiURrnsFUnt8SR+VxETW05QdC+L1e LZPKAoo8r1LeX7TiQPN691UcPVBirrwIDRbwktEvWcIVRNxYCS7p2yz25BdHmrzPabC57gqNH j3okSAkM9dyOZQXWBfKxAThu0nf/bbCeDN1Ldhwb090NKRTKelbM+vlZqsP2QN4+rWVkaQ07Z z550vJvUpqHK8EIMEeTciBQ51y2tw6ee4EYJkO55k96B0pRev6n0EGDC1VY+AMcVfCihR5mfO ROYZqMkEwVSb6Hnlpq+Y4ceDUt3gZ7FnbgUX51eiBMWcNwGSgJfdHAsogxfpw9GBlVkLCm1pZ PdyyAjRdHLFPdFs3yJOI7Xr9zO8BBs0ym02pQ9DnKKvadjrz9tk01E25XRN969DV/QpKnZV94 VIUm4KtRNqrDdQ4wLNX72/Uap6ues/ZHTC0ZDPOmGeeRqF1Yq2WVrYwXeZEa9HOsIT6nkQLFt vqK0WEqLWOhQzcscrueM1mgKjaZul1ZM4PuayzaEcYh5P7j8Z8= Archived-At: Subject: Re: [Json] jsonbis - Not having a session at IETF 100 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 05:00:09 -0000 On 2017-11-09 15:40, Alexey Melnikov wrote: > ... > I've seen a copy of the to-be-published document, but I am not sure if > it would be Ok to distribute it publicly. > ... FWIW: is the new version. Best regards, Julian From nobody Sat Dec 9 11:20:00 2017 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 9AFC61274A5; Sat, 9 Dec 2017 11:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D2PAx37s9_9; Sat, 9 Dec 2017 11:19:56 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 9005312704B; Sat, 9 Dec 2017 11:19:56 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id d141so2706274qkc.12; Sat, 09 Dec 2017 11:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Vi8Zif+ipraehNZaMoBJQdWIUoKzQGxQq4LHhAbQuLk=; b=aGTp1zxlzP0PBxVske957SKYXgMysfTuNAZexMNT2iGX8Yuj6xmePMuBMpAk2YrizV 1bVJLGagi7r+BZYO1O01N8HKiZBzO2gAWUIgkHtAlLtgyRoC02QQMaRuKRPISTp3xLIW 27x0QtB0cFqQCjAHLt5NnLCYmcHe6mDUChvhyhgIeR+wG1ImrcBZCPEcf/9jmE5ICvhS 7/RNiG9AK3AufPSlEiqJTHD6biatLtJO9SFelmop+pQVt6wHHBwmtkS/YRnkRnIBgvAf XGLwj6lSVdU+q3aub9QSPZx0n8+SIU+1D3gHHyITe9pg1oL2KZxuga+fjPOgkpAl988R 52XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Vi8Zif+ipraehNZaMoBJQdWIUoKzQGxQq4LHhAbQuLk=; b=RLKYYz1T5/36bEwOCyYR4zE4eipe7SYeqSrwbPsp65iod5WFCcf9/nYJhFHSqoogXX KPQInrpgQNu0XqsyPCxTjxbU5ehJ5bXjKNgnBdY0wjWQIS9PEpL6SyDPwTZBQgp20TMh 8JXz/VK0yED8MlBJtc6QtY4sHgL6cN4s8M6vM6KTjq8musKIgFUI11kpgMGmvf7uWxz+ LK6xfskProdAsnLVdJ11P+BAfayNIgHVdOqfYlioxbcDmkpepAsit1rIhXI1q5gXAzWZ UC7EKv+yTxpyO6DZ8RCg+rv/aB94V3BDDXGCVe1Okw2/a5Jvf3PutLs9VLbv4kOKoCIi rVFA== X-Gm-Message-State: AKGB3mLSW27NsZmiuAhUwW1dVlsyC1BkQ2QnwLQlNqRrDRfDzzfV79kE b9BJpuSsigUtOMGfxlX5yNzmUQ== X-Google-Smtp-Source: AGs4zMb9m6qtTKgefv7M25q4oiN9egbxmFEnUBmSDWWkODUkQ4Um6cSEQAq5jIU45k2HEyEC4OM9SQ== X-Received: by 10.55.115.130 with SMTP id o124mr41684329qkc.260.1512847195599; Sat, 09 Dec 2017 11:19:55 -0800 (PST) Received: from [192.168.88.142] ([199.4.160.88]) by smtp.gmail.com with ESMTPSA id k51sm2019371qtc.33.2017.12.09.11.19.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Dec 2017 11:19:54 -0800 (PST) To: Julian Reschke , Alexey Melnikov , json@ietf.org Cc: jsonbis-chairs@ietf.org References: <150669032129.14118.1441258768913961205.idtracker@ietfa.amsl.com> <14b239c8-e17c-0ca2-561b-83b2bbd57516@gmx.de> <0a167b10-bb3b-7bac-2906-63c459230645@isode.com> <1510238425.3520771.1167030728.53A2E4C7@webmail.messagingengine.com> From: "Peter F. Patel-Schneider" Message-ID: <26654843-a256-dcd4-8f4b-3910517eb3e9@gmail.com> Date: Sat, 9 Dec 2017 11:19:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-CA Archived-At: Subject: Re: [Json] jsonbis - Not having a session at IETF 100 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 19:19:59 -0000 On 12/08/2017 09:00 PM, Julian Reschke wrote: > On 2017-11-09 15:40, Alexey Melnikov wrote: >> ... >> I've seen a copy of the to-be-published document, but I am not sure if >> it would be Ok to distribute it publicly. >> ... > > FWIW: > is > the new version. > > Best regards, Julian > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >From that document: A definition of the JSON syntax was subsequently published as IETF RFC 4627 in July 2006. ECMA-262, Fifth Edition (2009) included a normative specification of the JSON grammar.  This specification, ECMA-404, replaces those earlier definitions of the JSON syntax.  Concurrently, the IETF published RFC 7158/7159 and in 2017 RFC 8259 as updates to RFC 4627. The JSON syntax specified by this specification and by RFC 8259 are intended to be identical. Not exactly what I was hoping for, but at least 8259 is listed as a normative reference. peter From nobody Sat Dec 9 14:33:41 2017 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 BDDC5126C2F for ; Sat, 9 Dec 2017 14:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPrct4HRGMhg for ; Sat, 9 Dec 2017 14:33:37 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D3A126BF0 for ; Sat, 9 Dec 2017 14:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id vB9MXWEQ011520; Sat, 9 Dec 2017 23:33:32 +0100 (CET) Received: from [192.168.217.124] (p5DC7E827.dip0.t-ipconnect.de [93.199.232.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3yvPBh2CV8zDWQX; Sat, 9 Dec 2017 23:33:32 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: <26654843-a256-dcd4-8f4b-3910517eb3e9@gmail.com> Date: Sat, 9 Dec 2017 23:33:31 +0100 Cc: JSON WG X-Mao-Original-Outgoing-Id: 534551611.362118-8a2a296490bcc712b39f7a1429000b83 Content-Transfer-Encoding: quoted-printable Message-Id: References: <150669032129.14118.1441258768913961205.idtracker@ietfa.amsl.com> <14b239c8-e17c-0ca2-561b-83b2bbd57516@gmx.de> <0a167b10-bb3b-7bac-2906-63c459230645@isode.com> <1510238425.3520771.1167030728.53A2E4C7@webmail.messagingengine.com> <26654843-a256-dcd4-8f4b-3910517eb3e9@gmail.com> To: "Peter F. Patel-Schneider" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Json] jsonbis - Not having a session at IETF 100 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 22:33:40 -0000 On Dec 9, 2017, at 20:19, Peter F. Patel-Schneider = wrote: >=20 > The > JSON syntax specified by this specification and by RFC 8259 are = intended to > be identical. And that is the juicy part =E2=80=94 ECMA-404 defines a syntax, RFC 8259 = will define the JavaScript Object Notation (JSON) Data Interchange = Format, which has been designed to use the same syntax. One of the ways in which this difference is elucidated in RFC-8259-to-be = is:=20 "Note, however, that ECMA-404 allows several practices that this specification recommends avoiding in the interests of maximal interoperability." Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Dec 10 21:46:52 2017 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 9B885126CC4; Sun, 10 Dec 2017 21:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 4L2FdaRAjM2U; Sun, 10 Dec 2017 21:46:48 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0097.outbound.protection.outlook.com [104.47.93.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C6A12702E; Sun, 10 Dec 2017 21:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PZg6Lojvtum/jc4XaB3i6XXUPPgMOj6ao7aBf5hZO3E=; b=ujRsl6zSSadNxYZsErQRCIEoVoYeuwkDbfTbbsSm8lI+g3G52cYKnCUBniaZkJalDWDMwbkjOnE0QzSQFFu2z4icT1RZJW/X9w19Va5Ww6UOlmeMqJ8QzHBE8FpVrLM4dTzVeQKVeoLANm05NCMIa4nyiY3K+gSIGdgEy54mDTE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0251.jpnprd01.prod.outlook.com (10.161.78.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Mon, 11 Dec 2017 05:46:42 +0000 To: "Peter F. Patel-Schneider" , Julian Reschke , Alexey Melnikov , json@ietf.org Cc: jsonbis-chairs@ietf.org References: <150669032129.14118.1441258768913961205.idtracker@ietfa.amsl.com> <14b239c8-e17c-0ca2-561b-83b2bbd57516@gmx.de> <0a167b10-bb3b-7bac-2906-63c459230645@isode.com> <1510238425.3520771.1167030728.53A2E4C7@webmail.messagingengine.com> <26654843-a256-dcd4-8f4b-3910517eb3e9@gmail.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <76679ff4-60f2-5744-f294-39d4029e683f@it.aoyama.ac.jp> Date: Mon, 11 Dec 2017 14:46:39 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <26654843-a256-dcd4-8f4b-3910517eb3e9@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAXPR01CA0011.jpnprd01.prod.outlook.com (10.171.236.149) To OS2PR01MB0251.jpnprd01.prod.outlook.com (10.161.78.18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e1aee90b-df77-4e5c-f80a-08d5405a8ed8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:OS2PR01MB0251; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0251; 3:NW2XqyaHumGuWLZpDf0DtRHJmkSQLYtCfXK1Z+lwwPS6oHhxkS+xvAZO/bzZBGu9dpIseWmfld+/GO+n3SiVZR5CRAvAOFISAAmsi1j7rPvK1Z5fn/lckvK2NKy7nS6Pk3RANgMevBJ6b0FqSXfd4/0L/6ZnBsDsboDXS1s5gYC4s/7w0oXjgVnmXbJNNyiT8vPtHXE5sBctM3Q23Rt/3TqerdgzkbVdSyRiEqw9JaQMRN8aO2nCafAMbdJ6DAHE; 25:QVIeCHKTxNFA79F/HvmUEh86DUwVU0mUwVPrjpwUfAzpXXS+mtPs3ibkLRzbNn+P5KMguf20Wmp+riqhbWv38LsoQXCEAduJRCFJmld+5qzXfjDmrXPHxJajgZeG3c6dR19ukzE/K57B0cGJsTQkdaJHZclR6TBInSbgFH+ec1umWDkVAbDvY2bv4pAArojWTE78imSFjSx4sls5CsZRmV/H+WdFz6EgEkI09ITIoXaK2ta+BBMx/HkvYAXg4XrjS0lZu7tsLp3z48cvi2pPM+4dhDDZQ8jIFiuoqGf8UIr2DLPwS/Dme9zW39Q5GP8iMyNUR3ty1yy3pqKWqem5BzSTeyxq/Sfm2qjrltnsvzg=; 31:ph9GN8zyK02PKQ9IYLJp7XAfqc/RFQ2RZmRa5NiR3Wmy9ts/ZEp7oAneIS752x2atpw/7ybPSPjx0WlgtBxeyjL1GBwlM0Pd/eH+LT0R1OU+3+bm2aqA9WYC1o/vjBPjBVtFcf4aI63g3v1Lt569XR+/PutVl+jFDmc+zKvwXBWAgxiE0HqAPxOARQ23uaWRf31uIs/lnzY98q/Y00XBQx3atBzIdFnpy5Zfy6wFjqs= X-MS-TrafficTypeDiagnostic: OS2PR01MB0251: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231022)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011); SRVR:OS2PR01MB0251; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:OS2PR01MB0251; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0251; 4:vAOhjIWz/b0Q1nu68svhsbsC2m7Pw1I/a2MvmMEJUVY9FlKxFroNmiozO83HUz8VqvWo7wOcZhYV3VdUlP5FNZjp9WpJrme/LGlEC6Z1/5zyhXYVDTNF8Wr8+A1aNNrKBU2r4zTtQb/WVdiXOtDk6Q7iBSClUBvYs04n9EUkSFVDGNCTZwo0OMBwe9YOX5bjyuuMenyb7Pron/ckIJE6jNgygmJ65oLfJ5B8GyEysZF/vLPUtQKuNZQSdauMFZNoG2rN02MusTBWNKTdKyxqVg== X-Forefront-PRVS: 0518EEFB48 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(346002)(376002)(39830400002)(24454002)(189003)(199004)(51444003)(65956001)(50466002)(47776003)(58126008)(110136005)(65826007)(6246003)(53936002)(65806001)(66066001)(97736004)(31696002)(5660300001)(25786009)(86362001)(8936002)(74482002)(49976008)(316002)(229853002)(59450400001)(36916002)(68736007)(16576012)(966005)(6306002)(16526018)(76176011)(478600001)(52116002)(2486003)(83506002)(67846002)(8666007)(786003)(90366009)(6486002)(7736002)(23676004)(39060400002)(305945005)(53546010)(2870700001)(93886005)(64126003)(106356001)(105586002)(52146003)(81156014)(8676002)(2906002)(42882006)(6116002)(81166006)(33646002)(3846002)(4326008)(6666003)(2950100002)(31686004)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0251; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMjUxOzIzOnVpcGpOMURBb3FqdGNIZ0hSZ3BxdXcxVm9Y?= =?utf-8?B?RjA4Y2xwZjIxV2dOTXBCRGhpWExnbzVydTVPTXc2dGVPVlRuVG9TT3FKbzU2?= =?utf-8?B?TEdyY0w2WTg0YnduV09ienk4V015clUwSFVUejBVMk85ZGZrVks2bGRPM0xh?= =?utf-8?B?cmtPOHVoZTM1aXUyeUJPSTFnMW9sbkNpS0h4eVRpa3hBNElxSzduazQ2aEdG?= =?utf-8?B?ekI1V1UvbHhwUzhPZ2lKaTU4TlRTR3R6Yk5XM2ViMWU3cTRkdzI0UnhnUFdQ?= =?utf-8?B?b1d0bkV6VVFubTY1Rk9mekdEUERwajYyZWdTRkkwRmd1VThxMHJwaDVaTnd1?= =?utf-8?B?bGVxblNvdWlEeW5FUXhCZFpVa2hmdFFiMFlMM3FRaFJObmpCamVEd1kwNjVy?= =?utf-8?B?eGdDRFBSd3BreGp0UXNoMlF0RHRjSWRDdlA5TDhMdFB4UUtrclNldnliMExi?= =?utf-8?B?Yy81cTMyNjVtblNxdysrZVFZSjIxVThUQkJ3Wm9nN3laNGYwTDhEV21WSTV2?= =?utf-8?B?RGtZZWphMVBHNDBkcXJOSnBBTmFQUzIwa21LTWpZcUg4UEdtc0NPY3VMb29V?= =?utf-8?B?UktJempJdWQwNUZiblpza0NTWTdFbThld2VpVkNIdGE0ZEdTcnpINkRBK3Mz?= =?utf-8?B?OVJ5SEJDY211TEcwNG9LK2tWdDZ2ZkozTHVURkJFaFo5MUxON3B2UXdodGxO?= =?utf-8?B?RXhHSU9FMktzMHJnREVZY21TdTlQS0ZXOFIyRzRIb1NDMzB1OHBRM1ZCZkVW?= =?utf-8?B?OXV2Q0ZiRmtvVlZIOVR0emQ4bWFQQ0E4ajJNZFI3NWFxcitZNEF0YWlyWEtl?= =?utf-8?B?NWxMSjhPVnpBNTZpTTNLcXBJV2VIdkdyMXBNYkc0YlRlakR2WmpOM3hEek50?= =?utf-8?B?c2p5by9MSVZ5cFFseExZODB2NUcvTGFrQjFHRDRFa0VFUnJRVDRZbWFDcEh2?= =?utf-8?B?SjBHSHBKeXNXQ2R3N2VzUGo3MGoycTQyWTlHblR4cjlXb3h6MU15MjU1d3lk?= =?utf-8?B?dXpaOFFGek9TaS9mcS95V2tvQnRiWFlMbFk0bnF1dTYyR21zSmp3TjhRQWQv?= =?utf-8?B?bXEzNTZnVXNZeU1KTCt5c0d6RHJMMW5URWdnUUNOZUx4c2pCOEx0ODRTMUxO?= =?utf-8?B?NHZ6V3JaUDJHcjhHQWR5WEVNNHdKeUZ2cUFzcEEydUU5R09halVReFMyaXZs?= =?utf-8?B?VHFTZU16SVB2K01wMktPQ2RTVUNiVTBWYWExNk5rYnRsWm9uQ3EvY0VkZDc2?= =?utf-8?B?Nkkwb2hZM2hwYzVRMHlxMDgzRFBBQVZPN3JnVWR5TDNHQ25oU2d0M00wK2FB?= =?utf-8?B?YUNTZ1l5RjMyQ2NTUDhCRjlsN012NzlMaTVGN01wTkJqRWYwb2R5cW9zd2Q5?= =?utf-8?B?aitVN1N2enFrNzN6Ny9pQjFsYm9aanlWdFhBMDBPZTFjSzNraWVkR29XbGV6?= =?utf-8?B?R1Q3VTQ3M044OWpsRzBYa1l1cWxuNnR5azNBVEJhbUhSQ0xEZlVZMmIrN0lS?= =?utf-8?B?K0JKQ1R2STgvdzJjVUdzT2tQRi9UMEZPMEU2ZEVuRmNLbUNhRXB6OEozT3Iv?= =?utf-8?B?K0diY1I1SUtwOWVHV1ArbWYveXVCNVhaeHZ5alJQNkx5M0FYendxVmpWd05O?= =?utf-8?B?MFY5WEN5YzlSd0o0RTFJSXFZMzYyOVhOSnhscGhsdzJUanFCTUk2SXYwRHlK?= =?utf-8?B?Njg1WjZTUnRocjYybzcxN2V3S09ISnFKT0JRa0NybXE0UkJIRHhTbDFONkkx?= =?utf-8?B?c1A1TzI5TmU3UW1kM0JOYnhjUWNjSnh1bkQveE5WaEt2WlpVN0lJaVRkN3pD?= =?utf-8?B?Z3NSZ3pITURuOVo2bzNCNm02Qk5TOGJYUTFndjRmYldaRnlYdDJzZUxSUU1o?= =?utf-8?B?NGZrdWVqeGRXeFdSNEVORkp5T3dwRkZSL3NQZDIreVVObFRqRUx6TkYvSlpO?= =?utf-8?B?eWpLQ0V0WlRCZmdEaVZaTTgzTGtJaWNQeFIzUjdnTzhGamlRcDVOdmZNKzhF?= =?utf-8?B?KzJxTjNlNXc2SElMaVVLQjMwTitCV2ZNMWpTcmNDVlA5UnFGRGRNZ0VLcUtQ?= =?utf-8?B?aFZnTWxyMGh6RzFzdGVsU204VEdjWkQ4Tm9vVkc0c2lBQTFYbnNJOXd4aExs?= =?utf-8?Q?pfh/H36JMLZ0vNmo6FcvbvovlVbXBYgz62RD5DTdK1K6?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0251; 6:3E7XBuLKmn6fMTM5nzTBFUJG9YL0w5HXmdnPGYRaykigTNIBdmJU67xzJH0LbsEQaCQYZvMFS4/lV/wi66u0FnJVJIKNjJBt8VGzYheIiYnX+JEDLJJ/BvOlRgQL64pxrqfzRgPoByH8fs8fjrZ9nwcoujNU+kFuAv0r8vLtB9Db3iUlmSWh4dpHroY3F7pymnKsSPVmI7f+4d+oXL15y5eS8Mg+TC0mTeaE4Pj1/aJEgbtbY4PsHmuHEP+WDfS/a0+Hf6Na85Pz9s+puZqfAKi1eVB0F/PjSXOjQvX1OlTF1tfwBzt5nDd2dGxsOXoCb2UD0ZeulOaKE13wOMAkmEyJA+0oU3TF8XOinoRPMuo=; 5:XVWhtEPh+yPTHR/KbvCp1hhCsQwRlTwE7idnwD9mbioH4OkDfMfYm17v1DfzP++Ni2pe5w8crM5pF1GoQLOl9SxmWsy4sgxFFc8lDiF2kwIZddKasSho1nSQsjHRkjvJUBgFvKTyPxoO4Zi/5QYuQdeCudzmplFgIwZdvCfZLKA=; 24:CawzulXx5v7NiPAGeGaKlNtyRhxyQ7v2W3W//fGpfwAKnXUsRaS5FdIQ5Vp2bD3w00Uy802D43EiMGe4hwsy9vro2wgAmkD1yGfxPFhVtNU=; 7:wzDhGVbLUOVfszyPfi74BuwBMFQFZqTFO6XP9Mm+woDGg4wtI/RofJcXj06PQm54+1GGK0raIF6ZZBwVaAj8a9oBzzoMnHS48UVJgfuKjHtBMQqLQxJFGT3wAcncpJtvV1LqfmovLc/s7DxcGudkaqVkoSjHlwk2TcCuujNSXHuF58ivfEaAjLeIe2nTlNgesFymjmjKLc75t33xSAxOYOyigGI5WLrwbkcr/lMzuzoF+DbTZ8Gv9x9M/IrtshHJ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Dec 2017 05:46:42.0455 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e1aee90b-df77-4e5c-f80a-08d5405a8ed8 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0251 Archived-At: Subject: Re: [Json] jsonbis - Not having a session at IETF 100 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 05:46:51 -0000 On 2017/12/10 04:19, Peter F. Patel-Schneider wrote: > On 12/08/2017 09:00 PM, Julian Reschke wrote: >> FWIW: >> is >> the new version. >> >> Best regards, Julian >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json > >>From that document: > > A definition of the JSON syntax was subsequently published as IETF RFC 4627 > in July 2006. ECMA-262, Fifth Edition (2009) included a normative > specification of the JSON grammar.  This specification, ECMA-404, replaces > those earlier definitions of the JSON syntax.  Concurrently, the IETF > published RFC 7158/7159 and in 2017 RFC 8259 as updates to RFC 4627. The > JSON syntax specified by this specification and by RFC 8259 are intended to > be identical. > > > Not exactly what I was hoping for, but at least 8259 is listed as a normative > reference. There is also this text, in Section 3 (Normative References): >>>>>>>> Bray, T., Ed. "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259. This specification and [RFC 8259] both provide specifications of the JSON grammar but do so using different formalisms. The intent is that both specifications define the same syntactic language. If a difference is found between them, Ecma International and the IETF will work together to update both documents. If an error is found with either document, the other should be examined to see if it has a similar error, and fixed if possible. If either document is changed in the future, Ecma International and the IETF will work together to ensure that the two documents stay aligned through the change. RFC 8259, also defines various semantic restrictions on the use of the JSON syntax. Those restrictions are not normative for this specification. >>>>>>>> I think that this is quite precise and adequate. The only thing I'd fix is the comma just after "RFC 8259" in the last sentence. I'm personally quite satisfied with this, and would like to thank everybody involved for their hard work in coordinating this behind the scenes. Regards, Martin. From nobody Tue Dec 12 15:56:00 2017 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 0FD7F126DCA for ; Tue, 12 Dec 2017 15:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKMQjHSq7ZOE for ; Tue, 12 Dec 2017 15:55:57 -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 B5B74126CBF for ; Tue, 12 Dec 2017 15:55:56 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id 64so1818168wme.3 for ; Tue, 12 Dec 2017 15:55:56 -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; bh=YSRB0C7w2120pcREhC2JKp2T9DiF4PBTZem9skSu7AU=; b=T6lujqJkrNV+9NZoWXXCc/8YiO7uTVAl1++C4G+7nCx4+hvNbeCjoxNBdB3WAC6IvI 1yTqU1DkMs8oRrRqaGEi1xqIEdO87Vhqg3UTsgGC9L+KgiCtZNaDE98OEJsPlrHaca5h lTN9feW0gxG/fQigS85jTgbjii21FWbgFXXtrcvMJ9soWnzEAQuv8RFjMdBOhMn6m4qY 8nBmttc5annqfYGhus10sjqVQfA2AWJW+0mzO0N0MNKnzXCGa2Bfnjr7S1O/RxtAh3NF fse6gZJ3NES5+6GDbxaw/1LkLu800ds6DON5l5pKDYkYYT+yTkepq5WRv0qvj55XZAOk XYsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YSRB0C7w2120pcREhC2JKp2T9DiF4PBTZem9skSu7AU=; b=H7jbaayzWy8rYQjEjSwLzUBWvpz64tRy7OF45VFw3NgwpXJZdv8U7ZpCnWcciL3xGF VXb2Q5zw4HUIJyJCbIh4rREnUgd6U9CpCPfZlnsFZj0BI7aJYiP9ycaAInxHbXTn1jgQ 61ZBig6tWJrfZZquTsQxkZe+zaLDGUzFMhsjUpr20ero9iqoGk/WwqgETitgNxXuG4Ru eXEtE9xhnVbbGIM19DXdNdC2IlaOLO/enhwhc8VZkXU0ZwU4PeeaJILKTQ+wiYqYffmJ VmnWQTxx4CScCtoRiYqL1eGiZXE4QxK6rNb9yXoU2Q95sFRTa1mx9VLsMuhh+Zbhyr/O mCog== X-Gm-Message-State: AKGB3mKYQOYAqm9tynDRJpsB1DVkslIdokTCy/b7ItTVslGLKbQyTFqY r9Wwvqxj/z3l/4/46DK5E4RLU+ss7EhCKEgazctn8POc X-Google-Smtp-Source: ACJfBou7Gmlc59KtCWqshhkwqEsEgJUnA3i/va8IwZ4//SrmdDNois5lC5KlaE8X1ek46e8aYAWi9DiMsuZFfxLJOhg= X-Received: by 10.80.139.180 with SMTP id m49mr5258965edm.36.1513122954983; Tue, 12 Dec 2017 15:55:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.243.1 with HTTP; Tue, 12 Dec 2017 15:55:54 -0800 (PST) X-Originating-IP: [64.141.86.146] Received: by 10.80.243.1 with HTTP; Tue, 12 Dec 2017 15:55:54 -0800 (PST) In-Reply-To: References: From: Tim Bray Date: Tue, 12 Dec 2017 23:55:54 +0000 Message-ID: To: json@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19578e3bd9bc05602d640c" Archived-At: Subject: [Json] Fwd: Inconsistency between RFC 8259 and RFC 5234 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 23:55:59 -0000 --94eb2c19578e3bd9bc05602d640c Content-Type: text/plain; charset="UTF-8" Ouch, I think he's right. ---------- Forwarded message ---------- From: "Dale Schumacher" Date: Dec 12, 2017 12:42 PM Subject: Inconsistency between RFC 8259 and RFC 5234 To: "Tim Bray" Cc: "Douglas Crockford" I'm attempted to reach out to you directly, since https://www.rfc-editor. org/info/rfc8259 (the recommended feedback channel) currently returns "RFC 8259 does not exist". It appears that the JSON grammar makes use of two "Core" ABNF rules: DIGIT = %x30-39 ; 0-9 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" However, JSON allows both upper and lower case in Unicode escapes within a string. In which case, the grammar for such escapes: char = unescaped / escape ( %x22 / ; " quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ; r carriage return U+000D %x74 / ; t tab U+0009 %x75 4HEXDIG ) ; uXXXX U+XXXX is incorrect. If I may be permitted a recommendation, I would suggest that the JSON grammar _not_ use the "Core" ABNF rules. Instead it could provide local definitions such as: digit0-9 = %x30-39 ; 0-9 hexdigit = digit0-9 / %x41-x46 / %x61-66 The use of "Core" ABNF rules doesn't seem to save much, in this case, and the indirection makes it easy to overlook this inconsistency. Thanks for your consideration, Dale Schumacher --94eb2c19578e3bd9bc05602d640c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ouch, I think he's right.
---------- Forwarded message ----------
From: "Dale Schumacher= " <dale.schumacher@gma= il.com>
Date: Dec 12, 2017 12:42 PM
Subject: Inconsistency bet= ween RFC 8259 and RFC 5234
To: "Tim Bray" <tbray@textuality.com>
Cc: "Douglas C= rockford" <douglas@crockfo= rd.com>

I'm at= tempted to reach out to you directly, since=C2=A0https://www.rfc-editor.org/info/rfc8259 (th= e recommended feedback channel) currently returns "RFC 8259 does not exist".

It appears that the JSON grammar makes use of two= "Core" ABNF rules:

         DIGIT          =3D=
  %x30-39
                                ; 0-9

         HEXDIG         =3D  DIGIT / "A" / "B" / "=
C" / "D" / "E" / "F"

However, JSON allows both upper and lower c= ase in Unicode escapes within a string. In which case, the grammar for such= escapes:

      char =3D unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

is incorrect.

If I= may be permitted a recommendation, I would suggest that the JSON grammar _= not_ use the "Core" ABNF rules. Instead it could provide local de= finitions such as:

      digit0-9 =3D %x30-39      =
   ; 0-9

      hexdigit =3D digit0-9 / %x41-x46 / %x61-66

T= he use of "Core" ABNF rules doesn't seem to save much, in thi= s case, and the indirection makes it easy to overlook this inconsistency.

Thanks for your consideration,
Dale Schum= acher

--94eb2c19578e3bd9bc05602d640c-- From nobody Tue Dec 12 16:04:10 2017 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 BC686126DCA for ; Tue, 12 Dec 2017 16:04:08 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=iku06Wwp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RMKN17WM 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 LVgBtHfeutJG for ; Tue, 12 Dec 2017 16:04:05 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE99126CBF for ; Tue, 12 Dec 2017 16:04:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4B86720BCF; Tue, 12 Dec 2017 19:04:04 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 12 Dec 2017 19:04:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=RgdZHCHiXuXRVSX4wR+bo6hl8EefR FSDicWIW9qVrXk=; b=iku06Wwp14fiPuJaCgYsjEobHgsU9YIFtdJNhal31BBf3 1ubYlnW8IGnV5EeBGUi0HzXoNU0/hjM6+wf+O3mq8v2gXSmx0OQRAQXTzZJWK6hU mLXrJA9EICmE+wFZjRwTB2h4Uwk2qCRFziYZwBXaJja5WM39vM5lF50S+mu/jkga QK+HxTzwxXH/HM2XlvlKoTP+Omws4QnA8kv567vDO/rBWKHP2lxP0Pq7zhYSTMrA e4IHu9+TeJ2je+srdTQGYdLVrLItrWE7UTO3SyvflorYFbwhB1AlO0NIK8n+DF7b MbB04Y3N7qzR+QhoMoIj5TinxJZ9tnsstGSnQGb5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=RgdZHC HiXuXRVSX4wR+bo6hl8EefRFSDicWIW9qVrXk=; b=RMKN17WMA5jzDyk8218c3f HIB5HR8ObB2y7GH0bDoHlleGOsjcZ6tKLYZeOpEGHDGRTA83BD0bLm/Ahm6j3uX6 fkE6Jrr3JiTiwl1hPnysp9YWZ9aEP1C4nfDy6A3LKN2RzdjGEhXRKp5Ghis2FyGs 9PTyFQ/qlIwgydx7Be7ScIlrDLF3cuqJB5iYPkJ+tZx5hvX1R/UF7Em8KsjHMqnW TzUffaes+n0lBHovtXlPCSEJpfqjiy+qlkNs7g49e57EpzrvbwHaSsVrB2PTkFnC 8DEFCAdAJBuU40HXdx01O6uC44GjkExlgxjRpbEBai7WukAgl+mp9vmyoi65JbVg == X-ME-Sender: Received: from [192.168.1.18] (cpe-144-136-175-28.sa.bigpond.net.au [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 4CA46240A4; Tue, 12 Dec 2017 19:04:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Mark Nottingham In-Reply-To: Date: Wed, 13 Dec 2017 11:03:58 +1100 Cc: json@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <87DE6791-D273-4EE7-8F4E-F9ADE4F57FFB@mnot.net> References: To: Tim Bray X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Json] Inconsistency between RFC 8259 and RFC 5234 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:04:09 -0000 Nope, it's OK. 5234 section 2.3: """ Literal text strings are interpreted as a concatenated set of printable characters. NOTE: ABNF strings are case insensitive and the character set for these strings is US-ASCII. Hence: rulename =3D "abc" and: rulename =3D "aBc" will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and "ABC". To specify a rule that is case sensitive, specify the characters individually. For example: rulename =3D %d97 %d98 %d99 or rulename =3D %d97.98.99 will match only the string that comprises only the lowercase characters, abc. """ > On 13 Dec 2017, at 10:55 am, Tim Bray wrote: >=20 > Ouch, I think he's right. > ---------- Forwarded message ---------- > From: "Dale Schumacher" > Date: Dec 12, 2017 12:42 PM > Subject: Inconsistency between RFC 8259 and RFC 5234 > To: "Tim Bray" > Cc: "Douglas Crockford" >=20 > I'm attempted to reach out to you directly, since = https://www.rfc-editor.org/info/rfc8259 (the recommended feedback = channel) currently returns "RFC 8259 does not exist". >=20 > It appears that the JSON grammar makes use of two "Core" ABNF rules: >=20 > DIGIT =3D %x30-39 > ; 0-9 >=20 > HEXDIG =3D DIGIT / "A" / "B" / "C" / "D" / "E" / "F" >=20 >=20 > However, JSON allows both upper and lower case in Unicode escapes = within a string. In which case, the grammar for such escapes: >=20 > char =3D unescaped / > escape ( > %x22 / ; " quotation mark U+0022 > %x5C / ; \ reverse solidus U+005C > %x2F / ; / solidus U+002F > %x62 / ; b backspace U+0008 > %x66 / ; f form feed U+000C > %x6E / ; n line feed U+000A > %x72 / ; r carriage return U+000D > %x74 / ; t tab U+0009 > %x75 4HEXDIG ) ; uXXXX U+XXXX >=20 >=20 > is incorrect. >=20 > If I may be permitted a recommendation, I would suggest that the JSON = grammar _not_ use the "Core" ABNF rules. Instead it could provide local = definitions such as: >=20 > digit0-9 =3D %x30-39 ; 0-9 >=20 > hexdigit =3D digit0-9 / %x41-x46 / %x61-66 >=20 >=20 > The use of "Core" ABNF rules doesn't seem to save much, in this case, = and the indirection makes it easy to overlook this inconsistency. >=20 > Thanks for your consideration, > Dale Schumacher >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json -- Mark Nottingham https://www.mnot.net/ From nobody Tue Dec 12 16:22:15 2017 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 DEB8712704A for ; Tue, 12 Dec 2017 16:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Q-MHDuG0k0o for ; Tue, 12 Dec 2017 16:22:09 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E97D126CBF for ; Tue, 12 Dec 2017 16:22:09 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id b76so1914413wmg.1 for ; Tue, 12 Dec 2017 16:22:09 -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=bOYGcefUc9LeP5y2vmq+iyZBsP/noFBqMwfcqi++cE4=; b=mrBWpAzsGuJEBkDVVbq4daeRTSmUwFAgK6aeE7nIYFYuuHkayz0Sg5JpYvYsUBXPu3 +fxMg7HJL94LM/2uplMsGAm4diCcleBHH9c0vUhjPpCiIZXpm70IVA7s5rmTxzAPtpbQ W5iyZ6A4s30/JCNwc3iH9sIgGSvokrKEevLjjPx/kBxhAbpgsdE1vdOjqk1R/pLKQRrc QYubeP9NI5+zRajk4USrJVWlamqLWOtlcT+iHdVNlBSc+pjhUjo+/x80hhFbf9Rvra+X 75aUdmvRCZhz9n5elC5K7so9e6Hnvd+QkjXX/N7k1krpZofOSDhUQQbUfWK2BT7L8aYB Owmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bOYGcefUc9LeP5y2vmq+iyZBsP/noFBqMwfcqi++cE4=; b=WIdrQQMPc0XFYbtVfeuegZ38Y1kiIBFewzbatjn1ONI5z8fvg8rOi5tGZIc5wBxI9g 1F8ZsXrzhJmJWwfBpiNg6VxazumdId5sqfM+yXNYJMJbfZ5wIAR2YPWN5catRFgt4R0d ZB7Ai8h69r4mJUwe3ATrF0qnVY/VY3ATEnfLNL7ULeu8iS17CAYSoT9cd7O4cL62FE6c UVkhnTVVjCXnH3R6BWK6NJzA6vOvPmDBevNFjvcNSU3RcPR4kqw1o7Ql3MGTfGDRZkvb 9U38w356eeSK4py+vsWkp1JqGgfEzxrS1+MMnUyUKVRjh93WzLA/34QmaX7BXTNQqyhG ofzw== X-Gm-Message-State: AKGB3mKZFAFx+ET2GorIe1uTQjrjVa1dagX3azZsU0F2tDz5WZ8+PDxb 4OZBLsb+JqnhpHBKUlLh7sO6b8mBLsFaTaN/mAFN9QxZ X-Google-Smtp-Source: ACJfBosacmGIMCffIdivqXsFJcGNl1AuMIIA8bo8xjAcSmqD7j2/h786UagBkC/ngxNQQoPVrj4gVJPTvhkEhIrmEKo= X-Received: by 10.80.139.180 with SMTP id m49mr5344963edm.36.1513124527974; Tue, 12 Dec 2017 16:22:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.243.1 with HTTP; Tue, 12 Dec 2017 16:22:07 -0800 (PST) X-Originating-IP: [64.141.86.146] Received: by 10.80.243.1 with HTTP; Tue, 12 Dec 2017 16:22:07 -0800 (PST) In-Reply-To: <87DE6791-D273-4EE7-8F4E-F9ADE4F57FFB@mnot.net> References: <87DE6791-D273-4EE7-8F4E-F9ADE4F57FFB@mnot.net> From: Tim Bray Date: Wed, 13 Dec 2017 00:22:07 +0000 Message-ID: To: Mark Nottingham Cc: json@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19578efdb41005602dc14c" Archived-At: Subject: Re: [Json] Inconsistency between RFC 8259 and RFC 5234 X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:22:14 -0000 --94eb2c19578efdb41005602dc14c Content-Type: text/plain; charset="UTF-8" /me sighs in relief. On Dec 12, 2017 4:04 PM, "Mark Nottingham" wrote: > Nope, it's OK. 5234 section 2.3: > > """ > Literal text strings are interpreted as a concatenated set of > printable characters. > > NOTE: > > ABNF strings are case insensitive and the character set for these > strings is US-ASCII. > > Hence: > > rulename = "abc" > > and: > > rulename = "aBc" > > will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and > "ABC". > > To specify a rule that is case sensitive, specify the characters > individually. > > For example: > > rulename = %d97 %d98 %d99 > > or > > rulename = %d97.98.99 > > will match only the string that comprises only the lowercase > characters, abc. > """ > > > > > On 13 Dec 2017, at 10:55 am, Tim Bray wrote: > > > > Ouch, I think he's right. > > ---------- Forwarded message ---------- > > From: "Dale Schumacher" > > Date: Dec 12, 2017 12:42 PM > > Subject: Inconsistency between RFC 8259 and RFC 5234 > > To: "Tim Bray" > > Cc: "Douglas Crockford" > > > > I'm attempted to reach out to you directly, since > https://www.rfc-editor.org/info/rfc8259 (the recommended feedback > channel) currently returns "RFC 8259 does not exist". > > > > It appears that the JSON grammar makes use of two "Core" ABNF rules: > > > > DIGIT = %x30-39 > > ; 0-9 > > > > HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" > > > > > > However, JSON allows both upper and lower case in Unicode escapes within > a string. In which case, the grammar for such escapes: > > > > char = unescaped / > > escape ( > > %x22 / ; " quotation mark U+0022 > > %x5C / ; \ reverse solidus U+005C > > %x2F / ; / solidus U+002F > > %x62 / ; b backspace U+0008 > > %x66 / ; f form feed U+000C > > %x6E / ; n line feed U+000A > > %x72 / ; r carriage return U+000D > > %x74 / ; t tab U+0009 > > %x75 4HEXDIG ) ; uXXXX U+XXXX > > > > > > is incorrect. > > > > If I may be permitted a recommendation, I would suggest that the JSON > grammar _not_ use the "Core" ABNF rules. Instead it could provide local > definitions such as: > > > > digit0-9 = %x30-39 ; 0-9 > > > > hexdigit = digit0-9 / %x41-x46 / %x61-66 > > > > > > The use of "Core" ABNF rules doesn't seem to save much, in this case, > and the indirection makes it easy to overlook this inconsistency. > > > > Thanks for your consideration, > > Dale Schumacher > > > > _______________________________________________ > > json mailing list > > json@ietf.org > > https://www.ietf.org/mailman/listinfo/json > > -- > Mark Nottingham https://www.mnot.net/ > > --94eb2c19578efdb41005602dc14c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
/me sighs in relief.

=
On Dec 12, 2017 4:04 PM, "Mark Nottingham&q= uot; <mnot@mnot.net> wrote:
Nope, it's OK. 5234 = section 2.3:

"""
=C2=A0 =C2=A0Literal text strings are interpreted as a concatenated set of<= br> =C2=A0 =C2=A0printable characters.

=C2=A0 =C2=A0NOTE:

=C2=A0 =C2=A0 =C2=A0 ABNF strings are case insensitive and the character se= t for these
=C2=A0 =C2=A0 =C2=A0 strings is US-ASCII.

=C2=A0 =C2=A0Hence:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rulename =3D "abc"

=C2=A0 =C2=A0and:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rulename =3D "aBc"

=C2=A0 =C2=A0will match "abc", "Abc", "aBc", = "abC", "ABc", "aBC", "AbC", and
=C2=A0 =C2=A0"ABC".

=C2=A0 =C2=A0 =C2=A0 To specify a rule that is case sensitive, specify the = characters
=C2=A0 =C2=A0 =C2=A0 individually.

=C2=A0 =C2=A0For example:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rulename=C2=A0 =C2=A0 =3D=C2=A0 %d97 %d98= %d99

=C2=A0 =C2=A0or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rulename=C2=A0 =C2=A0 =3D=C2=A0 %d97.98.9= 9

=C2=A0 =C2=A0will match only the string that comprises only the lowercase =C2=A0 =C2=A0characters, abc.
"""



> On 13 Dec 2017, at 10:55 am, Tim Bray <tbray@textuality.com> wrote:
>
> Ouch, I think he's right.
> ---------- Forwarded message ----------
> From: "Dale Schumacher" <dale.schumacher@gmail.com>
> Date: Dec 12, 2017 12:42 PM
> Subject: Inconsistency between RFC 8259 and RFC 5234
> To: "Tim Bray" <t= bray@textuality.com>
> Cc: "Douglas Crockford" <douglas@crockford.com>
>
> I'm attempted to reach out to you directly, since ht= tps://www.rfc-editor.org/info/rfc8259 (the recommended feedback ch= annel) currently returns "RFC 8259 does not exist".
>
> It appears that the JSON grammar makes use of two "Core" ABN= F rules:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DIGIT=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D=C2=A0 %x30-39
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; 0-9
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HEXDIG=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=3D=C2=A0 DIGIT / "A" / "B" / "C" / &qu= ot;D" / "E" / "F"
>
>
> However, JSON allows both upper and lower case in Unicode escapes with= in a string. In which case, the grammar for such escapes:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0char =3D unescaped /
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0escape (
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x22 /=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ; "=C2=A0 =C2=A0 quotation mark=C2=A0 U+0022<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x5C /=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ; \=C2=A0 =C2=A0 reverse solidus U+005C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x2F /=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ; /=C2=A0 =C2=A0 solidus=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0U+002F
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x62 /=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ; b=C2=A0 =C2=A0 backspace=C2=A0 =C2=A0 =C2=A0 =C2= =A0U+0008
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x66 /=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ; f=C2=A0 =C2=A0 form feed=C2=A0 =C2=A0 =C2=A0 =C2= =A0U+000C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x6E /=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ; n=C2=A0 =C2=A0 line feed=C2=A0 =C2=A0 =C2=A0 =C2= =A0U+000A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x72 /=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ; r=C2=A0 =C2=A0 carriage return U+000D
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x74 /=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ; t=C2=A0 =C2=A0 tab=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0U+0009
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%x75 4HEXDIG )= =C2=A0 ; uXXXX=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 U+XXX= X
>
>
> is incorrect.
>
> If I may be permitted a recommendation, I would suggest that the JSON = grammar _not_ use the "Core" ABNF rules. Instead it could provide= local definitions such as:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0digit0-9 =3D %x30-39=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0; 0-9
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0hexdigit =3D digit0-9 / %x41-x46 / %x61-66 >
>
> The use of "Core" ABNF rules doesn't seem to save much, = in this case, and the indirection makes it easy to overlook this inconsiste= ncy.
>
> Thanks for your consideration,
> Dale Schumacher
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--94eb2c19578efdb41005602dc14c-- From nobody Wed Dec 13 11:16:43 2017 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 95282128B38; Wed, 13 Dec 2017 11:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lCYbi8pN4kNo; Wed, 13 Dec 2017 11:16:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153FD1275F4; Wed, 13 Dec 2017 11:16:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 299BCB813D2; Wed, 13 Dec 2017 11:16:09 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, json@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20171213191609.299BCB813D2@rfc-editor.org> Date: Wed, 13 Dec 2017 11:16:09 -0800 (PST) Archived-At: Subject: [Json] =?utf-8?q?RFC_8259_on_The_JavaScript_Object_Notation_=28JS?= =?utf-8?q?ON=29_Data_Interchange_Format?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 19:16:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8259 Title: The JavaScript Object Notation (JSON) Data Interchange Format Author: T. Bray, Ed. Status: Standards Track Stream: IETF Date: December 2017 Mailbox: tbray@textuality.com Pages: 16 Characters: 28360 Obsoletes: RFC 7159 I-D Tag: draft-ietf-jsonbis-rfc7159bis-04.txt URL: https://www.rfc-editor.org/info/rfc8259 DOI: 10.17487/RFC8259 JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document is a product of the Javascript Object Notation Update Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Dec 13 11:48:36 2017 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 4823412704B; Wed, 13 Dec 2017 11:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MtsEEunGapHD; Wed, 13 Dec 2017 11:48:27 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D32126D45; Wed, 13 Dec 2017 11:48:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A5389B80E26; Wed, 13 Dec 2017 11:48:01 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, json@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20171213194801.A5389B80E26@rfc-editor.org> Date: Wed, 13 Dec 2017 11:48:01 -0800 (PST) Archived-At: Subject: [Json] =?utf-8?q?Corrected_Announcement=3A_STD_90=2C_RFC_8259_on_?= =?utf-8?q?The_JavaScript_Object_Notation_=28JSON=29_Data_Interchange_Form?= =?utf-8?q?at?= X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 19:48:29 -0000 A new Request for Comments is now available in online RFC libraries. STD 90 RFC 8259 Title: The JavaScript Object Notation (JSON) Data Interchange Format Author: T. Bray, Ed. Status: Standards Track Stream: IETF Date: December 2017 Mailbox: tbray@textuality.com Pages: 16 Characters: 28360 Obsoletes: RFC 7159 See Also: STD 90 I-D Tag: draft-ietf-jsonbis-rfc7159bis-04.txt URL: https://www.rfc-editor.org/info/rfc8259 DOI: 10.17487/RFC8259 JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document is a product of the Javascript Object Notation Update Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Dec 13 14:09:22 2017 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 4B6101205F0 for ; Wed, 13 Dec 2017 14:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAFmTtKOwhh0 for ; Wed, 13 Dec 2017 14:09:18 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 C81D8127867 for ; Wed, 13 Dec 2017 14:09:16 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id v21so3324446oth.6 for ; Wed, 13 Dec 2017 14:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to; bh=0g7fo90hbNs/3WFujXrrTTOP4wyTJ5nsnUa9fgxwBGM=; b=Mgd2Ye71MeEvPcnSKlG7zfrJL0+iFrt5e/g0Toz9HxoWmNfKx65qcT1SoTzq66zlB3 5HQt19xvQezg3t/RUHONltjXoXL0Fc9wdWCMxcaQg04iOfDzGtbokbjqjq64edkz/Xm/ azaXzeM5FPk6B703lN2DHpQNVULeojJ7Qoz1AtPlD13VSu75zDQgvLgMCa1h0oLGhGlB difkUGGKZMhjS+gNn9y4Yjnt6ImV4ZApElRIR9/7tWpbSlXT/PwjzXOzgplx1ouHRiLu s703s8NOCmFAj7g8bfA/0NWI6s6FgamRT2xgd+EnysjqCf2fmSlDtfV6FkrPxd4neYNb NAtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to; bh=0g7fo90hbNs/3WFujXrrTTOP4wyTJ5nsnUa9fgxwBGM=; b=QYBwRl8qOIE2cnAVei88Yq8q8QgJe6DelBlAPWCW3PNMlcxc6MTAGfMC4vnXgGI5Yy fYcyc0Ds8SU+sYvJe1n2JhBeh+J9dsIED3lMpp8yr2Hx3jfLRswI9O6JmRWQWG1uZM2q Eiv1E4sKk8LtmPX8/wcLIaua6lDi18Xuu6dXCmdCmQ0NHblX8Mmtws6vObnnMoJ28XI6 GdINCeU7Mbh3LkfEW3pPRo6lIOPhld4i8d00i671nXAy1HFMu/0YhOPaAFbTF0YUBaOF K/kH1azPN5G3zLm5ziMMWhu2IYi3IV2TiZ6Ji5R3Gl6x4Z6/kQwMX9cpU+H3wyHckZZr gpIA== X-Gm-Message-State: AKGB3mJD+Jrg9ScYo+jYYYXSrdz9Vq7jtrBFOjwrms2YoQ585mNURODw Dbc0ymu1/YHDdYXuRUkK+WDp8j0Dc8I= X-Google-Smtp-Source: ACJfBoufbZuxz5t3XWc6sDXGKErbM5h6Np5cArFv9NmZCVhSro7BW7WUQcRjD4O1Uo27iLsmIiXznQ== X-Received: by 10.157.40.114 with SMTP id h47mr3207573otd.236.1513202955687; Wed, 13 Dec 2017 14:09:15 -0800 (PST) Received: from [172.20.203.32] (rrcs-97-79-186-3.sw.biz.rr.com. [97.79.186.3]) by smtp.gmail.com with ESMTPSA id 80sm1233700otj.75.2017.12.13.14.09.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 14:09:14 -0800 (PST) Sender: Matthew Miller References: <20171213194801.A5389B80E26@rfc-editor.org> To: "json@ietf.org" From: "Matthew A. Miller" X-Forwarded-Message-Id: <20171213194801.A5389B80E26@rfc-editor.org> Message-ID: <9a021d73-893a-d95a-89b8-970768fe1a1f@outer-planes.net> Date: Wed, 13 Dec 2017 16:09:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171213194801.A5389B80E26@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oUqxp5DpouGkxOtfUGelr5E8UaDmwDKIG" Archived-At: Subject: [Json] Fwd: Corrected Announcement: STD 90, RFC 8259 on The JavaScript Object Notation (JSON) Data Interchange Format X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:09:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oUqxp5DpouGkxOtfUGelr5E8UaDmwDKIG Content-Type: multipart/mixed; boundary="q1rehW1nbFGnD3ebIKksGOdaOqT8pqXte"; protected-headers="v1" From: "Matthew A. Miller" To: "json@ietf.org" Message-ID: <9a021d73-893a-d95a-89b8-970768fe1a1f@outer-planes.net> Subject: Fwd: Corrected Announcement: STD 90, RFC 8259 on The JavaScript Object Notation (JSON) Data Interchange Format References: <20171213194801.A5389B80E26@rfc-editor.org> In-Reply-To: <20171213194801.A5389B80E26@rfc-editor.org> --q1rehW1nbFGnD3ebIKksGOdaOqT8pqXte Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable RFC 8259 (STD 90) is now published. A tremendous thank you to Tim Bray, and this community. - m&m Matthew A. Miller -------- Forwarded Message -------- Subject: Corrected Announcement: STD 90, RFC 8259 on The JavaScript Object Notation (JSON) Data Interchange Format Date: Wed, 13 Dec 2017 11:48:01 -0800 (PST) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, json@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. STD 90 RFC 8259 Title: The JavaScript Object Notation (JSON) Data Interchange Format Author: T. Bray, Ed. Status: Standards Track Stream: IETF Date: December 2017 Mailbox: tbray@textuality.com Pages: 16 Characters: 28360 Obsoletes: RFC 7159 See Also: STD 90 I-D Tag: draft-ietf-jsonbis-rfc7159bis-04.txt URL: https://www.rfc-editor.org/info/rfc8259 DOI: 10.17487/RFC8259 JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document is a product of the Javascript Object Notation Update Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggesti= ons for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC --q1rehW1nbFGnD3ebIKksGOdaOqT8pqXte-- --oUqxp5DpouGkxOtfUGelr5E8UaDmwDKIG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAloxpQkACgkQ7PRyThCe Bbs7tgf+MAt4w7QM/YphfnMPyVdf/KIvmStu41pkX2RHjw2dthNHnw5P3OxqR3AE f6rjd+L9rNnhl0I+h4dVic76MG/0EqecA4hDZBdspbavBxDGjWxFHxMYs5wM9Xxk wRRMN5kVeeCMOBP9bLKIPl1Sdksqsdkrh7XjA+DQsEgZKiZ1k2xnve9tQ7gJyzT6 +uLLWFNjMoHdwi14p78DzWKPeGGMvFgOD5/QvYZz4D+/Bx5IQdXUmR0KXnsHgdNz 4FKjXNOIcn5waoLVzAQtFCM4mwhptqSN3QFp7hZSBzq4zv3zdKGk2O9JS9G61BHH KN4p6IG9yWYhBANqwpJK/8/SbP36rw== =J2gu -----END PGP SIGNATURE----- --oUqxp5DpouGkxOtfUGelr5E8UaDmwDKIG-- From nobody Sat Dec 16 02:35:41 2017 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 391761205F1 for ; Sat, 16 Dec 2017 02:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-gYLOVrvBWp for ; Sat, 16 Dec 2017 02:35:38 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB7D1200FC for ; Sat, 16 Dec 2017 02:35:38 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5BD3DB8123E; Sat, 16 Dec 2017 02:35:10 -0800 (PST) To: tbray@textuality.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, linuxwolf+ietf@outer-planes.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: julian.reschke@gmx.de, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171216103510.5BD3DB8123E@rfc-editor.org> Date: Sat, 16 Dec 2017 02:35:10 -0800 (PST) Archived-At: Subject: [Json] [Editorial Errata Reported] RFC8259 (5210) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 10:35:40 -0000 The following errata report has been submitted for RFC8259, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5210 -------------------------------------- Type: Editorial Reported by: Julian Reschke Section: GLOBAL Original Text ------------- Internet Engineering Task Force (IETF) T. Bray, Ed. Request for Comments: 8259 Textuality Obsoletes: 7159 December 2017 Category: Standards Track ISSN: 2070-1721 Corrected Text -------------- Internet Engineering Task Force (IETF) T. Bray, Ed. Request for Comments: 8259 Textuality STD: 90 December 2017 Obsoletes: 7159 Category: Standards Track ISSN: 2070-1721 Notes ----- Missing "STD" entry in boilerplate. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8259 (draft-ietf-jsonbis-rfc7159bis-04) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : December 2017 Author(s) : T. Bray, Ed. Category : INTERNET STANDARD Source : Javascript Object Notation Update Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Dec 18 09:45:04 2017 Return-Path: X-Original-To: json@ietf.org Delivered-To: json@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE7126CBF; Mon, 18 Dec 2017 09:44:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" Cc: json@ietf.org, linuxwolf+ietf@outer-planes.net X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ietf@ietf.org Message-ID: <151361909904.3437.5608637238913144148.idtracker@ietfa.amsl.com> Date: Mon, 18 Dec 2017 09:44:59 -0800 Archived-At: Subject: [Json] WG Action: Conclusion of Javascript Object Notation Update (JSONBIS) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 17:44:59 -0000 The Javascript Object Notation Update (JSONBIS) WG in the Applications and Real-Time Area has completed its only deliverable and is now being closed. Thank you to the WG chair and editor for their hard work. The IESG contact persons are Ben Campbell, Alexey Melnikov, and Adam Roach. The mailing list will remain open. From nobody Thu Dec 28 10:35:28 2017 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 230F31242F7 for ; Thu, 28 Dec 2017 10:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwYx3hBRS4-m for ; Thu, 28 Dec 2017 10:35:24 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE73012420B for ; Thu, 28 Dec 2017 10:35:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 67E4BB81D5D; Thu, 28 Dec 2017 10:35:15 -0800 (PST) To: tbray@textuality.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, linuxwolf+ietf@outer-planes.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: vfaronov@gmail.com, json@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171228183515.67E4BB81D5D@rfc-editor.org> Date: Thu, 28 Dec 2017 10:35:15 -0800 (PST) Archived-At: Subject: [Json] [Technical Errata Reported] RFC8259 (5218) X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 18:35:26 -0000 The following errata report has been submitted for RFC8259, "The JavaScript Object Notation (JSON) Data Interchange Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5218 -------------------------------------- Type: Technical Reported by: Vasiliy Faronov Section: 12 Original Text ------------- JSON is a subset of JavaScript Corrected Text -------------- JSON is nearly a subset of JavaScript Notes ----- JSON is not a subset of JavaScript: there are syntactically valid JSON texts that are not syntactically valid JavaScript. Namely, JSON strings can contain unescaped U+2028 LINE SEPARATOR or U+2029 PARAGRAPH SEPARATOR characters, while JavaScript string literals cannot. Thus, a sequence of characters U+0022 U+2028 U+0022 matches this RFC's 'string' production, but does not match ECMA-262's 'Expression' production. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8259 (draft-ietf-jsonbis-rfc7159bis-04) -------------------------------------- Title : The JavaScript Object Notation (JSON) Data Interchange Format Publication Date : December 2017 Author(s) : T. Bray, Ed. Category : INTERNET STANDARD Source : Javascript Object Notation Update Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Sat Dec 30 21:24:56 2017 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 D976B12702E for ; Sat, 30 Dec 2017 21:24:54 -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 TX1cD8SbJ2N7 for ; Sat, 30 Dec 2017 21:24:52 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 588901200B9 for ; Sat, 30 Dec 2017 21:24:52 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f206so53420693wmf.5 for ; Sat, 30 Dec 2017 21:24:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=2EFVIekJAGnXop7ZiaJCXBvDZVh94lf2CnQBqHgVWjM=; b=kw8MYClQ/o+/+GlBZVR6tl/F5dqNEmb09Qaq8KP7YX2ubn0BBdUGkT2ukc7sj03hi8 P96vtpVhFzs/vsijuPIqRJESFxltMtW8dlf77y3KCBWX2pw06FJ8tvWfVZSBf3bYPqhh MlFR5rSSQ1aGfUOqv/wPe3jpAiM51jkgaoSEPTRga1bIb6QaFXwqj3Y7jVZoXknwhZKE 6di933DYQ0DsKoTZ3WmQGNoSvw3IhClFzGq6e9Bm23Fpr5aRVUNoPE8zQ2bbgusTZEl3 jCGlV3tKxY0mkwHBosthJH33CxuEay3K/16C0ozUZCsO6fdIvrKay8GKdqHk2Rf3B5b8 F9MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=2EFVIekJAGnXop7ZiaJCXBvDZVh94lf2CnQBqHgVWjM=; b=O8VYhgLg3kZUeFcwGCm30jYlMDt4IYjudJVMR/hewCEsuFWyNyDxVTQs3tAD0du4ub po6FCEkdZkyLi1QJw2wXqr5JuJM1cZqPjH955nzQtRMbZDdWpHQrqU+qKUFZewBzKXjI Wwg8DhlKlvwaehGVyP7fxcgsOqDJwvW7OoIOZisYth+t7NDwMe3hgeAVk7J3trp/iT/P EvBtz2CK18WexeOVv5riUquUBfEnSXkTK1dEpJ8l8mEH7qxhw6wG5KOJ4Kvs4/OQkV6y a85NFBy8pq3BcPI55LPE1ZTodBVNjeCOs3gq77an4wFpKECOxA0edkMyxZP3El/yNeWl Ubmw== X-Gm-Message-State: AKGB3mLNoue3lgCpX2uxK1cVDdkto+qS6sxhgewQOrXzyjAB6KWUGQUX WZ7CA0JIO6f0ZwqTjtFVsmXbDQ== X-Google-Smtp-Source: ACJfBouM8hfQm+3GBF5/JCQWv0+B3u2vh1VjY30mz4GsNajRJRhHdzdVRaQrfI01l7DRFYoSbYKoSQ== X-Received: by 10.28.144.10 with SMTP id s10mr29069726wmd.103.1514697890506; Sat, 30 Dec 2017 21:24:50 -0800 (PST) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 139sm18247967wmp.7.2017.12.30.21.24.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Dec 2017 21:24:48 -0800 (PST) To: "json@ietf.org" From: Anders Rundgren Message-ID: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> Date: Sun, 31 Dec 2017 06:24:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 05:24:55 -0000 Congratulations everybody to the revised JSON RFC! Does this mean that JSON is "done" for good? Probably not because the concept I have mentioned from time to time, the ability adding a digital signature to a JSON object (in contrast to signing arbitrary Base64Url-encoded data), is still very much alive.  In fact, there is an I-D in preparation aiming at reducing the current proliferation of "DIY-standards" for dealing with this highly requested feature.  The only real challenge is agreeing on a suitable way "normalizing" JSON data during parsing and serialization.  Such a scheme will be like an extended version of I-JSON (RFC7493), potentially having an impact on "ordinary" uses of JSON as well. Happy New [and optionally signed] JSON Year Anders Rundgren From nobody Sun Dec 31 10:43:17 2017 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 49303126B6E for ; Sun, 31 Dec 2017 10:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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 zLP3ml53cr46 for ; Sun, 31 Dec 2017 10:43:14 -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 2197A1200C1 for ; Sun, 31 Dec 2017 10:43:14 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id b141so8870758wme.1 for ; Sun, 31 Dec 2017 10:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UNtCujC66SFkPw9KSn6kf+wk+qDItLBKWo0t0P1Ex5c=; b=qluhseBjDHdKtuvUybEHsomHnVLgz2Jv9LtjDOO/oFpe0T/zP+gfxO30w0mAdnYLbQ M6oFQJJ5eeW0zkyXTSzl1rMHJVOFxP8xPUK5BZ17IhpBtzqGm3JTK9n+LMdOZcRjSqRq mCaYhLytNtTMV7TFBrd2/vUOq68NG5ZKhCU9KIjwazqJ2wLmb5aAQxSOFhS/3jFK6l+4 erhLXvNlRCsAhFBWffimdQLYwN4/XTZqFqJIGd9g4s3a//hB8RNVJU+fMnhnNKTetL4f SdAq2PME2DqCXJeobKQADoiaGEAST5D4nsRerjyi3VB3qSWSoQBvMFUeaExKnNXB3u/e A2pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UNtCujC66SFkPw9KSn6kf+wk+qDItLBKWo0t0P1Ex5c=; b=M5tGYYkfMn4ruxAFET36sDXTrtdhbI/gmAeTWrSsfjTwRYG/1sdXTqa5U3u42VfeyX EpaQv3C/KJ/BvQ7dlkFUu4WhSc9Ud3leh5bUjpDk9LyctMbyOVFt8T6lmcut4Pcet4/l qrxRLUxwJ536BCj6dXUmEwEdSuep6Rrj1Uqzk1IWZq5IeZO5o5YpomL25DRl5p7u3sqf sbIBODA5xDXeb9Nk2iBEKILonRdkt41ASZcUmP/hoXk8cA61J+b2TEwSynT9K4GZq6qw FeEeWgI7ndXsksUxNvYESjIuOIMf+x0oLTW/c93QAZAB2vkS0HImsm0UXG7663Q4mz1K rJ8Q== X-Gm-Message-State: AKGB3mJHqUHn20cDvsiCH1KyEUs0HAw1RWC4VYEJGMb6gXo7+71WqSF2 MJ06D+hbYL/lIxpzvyyZ3wNZmKJFU/2OQwEkb78= X-Google-Smtp-Source: ACJfBotkQSkHSUfD4YOGvHsE4eIyLFqVG20Iu9vYENsVYgwDaCFMaOLPBW5Nd8NFDOzl1fJUfzhs074zp49ITE5qBx0= X-Received: by 10.28.160.23 with SMTP id j23mr30503100wme.54.1514745792614; Sun, 31 Dec 2017 10:43:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.189 with HTTP; Sun, 31 Dec 2017 10:43:11 -0800 (PST) In-Reply-To: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> From: Richard Gibson Date: Sun, 31 Dec 2017 13:43:11 -0500 Message-ID: To: Anders Rundgren Cc: "json@ietf.org" Content-Type: multipart/alternative; boundary="089e082f8364e4d7c10561a73ceb" Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 18:43:16 -0000 --089e082f8364e4d7c10561a73ceb Content-Type: text/plain; charset="UTF-8" On the topic of JSON normalization, I believe that canonicaljson-spec covers all cases while respecting prior art like https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 and RFC 7638. I'd like to get it published as an RFC to handle scenarios like those mentioned by Anders Rundgren, but am not sure how to go about doing so. Is this a good place to ask for assistance? On Sun, Dec 31, 2017 at 12:24 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > Congratulations everybody to the revised JSON RFC! > > Does this mean that JSON is "done" for good? > > Probably not because the concept I have mentioned from time to time, the > ability adding a digital signature to a JSON object (in contrast to signing > arbitrary Base64Url-encoded data), is still very much alive. In fact, > there is an I-D in preparation aiming at reducing the current proliferation > of "DIY-standards" for dealing with this highly requested feature. The > only real challenge is agreeing on a suitable way "normalizing" JSON data > during parsing and serialization. Such a scheme will be like an extended > version of I-JSON (RFC7493), potentially having an impact on "ordinary" > uses of JSON as well. > > Happy New [and optionally signed] JSON Year > Anders Rundgren > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > --089e082f8364e4d7c10561a73ceb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the topic of JSON normalization, I believe that=C2= =A0canonicaljson= -spec=C2=A0covers all cases while respecting prior art like https:= //tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 and RFC 7= 638. I'd like to get it published as an RFC to handle scenarios like th= ose mentioned by Anders Rundgren, but am not sure how to go about doing so.= Is this a good place to ask for assistance?

On Sun, Dec 31, 2017 at 12:24 AM, An= ders Rundgren <anders.rundgren.net@gmail.com> wr= ote:
Congratulations everybody to the rev= ised JSON RFC!

Does this mean that JSON is "done" for good?

Probably not because the concept I have mentioned from time to time, the ab= ility adding a digital signature to a JSON object (in contrast to signing a= rbitrary Base64Url-encoded data), is still very much alive.=C2=A0 In fact, = there is an I-D in preparation aiming at reducing the current proliferation= of "DIY-standards" for dealing with this highly requested featur= e.=C2=A0 The only real challenge is agreeing on a suitable way "normal= izing" JSON data during parsing and serialization.=C2=A0 Such a scheme= will be like an extended version of I-JSON (RFC7493), potentially having a= n impact on "ordinary" uses of JSON as well.

Happy New [and optionally signed] JSON Year
Anders Rundgren

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

--089e082f8364e4d7c10561a73ceb-- From nobody Sun Dec 31 10:50:38 2017 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 75ED3127342 for ; Sun, 31 Dec 2017 10:50:37 -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 N2S1PKDt1Jq5 for ; Sun, 31 Dec 2017 10:50:35 -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 E34E8127058 for ; Sun, 31 Dec 2017 10:50:34 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id y82so11454098wmg.1 for ; Sun, 31 Dec 2017 10:50:34 -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=Q4Mxc2WttyonWXgmPQAmRSECIl8PV/qP95YPwnnr5IQ=; b=LUU8YX9WMSFAHzPj2Rj3k0eJ1CO5C/ktUZBN+uO1XEeHMhD0uYycQcPEbO5tye30V0 ZiybW17mmBUlcmjMUCJ34ON31tqu0RZkVPpEqGIb9dg0/uoTquTMlEtlmZJMnmm98NvD 4eDUg7phWLfpgDkuc5n5DtG9J5F/XaLDbg5cr75RnUR+5VzL4KmRT0p6mI4NeNmpcz8F eWIv+Vq8pGrBoA47mdDIvZO7d4oZB+8ZsS9zCODgCr2QSY/zHoG09oebqTRpsrXk8mHe wP726fP5IG8JrUXEIV3pAcNp/oaREHHz+6fe5yKi/XwB9acX/83axE4+E7C1xcgFlZSv ldPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q4Mxc2WttyonWXgmPQAmRSECIl8PV/qP95YPwnnr5IQ=; b=amsdhaFY+9an41F66LLNIbtZWzMpaPIxErmLAoWc3WBvXCe3Zu1OaB+GDGx3mUoC7a 92cw6xbSMyQ4q804jgNBcSEzX19jUUO0y9KeoHJdXJLMViZiFfjhJKXZWwi1O+MiGfuC ccPzTj4ZA/LBFGHS/vcxDhYgtLzBj0U274TbtYSOcRTGxMr8QMcrAm/xG2MYkueBO0Vy ahka1mQrBKba/FG4/HsBPY2bUroyI50g6q5NteSu02ElkTMn1d+CIqaghjt3nCo5yowO JIDWlBNxRV7R0Nj+SwZvbmN4Mo9ekbz0fahRXvytVB10JL60gr1Fw/AO4QkJkDQV7Z7W gmyQ== X-Gm-Message-State: AKGB3mJPvjexc1q0NZ0vKGapxI4TPX4DuZDT8BsN6djGueixh0xCemRi aZpxA/l4EPpf4Va6N9b4lgxeY2i1/kKy/+5eZoDqyg== X-Google-Smtp-Source: ACJfBovmIVRBm9wtgWBwNkPb5t2HnJ/RnavGdRwDf5j+boQ0nGuFCSW0EhlUhjWHpFwQpUEObA2IqCjpuERcvwcPC5s= X-Received: by 10.80.174.2 with SMTP id c2mr53164038edd.93.1514746232799; Sun, 31 Dec 2017 10:50:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.192.129 with HTTP; Sun, 31 Dec 2017 10:50:12 -0800 (PST) X-Originating-IP: [174.6.224.108] In-Reply-To: References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> From: Tim Bray Date: Sun, 31 Dec 2017 10:50:12 -0800 Message-ID: To: Richard Gibson Cc: Anders Rundgren , "json@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c196ade2199eb0561a75732" Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 18:50:37 -0000 --94eb2c196ade2199eb0561a75732 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I were going to make an argument for keeping the WG alive, it would require someone to get energized and submit an I-D for a plausible JSON schema system, or maybe even a much-needed formalization of JSONPath. We use JSONPath a lot at AWS. On Sun, Dec 31, 2017 at 10:43 AM, Richard Gibson wrote: > On the topic of JSON normalization, I believe that canonicaljson-spec > covers all cases while > respecting prior art like https://tools.ietf.org/html/ > draft-staykov-hu-json-canonical-form-00 and RFC 7638. I'd like to get it > published as an RFC to handle scenarios like those mentioned by Anders > Rundgren, but am not sure how to go about doing so. Is this a good place = to > ask for assistance? > > On Sun, Dec 31, 2017 at 12:24 AM, Anders Rundgren < > anders.rundgren.net@gmail.com> wrote: > >> Congratulations everybody to the revised JSON RFC! >> >> Does this mean that JSON is "done" for good? >> >> Probably not because the concept I have mentioned from time to time, the >> ability adding a digital signature to a JSON object (in contrast to sign= ing >> arbitrary Base64Url-encoded data), is still very much alive. In fact, >> there is an I-D in preparation aiming at reducing the current proliferat= ion >> of "DIY-standards" for dealing with this highly requested feature. The >> only real challenge is agreeing on a suitable way "normalizing" JSON dat= a >> during parsing and serialization. Such a scheme will be like an extende= d >> version of I-JSON (RFC7493), potentially having an impact on "ordinary" >> uses of JSON as well. >> >> Happy New [and optionally signed] JSON Year >> Anders Rundgren >> >> _______________________________________________ >> 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 > > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --94eb2c196ade2199eb0561a75732 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If = I were going to make an argument for keeping the WG alive, it would require= someone to get energized and submit an I-D for a plausible JSON schema sys= tem, or maybe even a much-needed formalization of JSONPath. We use JSONPath= a lot at AWS.

On Sun, Dec 31, 2017 at 10:43 AM, Richard Gibson <richard.= gibson@gmail.com> wrote:
On the topic of JSON normalization, I believe that=C2= =A0canonicaljson-spec=C2=A0covers all cases while respecting prior ar= t like https://tools.ietf.org/html/draft-stayko= v-hu-json-canonical-form-00 and RFC 7638. I'd like to get it p= ublished as an RFC to handle scenarios like those mentioned by Anders Rundg= ren, but am not sure how to go about doing so. Is this a good place to ask = for assistance?

On Sun, Dec 31, 2017 at 1= 2:24 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
Congratulations ever= ybody to the revised JSON RFC!

Does this mean that JSON is "done" for good?

Probably not because the concept I have mentioned from time to time, the ab= ility adding a digital signature to a JSON object (in contrast to signing a= rbitrary Base64Url-encoded data), is still very much alive.=C2=A0 In fact, = there is an I-D in preparation aiming at reducing the current proliferation= of "DIY-standards" for dealing with this highly requested featur= e.=C2=A0 The only real challenge is agreeing on a suitable way "normal= izing" JSON data during parsing and serialization.=C2=A0 Such a scheme= will be like an extended version of I-JSON (RFC7493), potentially having a= n impact on "ordinary" uses of JSON as well.

Happy New [and optionally signed] JSON Year
Anders Rundgren

_______________________________________________
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




--
=
- Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/t= imbray)
--94eb2c196ade2199eb0561a75732-- From nobody Sun Dec 31 11:28:07 2017 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 167F9124BFA for ; Sun, 31 Dec 2017 11:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=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 bcsFH2z39T0u for ; Sun, 31 Dec 2017 11:28:02 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003: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 5744E1200C5 for ; Sun, 31 Dec 2017 11:28:02 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id o64so31356761oia.9 for ; Sun, 31 Dec 2017 11:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0nnf0T0s97KQ1IX8VHXiwKfdAnivzIEekK0xWQCUT4s=; b=IqH+k/jV+smf4zMZ96AfsA+050Twvcp7FOc36xd8iDYLtV+sRyIZbP7/uffCsnkMDR 2BrBkP91d3wzKkFg2Ru4BAWl3OZ90LlfbQbRy6ZKaNv3ayEesHNvfKSbabBoY1ZaGs8B z0+cX0RrbNGfzGIjRylnyX7ZsG3ObZP11vOvuxeBn3rqflwM9FiwO4XzGfKa9BVroIVK XaC75uzKjprczfIdNxLUyfap51/2eV4xU1PDximp24YIEDtnIDW36n31wOm7+MyEDUir 7JV/6J+p2kPeK31pXrc7hDZsrOJPJBVGkaAfIu/2SeFOKUWfLqlvqqYAvAI20aTg7nRO rSSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0nnf0T0s97KQ1IX8VHXiwKfdAnivzIEekK0xWQCUT4s=; b=hxgcuggpuY8vhwYl4tNiHgGB6+Sk1V429B3sr8K9o8RkAyOcXoM9Ujmt+/XzGvEnNk obyclGDpBaDVhZI9LpxVzRd7061tVe7LR9qVUzb3npuxsJWBSD1WJNzRwHhNfORUH5vk E8U5V+DEqsgLm4qdauX4EH2fako5tNlMu2dpL4TvdhTBCAhI8BpqVUZ4Og6ENWFo4m+k oWWtgeRhp3O6NNzTSIbkE8pv94KakL0zeKNM+qhB9u5rcCgIhYncXfEjNjyT1S3tN+3k D0byKjIUSJ9KsvPNdLiy+LjN3mnyg4HWdC/T0+GaVqU/MMYEtldgyedGxBekxbRf8cmR INBw== X-Gm-Message-State: AKGB3mIoDAo3JNYHztRvaMKyug2iC93q1unK6lNRovRROwsQEWsZ/LKp lW8I0quQDPilpbMS6u+fCz0S57g3UhjD5lAtgqM= X-Google-Smtp-Source: ACJfBovifl4YUwSV+Z3har0xk9fABPKrimzlxfZbNO1ySXQw7Q7Ji5kgW6UGkdaedjxaxvu6t1YBLgHzUMwAd5n1bqQ= X-Received: by 10.202.245.216 with SMTP id t207mr26710807oih.265.1514748481501; Sun, 31 Dec 2017 11:28:01 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.49.87 with HTTP; Sun, 31 Dec 2017 11:28:00 -0800 (PST) In-Reply-To: References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> From: Phillip Hallam-Baker Date: Sun, 31 Dec 2017 14:28:00 -0500 X-Google-Sender-Auth: 1iRB9MQ2ejt8hvH70SV1hvTES7g Message-ID: To: Tim Bray Cc: Richard Gibson , "json@ietf.org" , Anders Rundgren Content-Type: multipart/alternative; boundary="001a113df24829feb90561a7dd60" Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 19:28:05 -0000 --001a113df24829feb90561a7dd60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 As a practical matter, the group would need to recharter and what is proposed is a completely different application and one that many folk, myself included are skeptical of having been burned on it with XML Signature. While it is possible that XML Signature canonicalization is covfefe because of the convoluted XML semantics, ASN.1 has reasonably precise semantics but I have yet to find an actual use case for DER. Seriously, VeriSign signed every certificate using BER for years until someone noticed. The idea that you can take a signed object, parse it and then re-emit it from the parsed object is not inherently flawed but I have yet to hear a good reason to do this. It is one of those terrible ideas that people keep insisting is 'essential' and cannot give a non referential reason for doing= . We did not do canonicalization in JOSE and not for lack of people suggesting it. On Sun, Dec 31, 2017 at 1:50 PM, Tim Bray wrote: > If I were going to make an argument for keeping the WG alive, it would > require someone to get energized and submit an I-D for a plausible JSON > schema system, or maybe even a much-needed formalization of JSONPath. We > use JSONPath a lot at AWS. > > On Sun, Dec 31, 2017 at 10:43 AM, Richard Gibson > wrote: > >> On the topic of JSON normalization, I believe that canonicaljson-spec >> covers all cases while >> respecting prior art like https://tools.ietf.org/html/dr >> aft-staykov-hu-json-canonical-form-00 and RFC 7638. I'd like to get it >> published as an RFC to handle scenarios like those mentioned by Anders >> Rundgren, but am not sure how to go about doing so. Is this a good place= to >> ask for assistance? >> >> On Sun, Dec 31, 2017 at 12:24 AM, Anders Rundgren < >> anders.rundgren.net@gmail.com> wrote: >> >>> Congratulations everybody to the revised JSON RFC! >>> >>> Does this mean that JSON is "done" for good? >>> >>> Probably not because the concept I have mentioned from time to time, th= e >>> ability adding a digital signature to a JSON object (in contrast to sig= ning >>> arbitrary Base64Url-encoded data), is still very much alive. In fact, >>> there is an I-D in preparation aiming at reducing the current prolifera= tion >>> of "DIY-standards" for dealing with this highly requested feature. The >>> only real challenge is agreeing on a suitable way "normalizing" JSON da= ta >>> during parsing and serialization. Such a scheme will be like an extend= ed >>> version of I-JSON (RFC7493), potentially having an impact on "ordinary" >>> uses of JSON as well. >>> >>> Happy New [and optionally signed] JSON Year >>> Anders Rundgren >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a113df24829feb90561a7dd60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1= =C2=A0

As a practical mat= ter, the group would need to recharter and what is proposed is a completely= different application and one that many folk, myself included are skeptica= l of having been burned on it with XML Signature.

While it is possible that XML Signature canonicali= zation is covfefe because of the convoluted XML semantics, ASN.1 has reason= ably precise semantics but I have yet to find an actual use case for DER. S= eriously, VeriSign signed every certificate using BER for years until someo= ne noticed.
The idea that= you can take a signed object, parse it and then re-emit it from the parsed= object is not inherently flawed but I have yet to hear a good reason to do= this. It is one of those terrible ideas that people keep insisting is '= ;essential' and cannot give a non referential reason for doing.

We did not do canonicalization= in JOSE and not for lack of people suggesting it.



On Sun, Dec 31, 2017 at 1:50 PM, Tim Bray <tbr= ay@textuality.com> wrote:
<= div dir=3D"ltr">
If I= were going to make an argument for keeping the WG alive, it would require = someone to get energized and submit an I-D for a plausible JSON schema syst= em, or maybe even a much-needed formalization of JSONPath. We use JSONPath = a lot at AWS.
=
On Sun, Dec 31, 2017 at 10:43 AM, Richard Gi= bson <richard.gibson@gmail.com> wrote:
On the topic of JSON normalizatio= n, I believe that=C2=A0canonicaljson-spec=C2=A0covers all cases while= respecting prior art like https://tools.ietf.org/ht= ml/draft-staykov-hu-json-canonical-form-00 and RFC 7638. I= 9;d like to get it published as an RFC to handle scenarios like those menti= oned by Anders Rundgren, but am not sure how to go about doing so. Is this = a good place to ask for assistance?

On Sun, Dec 31, 2017 at 12:24 AM, An= ders Rundgren <anders.rundgren.net@gmail.com> wrote:
Congratulations everybody to th= e revised JSON RFC!

Does this mean that JSON is "done" for good?

Probably not because the concept I have mentioned from time to time, the ab= ility adding a digital signature to a JSON object (in contrast to signing a= rbitrary Base64Url-encoded data), is still very much alive.=C2=A0 In fact, = there is an I-D in preparation aiming at reducing the current proliferation= of "DIY-standards" for dealing with this highly requested featur= e.=C2=A0 The only real challenge is agreeing on a suitable way "normal= izing" JSON data during parsing and serialization.=C2=A0 Such a scheme= will be like an extended version of I-JSON (RFC7493), potentially having a= n impact on "ordinary" uses of JSON as well.

Happy New [and optionally signed] JSON Year
Anders Rundgren

_______________________________________________
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




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

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


--001a113df24829feb90561a7dd60-- From nobody Sun Dec 31 11:41:03 2017 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 1B7F5120725 for ; Sun, 31 Dec 2017 11:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.net 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 zJWgcfq3M9cS for ; Sun, 31 Dec 2017 11:41:00 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 77FC51200C5 for ; Sun, 31 Dec 2017 11:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=56JaxMKFw9fI/Uhjj2T0T8Z5Tp0Mk9Fj6lj3j12NG/U=; b=Pidibv80ZY4oMt2rW0c/IRhWDG U21ERRZpiDIHfOmPYY4LFwN3Diwx63EZAskVqB0RPeoMbZ9jHA0G2k18Gfr5Wx0kgyLWejCgpUmXs uWgemWT33USsSPBRTVwLCy1NZxWsE1Bo4Pt5fbIEacsKlAJWpflkQwHL6fM98OuAdJcf9HI1m5eht qcQRNyWEhzY8GRtJjwryPbsUGEhXRygRiEq01WljsvQSKI1lKQ1bld3ul+O5jyQH5ysRStI35MhJo GuIU+U60/rLOpJDlt9NT73b0fYLCZdauj5ESVjG7oLJ6iife/m6Vyqlw06ZvFyZeihkGIitZIoT61 plH6Q0Mg==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:56221 helo=[192.168.1.78]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eVjTe-0001ZD-Hi; Sun, 31 Dec 2017 14:40:58 -0500 To: Tim Bray , Richard Gibson Cc: "json@ietf.org" , Anders Rundgren References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> From: Erik Wilde Message-ID: <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> Date: Sun, 31 Dec 2017 11:40:56 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 19:41:02 -0000 hello. On 2017-12-31 10:50, Tim Bray wrote: > If I were going to make an argument for keeping the WG alive, it would > require someone to get energized and submit an I-D for a plausible JSON > schema system, or maybe even a much-needed formalization of JSONPath. We > use JSONPath a lot at AWS. for the schema aspect: https://github.com/json-schema-org/json-schema-spec/issues/526 makes the relatively small team behind JSON schema (which started out as a continuation of the long-abandoned effort by kris zyp ) aware of this possibility. i am not involved enough to decide whether they are interested in making this step, but at least it's an effort that has been pretty active, and it might be an interesting candidate for a JSON schema language. for the JSON path aspect: +1 as well, but i am not aware of something as active as the schema language effort above that could be pulled in. for kicks and giggles, i'd also like to throw in that it would be great to have some reusable way of how various vocabularies can exist alongside in JSON. one could mutter the words "XML namespaces" here, but most people have negative views of them. but still: in APIs, there often is the need to support extensibility and openness, and it seems like every JSON-based API design has to come up with its own way of doing it. cheers (and happy new year to everybody!), dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sun Dec 31 13:34:35 2017 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 788DB126BF6 for ; Sun, 31 Dec 2017 13:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Earuuv8UH9Yw for ; Sun, 31 Dec 2017 13:34:32 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 2B7BB1242F5 for ; Sun, 31 Dec 2017 13:34:32 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id c204so24117821pfc.13 for ; Sun, 31 Dec 2017 13:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Yhg3O+pgB//JdPf+HZqeGaFg9cN0I7Ezhyd+0kwQQ0c=; b=shq0/xxdgKnKBgGNMKTgwNw9qwkzp6vIsYqgXi92GiytOuz8mCeOdDsOqjogEZvaie aCxLcR5DAEtrzsjgXJSJjKGJrlOQLRWLd4rXyEAUJntqb8ZUidO0WDc9fY0hyHYFxPfm F1S3dfOwlWeur7xPe2KNhUn7iDS69J7BVurMQoz3StbEvN81jtNaEbf1wNWpplgbJ1Zu j3uo378nnwqFiPfHlVQXbNYc7+M80s5a0xnoyVI7sksf0yDCK9fp2GkK+P06uXsiKIyY ZHIQOoqVs+Kisl4wdx+C7pP3QMnRudyijjUTA7ljLoN9hq+cClDw/Iasa/Ov1p7JGqYS dpWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Yhg3O+pgB//JdPf+HZqeGaFg9cN0I7Ezhyd+0kwQQ0c=; b=QIdhAa1Dp6rO71d5E+a8/1eZrWg3Q1SgI09ZR0uuaasR29sXaqpTGfT0fzwu2miH1q yJD26THyrNXogLf6PskO+LBsADW9lu8SBKu0baA0wCpqE/3o0rVASKUK02NX/y3siWOx wdtvjeHclfNWhjV+kZougQ5rUTpqdZmKHBJmfNldOtPK9UeTxi35FUGK+Q3scWO8rNTI SUDVmQz/JmeILuAivS+HYSnkiufeJQl47wjtgpyiJiL6jpbdOuAon5DaschWr+6HqFLq m6SGhz7/vbzKiIGvbzZofalXJl/41uuM/pVSYmq4CMMnWf5GZ1Nd6hkWRH1ZO+p6nHJE GRig== X-Gm-Message-State: AKGB3mKZCd8O1FEBK2ulrFQC75wd6fpCoPgZsIaJxsuGhCbiGGTt8naV VvBo+w40WX2n18fsKlV0gurkOjAKDVs6O6CX9tk= X-Google-Smtp-Source: ACJfBot/jRIJhWi7QdbRQQvq51KdpkGQs82rg3MsRPSjZDah76Iu418hNciY+Q1LBfW6i9ku4awYU3hbB6LNY0zvQpg= X-Received: by 10.99.56.67 with SMTP id h3mr13166549pgn.311.1514756071314; Sun, 31 Dec 2017 13:34:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.169.73 with HTTP; Sun, 31 Dec 2017 13:34:30 -0800 (PST) Received: by 10.100.169.73 with HTTP; Sun, 31 Dec 2017 13:34:30 -0800 (PST) In-Reply-To: <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> From: Anders Rundgren Date: Sun, 31 Dec 2017 22:34:30 +0100 Message-ID: To: JSON WG Content-Type: multipart/alternative; boundary="f403045d206a8d5b8b0561a9a1d7" Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 21:34:34 -0000 --f403045d206a8d5b8b0561a9a1d7 Content-Type: text/plain; charset="UTF-8" For normalization it turns out that JSON.parse() and JSON.stringify() as specified by ECMA and already supported by the most widely available JSON tools is all you need! Anders on mobile --f403045d206a8d5b8b0561a9a1d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For normalization it turn= s out that JSON.parse() and JSON.stringify() as specified by ECMA and alrea= dy supported by the most widely available JSON tools is all you need!
=

Anders on mobile
--f403045d206a8d5b8b0561a9a1d7-- From nobody Sun Dec 31 15:39:10 2017 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 2C01A126C89 for ; Sun, 31 Dec 2017 15:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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 NrQR0Z3-Bkru for ; Sun, 31 Dec 2017 15:39:06 -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 AE81E124217 for ; Sun, 31 Dec 2017 15:39:06 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id i11so55624065wmf.4 for ; Sun, 31 Dec 2017 15:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gqBUlM3K29gY9joCenL2anpfcHk8xgbggAhZbn0qfYQ=; b=cBl/0hBb/u9fY3ZRbU1pMk+QsN6VC/2Mf4hWKOda2hsgep01T/Os5n1oa7z38VxwcG j+y17itfh8usgzrTV5I1D5cnWvgWjiwYvPtn26PGM81JXz/q52thBIJLV4J0QC5OmI0+ zdQygCfU378cq5MvA9gdEuGMxVjySSWBNEOy8OKQeJevOJKE4GkDo4j/9ZxNLWVqiJ9W yVqtDetSA+Es0gRKargyGv9tj44L/gC/yj44OpkNQL10tU1eH0BtiZpJtjgc79MXMP9F Ul7adZ2RZC4WDrYi+ASvVmF0L5jGxcdKJWWKtKksly9+H+FCOxjSb2uVdbULZ5sbF0ol YcsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gqBUlM3K29gY9joCenL2anpfcHk8xgbggAhZbn0qfYQ=; b=dP3EGVB8KCVjMUwuqW0XVS4Btin/bkC9jndH0JexMXUAdVzgRGD2zwLHwxkBteKvLU Dr5mpgX/WIGdT1v6HwtJl5SZsvf9Cus5gnIew6UsTljLHXLFzsVn07UVa7wEVVPszk63 aiQkEt/pvE+XlRFqsX9Lhk3aHLTcnN1LF6ETq4LUcZkyM3aTfcPce1u4z31fTj+3qhkn +5On4JlcmSm0ycyoh/g7DybA3ykahuiUwyHL4v5UN7h0ij2rg06HuSd7QJlKW6rU6tjW bsqiRiUdZWqPwa/ZiRVZ9ZkUxsO8VDTMcXMEC2z0zE9bP6ULVIxTpmO/uzCbx6ZA9gK1 PFVg== X-Gm-Message-State: AKGB3mLC6Hy3hrHQLmS0TrXrby5yVM5PlslPYyhtTIVUcOS4vT6THM+Y PqFtpVUQdwnqkPP/KElNjxeGi4jNXlEXHlgGWz4= X-Google-Smtp-Source: ACJfBovnZ6nSN47u7YtZfGFdHg36UurS83V5C1KmvTVr+rOvPepxmfEeJ0F5jUvk90+UAQFDFQQJWEWsm4Nd+z2Ca5M= X-Received: by 10.28.134.133 with SMTP id i127mr34514134wmd.79.1514763545074; Sun, 31 Dec 2017 15:39:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.189 with HTTP; Sun, 31 Dec 2017 15:39:04 -0800 (PST) In-Reply-To: References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> From: Richard Gibson Date: Sun, 31 Dec 2017 18:39:04 -0500 Message-ID: To: Anders Rundgren Cc: JSON WG Content-Type: multipart/alternative; boundary="001a11441c0205e1290561ab5f72" Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2017 23:39:09 -0000 --001a11441c0205e1290561ab5f72 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 31, 2017 at 4:34 PM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > For normalization it turns out that JSON.parse() and JSON.stringify() as > specified by ECMA and already supported by the most widely available JSON > tools is all you need! > That is definitely not true. A trivial counterexample: https://jsbin.com/luyoveyuqu/edit?js,console,output --001a11441c0205e1290561ab5f72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Dec 31, 2017 at 4:34 PM, Anders Rundgren <anders.rundgren= .net@gmail.com> wrote:
For normal= ization it turns out that JSON.parse() and JSON.stringify() as specified by= ECMA and already supported by the most widely available JSON tools is all = you need!

That is definit= ely not true. A trivial counterexample:=C2=A0https://jsbin.com/luyoveyuqu/edit?js,cons= ole,output=C2=A0
--001a11441c0205e1290561ab5f72-- From nobody Sun Dec 31 16:49:17 2017 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 399F1126DFB for ; Sun, 31 Dec 2017 16:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P89pfVo4aVix for ; Sun, 31 Dec 2017 16:49:14 -0800 (PST) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (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 92875124217 for ; Sun, 31 Dec 2017 16:49:14 -0800 (PST) Received: by mail-ot0-x241.google.com with SMTP id 37so13446870otv.6 for ; Sun, 31 Dec 2017 16:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nnOhP/U8S1sIzAWUqKymGoRKGAFbLrXcwdsREKYK+YY=; b=RwxtaAbziZ+fJLAHYd9Pn2kuQGtDCjxQHCixfVay7doriY2hYbkMsw0H7DVxxgvQEA dgeMMkyzFVAC0eTsDN82rOF4FTY/EQ01iEWKgwfRN7q4MfQ7bmc93bbgWvOTGKaNMisx TR2RaxJ7ZVkjud2yG91mWmb/tgsoykAgUWOf7TUeSBZ1uFXPfwKmtgg0dZnucVBkgBeN kIE7jExp43yZuMRWJIWzAQeDXQkJMcrNElEdDI+KH4xP0N+5q0kDUwqFIWhgUAjvVMZH VjvIprXyhZIOW/7eRnnLnDi2f6oyKlglgbT+ZcyYSyEWYuaUPpk8KqZzh1cFT59FVrfW fpRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nnOhP/U8S1sIzAWUqKymGoRKGAFbLrXcwdsREKYK+YY=; b=saGlAVU0yL6+RyVdnycZPh6Sdm2Xtz1fwnhDDYILlHlIClvIREA55vXRnolHo0XTt1 MVFcH/YB7j9exHaQCRmC6y3thiNnri9SKqybfJeLuKRHNqiKw7H/JXrPBDkScmRB7t+Q EXXSE+zxdPcg83lIPJSLzzSjEJlSAc4fkfqN695y4De+PfKWOlXHD1H9FxjhfzmzQijd oSYTWmG8ktL7qMbth/SFYSfOpACCfpqWK18Kb/jVJE5+ccZJJmnlY7RxH1+N+9kc+Llf QQ7RUo71NPWqB+Ue1cB2SoKI0vcBSes9LjNhMRJMcak5TG9vqyk8joQ7/VCT3kxDh9yn 7vtw== X-Gm-Message-State: AKGB3mISK6L9xef+krlE/4q4He/macD9F/CzgfZiB3fVi7KvSydBkRXq cNUkGd3rEQcBy5qplO4ePTLED7rOn+nguMYTex4= X-Google-Smtp-Source: ACJfBosOJEgNPWG+7Ll4dcAE7cAMueWBOCEd7BFXTBs/7QlfmQbQzJB6wu1p9RFEK6xxgu+IESocMInHrKIU2xMuHqc= X-Received: by 10.157.63.69 with SMTP id m63mr17175109otc.52.1514767753833; Sun, 31 Dec 2017 16:49:13 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.49.87 with HTTP; Sun, 31 Dec 2017 16:49:13 -0800 (PST) In-Reply-To: References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> From: Phillip Hallam-Baker Date: Sun, 31 Dec 2017 19:49:13 -0500 X-Google-Sender-Auth: eWmRdA16cFpUvEduVBe0bmsOMf4 Message-ID: To: Tim Bray Cc: Richard Gibson , "json@ietf.org" , Anders Rundgren Content-Type: multipart/alternative; boundary="001a11473304e2708f0561ac59f5" Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 00:49:17 -0000 --001a11473304e2708f0561ac59f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have a schema language that I use to generate Web Service clients and services. The implementation is open source. It also generates reference sections for an Internet Draft: http://www.prismproof.org/Documents/draft-hallambaker-mesh-reference.html Right now I have three separate schema languages that were written at different times to target XML, JSON, ASN.1 and TLS style encodings. 90% of them are the same. What I think really commends JSON is the lack of extraneous information in the schema. Let us say we are serializing an integer. In the TLS schema I have to specify whether it is an 8, 16, or 32 bit, signed or unsigned, etc. In JSON its just an integer. I just want to think about my application, I want the serialization to be as straightforward as possible. What I don't need or want is the type of capabilities XML Schema gives me, the ability to specify that an integer is greater then 4 and less than 23. That is not information I have ever found the need to express in a schema and I have been using this approach to generate protocols for 25 years. What I have now is adequate for my needs right now. If there is interest in a standard, I would probably want to clean up the approach and make it more regularized. On Sun, Dec 31, 2017 at 1:50 PM, Tim Bray wrote: > If I were going to make an argument for keeping the WG alive, it would > require someone to get energized and submit an I-D for a plausible JSON > schema system, or maybe even a much-needed formalization of JSONPath. We > use JSONPath a lot at AWS. > > On Sun, Dec 31, 2017 at 10:43 AM, Richard Gibson > wrote: > >> On the topic of JSON normalization, I believe that canonicaljson-spec >> covers all cases while >> respecting prior art like https://tools.ietf.org/html/dr >> aft-staykov-hu-json-canonical-form-00 and RFC 7638. I'd like to get it >> published as an RFC to handle scenarios like those mentioned by Anders >> Rundgren, but am not sure how to go about doing so. Is this a good place= to >> ask for assistance? >> >> On Sun, Dec 31, 2017 at 12:24 AM, Anders Rundgren < >> anders.rundgren.net@gmail.com> wrote: >> >>> Congratulations everybody to the revised JSON RFC! >>> >>> Does this mean that JSON is "done" for good? >>> >>> Probably not because the concept I have mentioned from time to time, th= e >>> ability adding a digital signature to a JSON object (in contrast to sig= ning >>> arbitrary Base64Url-encoded data), is still very much alive. In fact, >>> there is an I-D in preparation aiming at reducing the current prolifera= tion >>> of "DIY-standards" for dealing with this highly requested feature. The >>> only real challenge is agreeing on a suitable way "normalizing" JSON da= ta >>> during parsing and serialization. Such a scheme will be like an extend= ed >>> version of I-JSON (RFC7493), potentially having an impact on "ordinary" >>> uses of JSON as well. >>> >>> Happy New [and optionally signed] JSON Year >>> Anders Rundgren >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > - Tim Bray (If you=E2=80=99d like to send me a private message, see > https://keybase.io/timbray) > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a11473304e2708f0561ac59f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I h= ave a schema language that I use to generate Web Service clients and servic= es. The implementation is open source. It also generates reference sections= for an Internet Draft:

http://www.prism= proof.org/Documents/draft-hallambaker-mesh-reference.html

Right now I have three separate sc= hema languages that were written at different times to target XML, JSON, AS= N.1 and TLS style encodings. 90% of them are the same.

What I think really commends JSON is the lack= of extraneous information in the schema. Let us say we are serializing an = integer. In the TLS schema I have to specify whether it is an 8, 16, or 32 = bit, signed or unsigned, etc. In JSON its just an integer.

I just want to think about my applicatio= n, I want the serialization to be as straightforward as possible. What I do= n't need or want is the type of capabilities XML Schema gives me, the a= bility to specify that an integer is greater then 4 and less than 23. That = is not information I have ever found the need to express in a schema and I = have been using this approach to generate protocols for 25 years.


What I have now is adequate for my needs rig= ht now. If there is interest in a standard, I would probably want to clean = up the approach and make it more regularized.


On Sun, Dec 31, 2017 at 1:50 PM, Tim Bray <tbra= y@textuality.com> wrote:
If I were = going to make an argument for keeping the WG alive, it would require someon= e to get energized and submit an I-D for a plausible JSON schema system, or= maybe even a much-needed formalization of JSONPath. We use JSONPath a lot = at AWS.
=
On Sun, Dec 31, 2017 at 10:43 AM, Richard Gi= bson <richard.gibson@gmail.com> wrote:
On the topic o= f JSON normalization, I believe that=C2=A0canonicaljson-spec=C2=A0cov= ers all cases while respecting prior art like https:= //tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00= and RFC 7638. I'd like to get it published as an RFC to handle scenari= os like those mentioned by Anders Rundgren, but am not sure how to go about= doing so. Is this a good place to ask for assistance?

On Su= n, Dec 31, 2017 at 12:24 AM, Anders Rundgren <anders.rundgren= .net@gmail.com> wrote:
Congratulations everybody to the revised JSON RFC!

Does this mean that JSON is "done" for good?

Probably not because the concept I have mentioned from time to time, the ab= ility adding a digital signature to a JSON object (in contrast to signing a= rbitrary Base64Url-encoded data), is still very much alive.=C2=A0 In fact, = there is an I-D in preparation aiming at reducing the current proliferation= of "DIY-standards" for dealing with this highly requested featur= e.=C2=A0 The only real challenge is agreeing on a suitable way "normal= izing" JSON data during parsing and serialization.=C2=A0 Such a scheme= will be like an extended version of I-JSON (RFC7493), potentially having a= n impact on "ordinary" uses of JSON as well.

Happy New [and optionally signed] JSON Year
Anders Rundgren

_______________________________________________
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




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

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


--001a11473304e2708f0561ac59f5-- From nobody Sun Dec 31 22:10:42 2017 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 6789E12422F for ; Sun, 31 Dec 2017 22:10:40 -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 HQkQb4tgCfZC for ; Sun, 31 Dec 2017 22:10:38 -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 4BCC31205F0 for ; Sun, 31 Dec 2017 22:10:38 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id n138so56527232wmg.2 for ; Sun, 31 Dec 2017 22:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=v3/OOfTcwyztDQj69NvTgt3m3c23nEpbuB8tUyQ/PZo=; b=TDmptWqwkGTeRh/7shOyQVhQtXO0xm2IszXIq+WccyW2sqwnttKErbIPjLhemJVNdT O+NLv0tI/wXiDeRSJ291pdnhPbP7K+OEJCOaSRSEKY2D0TGi3/qUhTxvsK6gFsP86gFU PUXrHC2NcGe3vTyhh/BlQxR8H8Zix8+FZl9D/uC96d/9j+F694qxDpd3PkWB6WnpjLbn 4rVHEePuxpkitS3alLMmFL8d8xgQ6HbXyXNf536vmDliWQ8NYwCGJKmNKj4ttV4Yj9WR wCQriZw75hRGh3uIfqrcFUYQhJO2TwWAqDs1zJdjMpJbiRIAE37T6nikTssPslNINqIO +flA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v3/OOfTcwyztDQj69NvTgt3m3c23nEpbuB8tUyQ/PZo=; b=ibkGlb2zrAvTfkXt+u+MxtOiORncsWknfNI2KGrrxps035zBMF1sIKMsTccTnnUJjL h0vQOKDsqHPxSnGnNrNuZX5kEG5TCLky6gZYwJU8K+/khI90R0NnpDQLbQnWPt66CmGy 3CGTuS8bGcyoLYOKCww9d5iuE4/8o6G5BpbzJ9Mk0eNPjfmnKZWB9aJUYqiU+Fu4mlCW e0k8uC/EG8HRFpStjAgiwyNhbPnbshw+13u8L5znGOu7ZaE3V2RFYYcqG1F1oaXxutya BPhzsJo3TtdZ70z46HcMuGqNTXdqgxvy+S5kzLROI9QZgc32xDstxAGIqY6UpuneRMkz Th3A== X-Gm-Message-State: AKGB3mLK9OnNegl1ACX5TyEodPIPPHDhST61C6tevhp2zf0odhzaXuaF kQv2v4cU6951xvYzIiWhx1s4Fg== X-Google-Smtp-Source: ACJfBovjjj/Fs5/vkhYndrrr80UZX+PHWIdXijkBrVL8VAr6sw35y69b3TIZ92wffsAbE1DiMoPraQ== X-Received: by 10.80.154.193 with SMTP id p59mr56038330edb.304.1514787036506; Sun, 31 Dec 2017 22:10:36 -0800 (PST) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id n3sm35683059edb.46.2017.12.31.22.10.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Dec 2017 22:10:35 -0800 (PST) To: Richard Gibson Cc: JSON WG References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> From: Anders Rundgren Message-ID: Date: Mon, 1 Jan 2018 07:10:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 06:10:40 -0000 On 2018-01-01 00:39, Richard Gibson wrote: > On Sun, Dec 31, 2017 at 4:34 PM, Anders Rundgren > wrote: > > For normalization it turns out that JSON.parse() and JSON.stringify() as specified by ECMA and already supported by the most widely available JSON tools is all you need! > > > That is definitely not true. A trivial counterexample: https://jsbin.com/luyoveyuqu/edit?js,console,output Right, JSON.stringify() doesn't not canonicalize but preserve property order [1] + normalize data which for "crypto-safe" JSON applications is entirely sufficient. If you go back to your example you can see another nicety of the EMCA parse/stringify scheme: JSON data is actually generated in the order specified by the programmer. Or as I like to put it: JSON grew out of JavaScript, now it has come home again :-) Cheers, Anders 1] Extract from an I-D in preparation: For JavaScript optimization reasons, ECMAScript's JSON.parse() internally rearranges order of properties with names expressed as integers, making a parsed JSON string like '{"2":"First","A":"Next","1":"Last"}' actually serialize as '{"1":"Last","2":"First","A":"Next"}'. Due to this fact, signature creators must (in the hopefully rather unusual case cross platform applications would mandate numeric property names), in an here unspecified way, "emulate" this scheme since this behavior is not intended to be an additional requirement to support by JSON tools in general in order to use this specification. From nobody Sun Dec 31 22:27:24 2017 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 E5737126D45 for ; Sun, 31 Dec 2017 22:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR9MZgGZvvSS for ; Sun, 31 Dec 2017 22:27:21 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::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 457BF1205F0 for ; Sun, 31 Dec 2017 22:27:21 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id p31so34898259ota.4 for ; Sun, 31 Dec 2017 22:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0hDtPjYzMs9pyF6502kMegumxiBRmiNpnLsy66ScyaI=; b=tBh6ZWnjCewV+jVGHKZ8lJsqnSQhwL3YM/LItBXypYiRCChYoXQu/aFWLd6qwhRkUA 8eqU5aqeS6vG4uWJNiZDLDQ7nykUqEB6P6AY56zupgOkvwfVzUyTQQYeYFhvr1QgC73l zRb8t2ErQn4LPduxJA5VlVBu+3l7MicKa/N2Z4nOKhy9v+XhXzwh/ha/2zVnVSrHv6G/ SWK9ahnu5Z2KpU6mYgucIzY4GeZOyyDDh+OA7zNGBAzFItfAiUefd58/GejgLA4YNXAs xl4GJXvfHuX9yIjFOlZJ2WbV1NLAxXNJENoS3L6g6bBy+Ujljl7hOGRMiN3iSFwoao8T 9lGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0hDtPjYzMs9pyF6502kMegumxiBRmiNpnLsy66ScyaI=; b=TWmJbz90lpID4MdjHpsLmoywj9Rgd+Wplb+TvPpulIAGfI6u5R5I8p0UKWRw0r5LiK KT8CAKP6ju4bvR94PuZRniuabiePI54fPGZuVpHTIvKfg3d+Yem5/YrbZ/sbA6Hk51Wa nNRIoNNQQfImvGRxYTQN6oGZF2xEtSowjahnu1pH1hkQLZmj60F7YnbW+6DoYF8VBdkS 33AQDX5Af/CTPb3YGD5kUXRVUeeOb2vuZn+39gYxM0s+kQQnXvfiw4gcu2OItaqEY8qv Z09kk+si1EJptggDjB+GyNyE5sTR9VclNA//v3PUaiAhcFwTIGGJj3tqEvUs3gv7XLfm j36Q== X-Gm-Message-State: AKGB3mIcpkt5hh7FUm2pzNK2oMe/qZvMkYAkNWjdu5bwzpIVWXZ0VSsM dblpvetkZa/0INxIJDuNU2XPzGwFGtSvgBVdRXA= X-Google-Smtp-Source: ACJfBouOMXrN9K4MRBZqNQTrFOg1SFBP3X6+xdcvGd8XLQV1eh9DYeNmQDbqeInXjWQf5qiyiYvY7kOQQIqu8n9qvu0= X-Received: by 10.157.63.69 with SMTP id m63mr17590038otc.52.1514788040510; Sun, 31 Dec 2017 22:27:20 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.49.87 with HTTP; Sun, 31 Dec 2017 22:27:19 -0800 (PST) In-Reply-To: References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> From: Phillip Hallam-Baker Date: Mon, 1 Jan 2018 01:27:19 -0500 X-Google-Sender-Auth: mW1iLy1LWJ-x9rQOHAiuDZzf2Fg Message-ID: To: Anders Rundgren Cc: Richard Gibson , JSON WG Content-Type: multipart/alternative; boundary="001a114733041091c90561b11328" Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 06:27:23 -0000 --001a114733041091c90561b11328 Content-Type: text/plain; charset="UTF-8" The use case that I believe gives rise to the belief canonicalization is necessary is the need to sign a data object in the same JSON document. I have this need frequently: { {A = [... JSON Data...]} { Signature (A) } } The way I solve this using JSON is to BASE-64 encode: { { A = base64(... JSON Data...)} { Signature (A) } } Which is brutal but entirely effective and only expands the data by 33% For an efficient encoding, I use JSON-B which is a strict superset of JSON with additional code points that allow binary data to be spliced in. JSON only uses bytes in the range 1-127 for tagging. Bytes in the range 128-255 can only occur inside strings. Which means all the other values can be repurposed In JSON-B, the binary sequence 01 02 03 can be encoded as either "AQID" or 88 03 01 02 03 The first byte says that this is a binary value with an 8 bit length and the final block of the sequence (i.e. there is only one block in this sequence). The second byte is the length. The rest is the data. I would much rather extend JSON to support efficient encoding of any binary value than develop a canonicalization hack that could only ever work for JSON. http://www.prismproof.org/Documents/draft-hallambaker-jsonbcd.html --001a114733041091c90561b11328 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The= use case that I believe gives rise to the belief canonicalization is neces= sary is the need to sign a data object in the same JSON document. I have th= is need frequently:

{ {A = =3D [... JSON Data...]} { Signature (A) } }

The way I solve this using JSON is to BASE-64 encode:<= /div>

{ { A =3D base64(... JSON= Data...)} { Signature (A) } }

Which is brutal but entirely effective and only expands the data= by 33%

For an efficient = encoding, I use JSON-B which is a strict superset of JSON with additional c= ode points that allow binary data to be spliced in.

JSON only uses bytes in the range 1-127 for tagg= ing. Bytes in the range 128-255 can only occur inside strings. Which means = all the other values can be repurposed

In JSON-B, the binary sequence 01 02 03 can be encoded as eit= her "AQID" or

8= 8 03 01 02 03
<= br>
The first b= yte says that this is a binary value with an 8 bit length and the final blo= ck of the sequence (i.e. there is only one block in this sequence).=C2=A0

The second byte is the len= gth.

=
The rest is the data= .


I would much rather extend JSON t= o support efficient encoding of any binary value than develop a canonicaliz= ation hack that could only ever work for JSON.

= http://www.prismproof.org/Documents/draft-hallambaker-jsonbcd.html
<= /div>


--001a114733041091c90561b11328-- From nobody Sun Dec 31 22:43:55 2017 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 6D2D2126D45 for ; Sun, 31 Dec 2017 22:43:54 -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 rJ5f4BVen0pI for ; Sun, 31 Dec 2017 22:43:52 -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 627ED124BE8 for ; Sun, 31 Dec 2017 22:43:52 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id n138so56576146wmg.2 for ; Sun, 31 Dec 2017 22:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Rbh+w5d6szBaMhlwA49met7C+o6oig496VzL4p73cRs=; b=aLd/edW/AUL66Y93ZMwd7DymeMw1oD3FxGSlKDacyncEmJk1kKItgSg3KykG+7MPog kKZWAFcFQptaFLRezYtfCx/2EUj6lfFTEESpY82fzUbqzkbnBnzx04lNP9QTZlTS5dFo abykaQI/9FjiVhNKtte9C3RFDziVIf66Q5nfDGvl30jCoqfy5rUhCyro8MTLnQa/egju 0xlTQvxpNu3OHifg079nQQQV1k2jdlqVLyfPMF/11VKLI0Fml09TprpbDsS6LDzwJbA5 uF0GEthIN+W5rN9y2x0RyR33QDJykjfvw7SuNGGAaoRDShep9Oms3maagIeTGJmJ6380 mOrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Rbh+w5d6szBaMhlwA49met7C+o6oig496VzL4p73cRs=; b=udYf+ZsBdRIU1RoX/3mt6rpHSKzOYV94K9hpmXAptBEpYgcBAgk8yFGTDDhLg8UPzf OgPNDwMTL1hm9/qVTsNV2z6YrqJPsuVnRglwQWNAqu0iUd0cF39omwCM0lIZ3BjBov6o DN6Epw62/yWz2I642NT+AGJiYsOIwdVRXRw5LnhLaJOSv3BeGPzG+syVgMx1glEh/gIe 56kA2ge6FQ7JChYtXVIG8J4BxFmCXrWSjnTUs/bas/mkR55eA28/0ObT+w+AXigUyVG8 gI0fxrM0LKM77JEwJ2RgtmeqYlsJW9vnOIipYQ4Tmft81txpOtBvsQYzBXIXzIzMrrWD 4nug== X-Gm-Message-State: AKGB3mK+0LkZX0ioedrMVE3v7rNEMamdRMe84I1OdbwOis5jYE5ewyW0 rUDf6D/A7p0Vpw4fWtZ6YybS5w== X-Google-Smtp-Source: ACJfBouhpnxGV5vBSX7qFVUng2oj0C9lg9bpdfctaBPiY0gnhbk1VS8I1i+u03KL6VzxeoOYrmWPQw== X-Received: by 10.80.149.152 with SMTP id w24mr57208174eda.76.1514789030522; Sun, 31 Dec 2017 22:43:50 -0800 (PST) Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id r15sm31914945edi.23.2017.12.31.22.43.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Dec 2017 22:43:49 -0800 (PST) To: Phillip Hallam-Baker Cc: Richard Gibson , JSON WG References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> From: Anders Rundgren Message-ID: Date: Mon, 1 Jan 2018 07:43:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Json] JSON Concluded? Well, maybe not X-BeenThere: json@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2018 06:43:54 -0000 On 2018-01-01 07:27, Phillip Hallam-Baker wrote: > The use case that I believe gives rise to the belief canonicalization is > necessary is the need to sign a data object in the same JSON document. Yes, but this is indeed only a belief. The following in-object signature would validate in any JSON system compliant with ECMA: { "now": "2017-04-16T11:23:06Z", "escapeMe": "\u20ac$\u000F\u000aA'\u0042\u0022\u005c\\\"\/", "numbers": [1e+30,4.5,6], "signature": { "alg": "ES256", "jwk": { "kty": "EC", "crv": "P-256", "x": "_gow8fcS3Dx9z6j57U5q8tunnRBdrgLU9A7CZTYCnqU", "y": "bdfJGraBVL5aPj38TG4tHwxpU2VKwG1XBp0wQfCLOFQ" }, "val": "OfTUed3gOO58ZPcP5ZXpL6OA9iyHskfo0zKI60H6XriGNNNb5sugGz80nqfyJ25jXPRYGAWcjH-1KGy5_eQuJQ" } } // Perform normalization var clone = Object.assign({}, signedObject.signature); // Clone "signature" child object var signature = decodeBase64URL(clone.val); // Get signature value delete signedObject.signature.val; // Remove signature value property from signed object var data = convertToUTF8(JSON.stringify(signedObject)); // Get normalized JSON string (signed data) signedObject.signature = clone; // Restore signed object // Do the crypto now That's clearly not rocket science. Anders > I have this need frequently: > > { {A = [... JSON Data...]} { Signature (A) } } > > The way I solve this using JSON is to BASE-64 encode: > > { { A = base64(... JSON Data...)} { Signature (A) } } > > Which is brutal but entirely effective and only expands the data by 33% > > For an efficient encoding, I use JSON-B which is a strict superset of JSON with additional code points that allow binary data to be spliced in. > > JSON only uses bytes in the range 1-127 for tagging. Bytes in the range 128-255 can only occur inside strings. Which means all the other values can be repurposed > > In JSON-B, the binary sequence 01 02 03 can be encoded as either "AQID" or > > 88 03 01 02 03 > > The first byte says that this is a binary value with an 8 bit length and the final block of the sequence (i.e. there is only one block in this sequence). > > The second byte is the length. > > The rest is the data. > > > I would much rather extend JSON to support efficient encoding of any binary value than develop a canonicalization hack that could only ever work for JSON. > > http://www.prismproof.org/Documents/draft-hallambaker-jsonbcd.html > > >