From nobody Mon Jan 1 06:30:36 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BC1124239 for ; Mon, 1 Jan 2018 06:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9i09pQjGKHv for ; Mon, 1 Jan 2018 06:30:32 -0800 (PST) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C369C124207 for ; Mon, 1 Jan 2018 06:30:31 -0800 (PST) Received: (qmail 31670 invoked from network); 1 Jan 2018 14:20:55 +0000 Received: from host109-158-28-63.range109-158.btcentralplus.com (HELO ?192.168.1.72?) (109.158.28.63) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 1 Jan 2018 14:20:55 +0000 To: Tim Bray Cc: "json@ietf.org" References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> From: Pete Cordell Message-ID: Date: Mon, 1 Jan 2018 14:30:27 +0000 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON Schema (Was: 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 14:30:34 -0000 On the JSON schema topic, Andy Newton and I, with the help of a number of people active in the IETF, have been working on something called "JSON Content Rules". The current I-D is at: https://www.ietf.org/id/draft-newton-json-content-rules-09.txt The aim is for it to be easy to write, and easy to understand. It's a "JSON-like" syntax, as it was felt restricting it to pure JSON made the syntax harder to write and read. There's a few more details at the following address, including details of implementations so far: http://json-content-rules.org We're happy to discuss it with anyone, either here, using my send address, or via contact@json-content-rules.org . Happy New Year! Pete. On 31/12/2017 18: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. > > 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 > > 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 > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > > > > -- > - Tim Bray (If you’d like to send me a private message, see > https://keybase.io/timbray) > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Mon Jan 1 09:17:22 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB86912025C for ; Mon, 1 Jan 2018 09:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 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, HTML_OBFUSCATE_05_10=0.26, 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 56EiPYmgmeMS for ; Mon, 1 Jan 2018 09:17:19 -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 19D0F124D6C for ; Mon, 1 Jan 2018 09:17:19 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id b56so27830723otd.10 for ; Mon, 01 Jan 2018 09:17:19 -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=qfhHTVag/Lqmr9fY3picLadvm8k1TqeAxdoDX3N50uA=; b=G9xy9Kfiiig4aLSozT3aAGMkj17s1iyHn1LC6u4pysTEQJhML9RN4xU14Egf1h9cgJ dbOfrWbWaqBAQn1yr8P1tnhiiUo60T9u95QLjKlk2a7m0P0DAjm8vHWLf2OvXSnINMUZ 2Fv3rwqvjBrP1aCTyvCAHAi6kKQWvbs8KZhFUpfvieVGANiGTJtdsVMF0LPq6j7iXMk8 Rg8J8cDjUzDtflscYNEzB5h1clFkc5obC80PH7sZKj+jRp50s6/wMR9VM9vfCUGoooUe yy0MfP1Ewzgnu8YsuKFDpp3O0Map16xvcl0JsG7bX+PNGwFY2oDPLrDtRX9tWo3XHE4z r2LQ== 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=qfhHTVag/Lqmr9fY3picLadvm8k1TqeAxdoDX3N50uA=; b=A0i5qCqEKYgXuLD9eCYffr2Xcd4PAiOpvMTjTlVeCdEaj/X4tNSdQJziLMVZbrgtrW /LvmVSY0bf3U57vGoY71yYc3JAn24rk+n3Hdh397ZoE6LkbKXu/PnBVHlLb0LlRV4k5t wPialSVy8tkJ11cDrwL+oWgkFhQ1jPU5wUlEeakkbjBGLPruNn0UEVDfVUUQ9xcrUUsN TdxxNXDDiRjTdiBvfvIo5Odg0oMtPjCmdcf1z6qnypcrSUcxh3ucs/Q+L9o3FqNimATw kkKNntbn36/3vlEsypaACtdqO2gbvK1o96HLCDNmA0xTZqcgOrze1uDbBn+1ef5h8D72 HfIQ== X-Gm-Message-State: AKGB3mLjDSUa7tZb+0XD2RBnBjAXZiQp4aHuT++91jcmSpf1UkinZuHR 7nStlTifVfdXSWjYRnXMB9VQ9EFGCEbMQ0u0/4M= X-Google-Smtp-Source: ACJfBos53v30OXTcqDow3lLIWgIxUP9K5ST+j75MX8NssC6gA8z4zLx5F5qNfNzBQhLU6GPh0NGz0tFvkitDQE4mbS0= X-Received: by 10.157.26.50 with SMTP id a47mr18726899ote.149.1514827038311; Mon, 01 Jan 2018 09:17:18 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.49.87 with HTTP; Mon, 1 Jan 2018 09:17:17 -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 12:17:17 -0500 X-Google-Sender-Auth: KT7mrtjI8RJM4cWuxcLeK8pj9No Message-ID: To: Anders Rundgren Cc: Richard Gibson , JSON WG Content-Type: multipart/alternative; boundary="001a11463ba083cb940561ba279f" 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 17:17:21 -0000 --001a11463ba083cb940561ba279f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BI can't see the need for stringify there. By which I mean, my code= runs and I do not use javascript or stringify anywhere. =E2=80=8BWhere I think folk tend to go really wrong is doing the stuff peop= le decided they wanted with XML Signature which was to have the following: Unsigned object: Signed object: {path transform} {etc} And it worked exactly as well as could be expected. On Mon, Jan 1, 2018 at 1:43 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > 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": "OfTUed3gOO58ZPcP5ZXpL6OA9iyHskfo0zKI60H6XriGNNNb5sugGz80nqf > yJ25jXPRYGAWcjH-1KGy5_eQuJQ" > } > } > > > // Perform normalization > var clone =3D Object.assign({}, signedObject.signature); // Clone > "signature" child object > var signature =3D decodeBase64URL(clone.val); // Get > signature value > delete signedObject.signature.val; // Remove > signature value property from signed object > var data =3D convertToUTF8(JSON.stringify(signedObject)); // Get > normalized JSON string (signed data) > signedObject.signature =3D clone; // Restore > signed object > // Do the crypto now > > That's clearly not rocket science. > > Anders > > > I have this need frequently: >> >> { {A =3D [... JSON Data...]} { Signature (A) } } >> >> The way I solve this using JSON is to BASE-64 encode: >> >> { { 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 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 w= ork >> for JSON. >> >> http://www.prismproof.org/Documents/draft-hallambaker-jsonbcd.html >> >> >> >> > --001a11463ba083cb940561ba279f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=E2= =80=8BI can't see the need for stringify there. By which I mean, my cod= e runs and I do not use javascript or stringify anywhere.

=E2=80=8BWhere I think folk tend to go r= eally wrong is doing the stuff people decided they wanted with XML Signatur= e which was to have the following:

Unsigned object:

<object>
=C2=A0 =C2=A0<blahdyblah/>
</object>

Signed object:

<object>
=C2=A0 =C2=A0<blahdyblah/>
=C2= =A0 =C2=A0<signature>
=C2=A0 =C2=A0= =C2=A0 {path transform}
=C2=A0 =C2=A0 = =C2=A0 {etc}
=C2=A0 =C2=A0</signature&= gt;
</object>

And it worked exactly as well as could b= e expected.

On M= on, Jan 1, 2018 at 1:43 AM, Anders Rundgren <anders.rundgren= .net@gmail.com> wrote:
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.=C2=A0 The following in-object signat= ure would validate in any JSON system compliant with ECMA:

{
=C2=A0 "now": "2017-04-16T11:23:06Z",
=C2=A0 "escapeMe": "\u20ac$\u000F\u000aA'\u0042\u00= 22\u005c\\\"\/",
=C2=A0 "numbers": [1e+30,4.5,6],
=C2=A0 "signature": {
=C2=A0 =C2=A0 "alg": "ES256",
=C2=A0 =C2=A0 "jwk": {
=C2=A0 =C2=A0 =C2=A0 "kty": "EC",
=C2=A0 =C2=A0 =C2=A0 "crv": "P-256",
=C2=A0 =C2=A0 =C2=A0 "x": "_gow8fcS3Dx9z6j57U5q8tunnRBdrgLU9A7CZTYCnqU",
=C2=A0 =C2=A0 =C2=A0 "y": "bdfJGraBVL5aPj38TG4tHwxpU2VKwG1XBp0wQfCLOFQ"
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "val": "OfTUed3gOO58ZPcP5ZXpL6OA9iyHskfo0= zKI60H6XriGNNNb5sugGz80nqfyJ25jXPRYGAWcjH-1KGy5_eQuJQ"
=C2=A0 }
}


=C2=A0 // Perform normalization
=C2=A0 var clone =3D Object.assign({}, signedObject.signature);=C2=A0 =C2= =A0 =C2=A0// Clone "signature" child object
=C2=A0 var signature =3D decodeBase64URL(clone.val);=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Get signature value
=C2=A0 delete signedObject.signature.val;=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// Remove signature= value property from signed object
=C2=A0 var data =3D convertToUTF8(JSON.stringify(signedObject));=C2=A0= =C2=A0 // Get normalized JSON string (signed data)
=C2=A0 signedObject.signature =3D clone;=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 // Restore s= igned object
=C2=A0 // Do the crypto now

That's clearly not rocket science.

Anders


I have this need frequently:

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

The way I solve this using JSON is to BASE-64 encode:

{ { 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 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 th= e final block of the sequence (i.e. there is only one block in this sequenc= e).

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 J= SON.

http://www.prismproof.org/Documents/draft-hallambaker-jsonbcd.html





--001a11463ba083cb940561ba279f-- From nobody Mon Jan 1 09:55:11 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7464F1267BB for ; Mon, 1 Jan 2018 09:55:09 -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 MZ-PZM5LN9Aq for ; Mon, 1 Jan 2018 09:55:07 -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 323F912025C for ; Mon, 1 Jan 2018 09:55:07 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id g75so58339991wme.0 for ; Mon, 01 Jan 2018 09:55:07 -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=O1UkisssM/8leCRxAcz3WgudI9nxZNx2yT+7vPygXqk=; b=p8MKI0uxt+k7TAwCHJxdpwS+Yj8JKhfIF1CaHDLgyP9tK159pdFVhVWDObku8CFgjf HAqJMIBWBLkv7qQsYiLHNIttM9Vk6bjr8w64/LAefC7VgngCGWhJOJZO6po7mIu6/+HJ 7WedXMh3GQAZJj6NB5UBKQveqNz72TsrL9CSTHKIi+N4fKCgbOWgP2Syc922cwW2LSAn CNgfwzaGE1/NAroMBOcTOKRkt8Si8ZZxnBDMDF2dTG/CuIS6tRfXwyPwx8uFNAM+DlMp Pg7FmhD5ucB+maNBXZpGv421pfiXP6dHndQV4polmgc+o+YttXiVTBPAYK53BO7uW1y1 e4ug== 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=O1UkisssM/8leCRxAcz3WgudI9nxZNx2yT+7vPygXqk=; b=KgtLN7hy4j8dPxPILKfen0qZAmPQ+iR6Y+L+soNFhHybBVmOskZLllG/QH8NtZrmwh Np089hhdNhRK3s0zZiZY+o/KCvfMllxIRYwr58v3cQ0+PvrBBOh8PIgW7PB77Ya6Mk0r 9oCZ1ADZ9C3czyPevO8t6z3xm7cBl2+XJQ+mNpcR97ESrNHZ1zVDj+PC2a4oE9E88UNb Td2Vv9xfMFKWKM66EtE0xFvOBC/JJTXkWoG8+ZiaNWd1LvxqUUfQ1sf1aIv+YmkRg1Q6 dDJK9Na4Tb3P6RWWGr7a6HA4hkIq73vBn/+D87nZ0dvGCjtUK7EgAuSlMUyWejfMiVfJ l9LQ== X-Gm-Message-State: AKGB3mLbuy7734lk3hYvA7HrW8ddJBaLUUlYYn5jj4hmIMV4URIjVa2V KBupSro/5TNnEFzTBSd7l8PEfQ== X-Google-Smtp-Source: ACJfBov6i5efjIdxFvk/r7Tv5h2rG9fMzJpeWqi8F9trjcJOPK56W7msklD09wWWzC5YjSKxQW+QAw== X-Received: by 10.80.141.141 with SMTP id r13mr58415037edh.122.1514829305212; Mon, 01 Jan 2018 09:55:05 -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 y3sm39323827edb.37.2018.01.01.09.55.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jan 2018 09:55:04 -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: <4950bfd0-9f89-4fe8-4e85-eb397a40afb1@gmail.com> Date: Mon, 1 Jan 2018 18:55:01 +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: 8bit 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 17:55:09 -0000 On 2018-01-01 18:17, Phillip Hallam-Baker wrote: > ​I can't see the need for stringify there. By which I mean, my code runs and > I do not use javascript or stringify anywhere. The only "hard" requirement is that the JSON tool adheres to ECMA's ES6+ JSON processing rules. With the exception of "Number" normalization [1] this is a trivial matter [2]. By putting your JSON data in Base64 or using special JSON dialects you can of course do things differently. > ​Where I think folk tend to go really wrong is doing the stuff people > decided they wanted with XML Signature which was to have the following: > > Unsigned object: > > >     > > > Signed object: > > >     >     >       {path transform} >       {etc} >     > > > And it worked exactly as well as could be expected. The sample and its associated scheme does (by design) NOT perform any sophisticated textual processing. Maybe it only covers 80% of the "market". Is that a showstopper? Anders 1] https://www.ecma-international.org/ecma-262/8.0/index.html#sec-tostring-applied-to-the-number-type 2] https://docs.oracle.com/javase/8/docs/api/java/util/LinkedHashMap.html > On Mon, Jan 1, 2018 at 1:43 AM, Anders Rundgren > wrote: > > 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 > > > > > From nobody Tue Jan 2 08:33:59 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6401F12D77A for ; Tue, 2 Jan 2018 08:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 H6C_26oBlHZT for ; Tue, 2 Jan 2018 08:33:56 -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 71252124319 for ; Tue, 2 Jan 2018 08:33:56 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id 9so62032065wme.4 for ; Tue, 02 Jan 2018 08:33:56 -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=Y1VNWEspGLKUL83HuJ34/QINjTGhAwr1BAgpXW9FHRU=; b=VMMaHNsPFmOqzEDCYcIUccJ71NRj/XJnuA75wWduZOk8mNtxTdkstsjNMYXH4z16nY FjcNpxQTnwoiGkL4rX2PpGSuVhmO9Xb8dB5oTCaR1GPC9kSj+/xnWRnOh1NW0LVbRQgf XFYmBBtA1FobR2/P83uGLe8VtGj9IO0qfiUJZYD6bIgjECmMBU4UMu1bshQd3cw+7ktH tsAMYSaF09HU1Vy2Mu5yhDnwPw0aHLbAJAcaOkyIYTLYFIeRSHc3lPHKYLOTjFwskHTr udYIJYGBrGeOvJS7jo74JVABot5KyT5nUrhbQs4DkpM/ToN+IyepS57F0r+ErPrPgjZM xvLQ== 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=Y1VNWEspGLKUL83HuJ34/QINjTGhAwr1BAgpXW9FHRU=; b=lXTMrv4xx277ZM/If0wrR/qYaU4BAlR8XrvVrnX8GETT7Z6uFuZEPi23Y2KzD1LGbC BfC9uqXV87DkcauFdPpyH2dJFpO4/CiN4rYFnUefFuvS84uop5vp50TMGULjg3fPGJEY mdObIRVHunGqNXplhY/wIcb0pQ4OiWXFxprXgN9z8+XlCV7B5MBTavFt/qOoNSi57zu5 tObKHugJjqS+i2yFKkX7wH+XQCVEuTGvNR3TeWiQ9a/nY6mi3+ZW+GTBVhmDtaqNe/qt Nlda/7rP5vbYeXAiOC0JdwncXP0yy8VJnKAajkyuvEywvGuZZhpi+Yh6MsWdJER8KRRx cxdA== X-Gm-Message-State: AKGB3mLnktXMIZhN/cp5Spz/P7V/FORN3CC/jQ2bnVlXb5vHF1iLA6ap TqVDczsHLc6dENFk98JA9+G5/ogj4ckaq76Cxcw= X-Google-Smtp-Source: ACJfBotRBvNy0x1TiXDwlxizEwP8V1DDuVfG+rPEBHKxigT0JA1vFQrl1uPrx7v9J+xZ83dcjVsMegW2VJduL6R2lBw= X-Received: by 10.28.178.85 with SMTP id b82mr35728156wmf.47.1514910834994; Tue, 02 Jan 2018 08:33:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.189 with HTTP; Tue, 2 Jan 2018 08:33:54 -0800 (PST) In-Reply-To: References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> From: Richard Gibson Date: Tue, 2 Jan 2018 11:33:54 -0500 Message-ID: To: Anders Rundgren Cc: JSON WG Content-Type: multipart/alternative; boundary="001a11444aec2fb3de0561cdaaef" 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: Tue, 02 Jan 2018 16:33:58 -0000 --001a11444aec2fb3de0561cdaaef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 1, 2018 at 1:10 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2018-01-01 00:39, Richard Gibson wrote: > >> 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 >> > > Right, JSON.stringify() doesn't not canonicalize but preserve property > order [1] + normalize data which for "crypto-safe" JSON applications is > entirely sufficient. > JSON.stringify assumes information that is explicitly not conveyed by JSON (in which an object is "an unordered collection of zero or more name/value pairs") [1], and both its number serialization [2] and string serialization [3] specify aspects that harm compatibility (the former having arbitrary value-dependent branches, the latter being capable of producing invalid UTF-8 octet sequences that represent unpaired surrogate code points=E2=80=94unacceptable for exchange outside of a closed ecosystem [4])= . JSON is a general language-agnostic interchange format, and ECMAScript JSON.stringify is *not* a JSON canonicalization solution. [1]: https://tools.ietf.org/html/rfc8259#section-1 [2]: http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-num= ber-type [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring [4]: https://tools.ietf.org/html/rfc8259#section-8.1 --001a11444aec2fb3de0561cdaaef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jan 1, 2018 at 1:10 AM, Anders Rundgren <anders.rundgren= .net@gmail.com> wrote:
On 2018-01-01 00:39, Richard Gibson wrote:
On Sun, Dec 31, 2017 at 4:34 PM, Anders Rundgren <anders.rundgren.net@gmail.com<= /a> <mailto:anders.rundgren.net@gmail.com>> wrote:

=C2=A0 =C2=A0 For normalization it turns out that JSON.parse() and JSON.str= ingify() as specified by ECMA and already supported by the most widely avai= lable 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 applicati= ons is entirely sufficient.

JSON.string= ify assumes information that is explicitly not conveyed by JSON (in which a= n object is "an unordered collection of zero or more name/value pairs&= quot;) [1], and both its number serialization [2] and string serialization = [3] specify aspects that harm compatibility (the former having arbitrary va= lue-dependent branches, the latter being capable of producing invalid UTF-8= octet sequences that represent unpaired surrogate code points=E2=80=94unac= ceptable for exchange outside of a closed ecosystem [4]). JSON is a general= language-agnostic interchange format, and ECMAScript JSON.stringify is *no= t* a JSON canonicalization solution.

[1]:=C2=A0https://tools.ietf.org/html/rfc8259#section-1
[2]:=C2=A0http://ecma-international.org/ecma= -262/7.0/#sec-tostring-applied-to-the-number-type
[3]:=C2=A0http://ecma-international.org/ecma-262/7.0/#sec-quote= jsonstring
[4]:=C2=A0https://tools.ietf.org/html/rfc82= 59#section-8.1
--001a11444aec2fb3de0561cdaaef-- From nobody Tue Jan 2 23:06:45 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFDA120713 for ; Tue, 2 Jan 2018 23:06:42 -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 M7OPAQqXvCFy for ; Tue, 2 Jan 2018 23:06:40 -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 78F8C120227 for ; Tue, 2 Jan 2018 23:06:40 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id t8so935008wmc.3 for ; Tue, 02 Jan 2018 23:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=H6lV2au4HhBiveawoScqDKMuAvZVzkBQCnrLvWXg1IA=; b=ZlSj5//Sp5ZkjRHVSKW/Q81/bhH6JJ9yWkYKUQu5DtGdBrMnDH+BGigOvhzVBrY55t 6PKDsbWB3jQSt1W6rhHgvY476bCOW00exUXCbEdWLKVLl0RuHWilDEF09LDyURG3wcTj LQh+DIA+x17rGmRW7lB0Ty1pWuWVXEpV1YaaAazXKZifH6WsqiKCan89f5YGw3XiWq6Z WxuCjShcRV4tEzqRrzyEiXpNfT7Xo51BuOCHSycj5o7tgq9NerYFAHwx6pU7jgk1Ny8l ztPI3ZqAfVdoMtpH7CuALaJI8+gY+Q9CzJutLEfAet76J/5HaYLD8ZEcIun1RRKY0lVR m8sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=H6lV2au4HhBiveawoScqDKMuAvZVzkBQCnrLvWXg1IA=; b=moFw/iEb95F2yqr0vgN63BgsF4GaTLNrzMbdCV9lnlnHEi5nu8I2Gyy3vJBsGi/AY/ tCmWT12tuArLxrQJmHg/p0QQCEhpgZCZBIaDzDfB5PoiBPaoH3p6DgELdXtLgRqPbtUo Xd8c3b22zlpaRa7wPnzy4wB0OCBBGBXDa7ZjKnBlVzKTQySFoTR5hJj2EsHzbNjkud4r 32W1wCq3C2+Peruh6HTMEEQtVEyAhniFc/fbDErQn6rDXerEQTkmJMAm2EkOftC5DxAp Nz3+zWRPmCIsyUKTq9C/D4qb3pV1AAaP9LGFPqwWTe6bcWjPLKr3jInRf3sMu38Q7I+/ OApw== X-Gm-Message-State: AKGB3mJtwMF4sS6ewnWdcrVO+QWDy2inkE7y0fi9mGMRc/nwKZpzvqqt PVFTR+/53eyo2q6k0bRzIwqCTg== X-Google-Smtp-Source: ACJfBouSSjjVS90n94P8K+WAdmeIPxYW0Ld8WidGRxanrB+kmm2E2kTy/+mw78EvZ+/mZitncPdT+w== X-Received: by 10.80.211.18 with SMTP id g18mr1309156edh.279.1514963198872; Tue, 02 Jan 2018 23:06:38 -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 g20sm315860edb.75.2018.01.02.23.06.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 23:06:37 -0800 (PST) From: Anders Rundgren To: Richard Gibson Cc: JSON WG References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> Message-ID: <15337fea-5cec-0306-939b-df40b3a367d6@gmail.com> Date: Wed, 3 Jan 2018 08:06:36 +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: 8bit 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: Wed, 03 Jan 2018 07:06:43 -0000 On 2018-01-02 17:33, Richard Gibson wrote: > JSON.stringify assumes information that is explicitly not conveyed > by JSON (in which an object is "an unordered collection of zero or > more name/value pairs") [1], and both its number serialization [2] > and string serialization [3] specify aspects that harm compatibility > (the former having arbitrary value-dependent branches, the latter being > capable of producing invalid UTF-8 octet sequences that represent unpaired > surrogate code points—unacceptable for exchange outside of a closed > ecosystem [4]). JSON is a general language-agnostic interchange format, > and ECMAScript JSON.stringify is *not* a JSON canonicalization solution. > > [1]: https://tools.ietf.org/html/rfc8259#section-1 > [2]: http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type > [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring > [4]: https://tools.ietf.org/html/rfc8259#section-8.1 JSON is a format defined the IETF and ECMA in some kind of cooperation. ECMA's ECMAScript defines a set of ("fairly" easy to implement) JSON processing rules which are fully compatible [1] with the JSON format. The idea using ES6+ number normalization was originally proposed by an esteemed member of the now concluded JOSE WG: https://www.ietf.org/mail-archive/web/jose/current/msg05323.html Following that path, I (accidentally) discovered the "missing link", ES6+'s preservation [2] of the original property ordering which in my mind is quite logical [3] for "ordinary" JSON usage as well. A Java based reference implementation has been successfully tested against Chrome, Node.js, Firefox and Safari. Feel free taking a test ride on: https://mobilepki.org/jose-jcs/home Note that it outlaws signing a JSON "Number" expressed as "1.0" since the correct (according to ES6+) representation is "1". Anders 1] possibly with the exception of "unpaired surrogate code points" which I admittedly know zilch about 2] with properties named as integers as a for practical purposes insignificant exception 3] Making data come out in the order it was specified addresses human aspects like debugging and documentation of JSON data From nobody Wed Jan 3 09:25:10 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B3C124BFA for ; Wed, 3 Jan 2018 09:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 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, HTML_OBFUSCATE_05_10=0.26, 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 oT2Jc0FXifwx for ; Wed, 3 Jan 2018 09:25:05 -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 5964F1241F5 for ; Wed, 3 Jan 2018 09:25:05 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id n138so3910726wmg.2 for ; Wed, 03 Jan 2018 09:25:05 -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=r1JZKaISdC0/klppAaslxtt62nTZ514Cyg2plxuPpPA=; b=tt8vOAqViDlSzNvbKRvxYX6QMsIAKkmb7p4djR2pUN/g2LWVlNaJAksJveHrArlc/m MyS/SmjS4f2WcBhYFSr1E3nxf49E0PirNEngviv137KXdCEeO5m6gVJFwHPQjojv5gP3 D5N/0jlLgbfB6+RZGEFaxtOZWt5SWlIZ+EbIGq/QxBhJtVpDxJJwY4ygq+MwsLzHrKNh WeJBjAvEq3IjIwSif4CWqdyN4WSG4zeWM4/Lf4pTcjUUduXkt8ws8uUFcJy76b03cgvr ixiFnWCsMZHomuM9W9xIzh1vo9LZuZXCWXW0zik/B8fi+a0mhSvgtnKU/UVGzGCilB13 skmA== 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=r1JZKaISdC0/klppAaslxtt62nTZ514Cyg2plxuPpPA=; b=jd/xE908VPmucYOB2OhWpfws+6g49rz+SRIvLTdP1jta0vQ/qjwlnuXJKPgWFZivyn rJ8k+C7j14Zd9nMgnhcJwxzvGX8BICNx7LzsStyX16MM4WAEUmXviK2/a77MnldDIErK Ikj3wB0vlDDQJpuIctulDacwAIZLzY4+2sUpljNplB6MdO5P7bDSwSJaTyfEJ+tTUuXb cDqg9YtljtO1vovqIX+lXtpgY1ykPBcHtJni41UrD0LouVRuVwegV9mygZSX7Dopnhl8 hinM95Wn3VT5l4UxGNg5/Qd5ERLIfDQAwVQA34eEMS/jeHssNEOIfBvTXf4QT/bVhutL znxQ== X-Gm-Message-State: AKGB3mKm5luAIZ/KjCr3wCE1z81eo/XzhZZAf6s8EUC9oDOGYJHd3OVn v5tNjKNyLycm5RwRxbIOMH2lX4Bsj5H8/5UaLkE= X-Google-Smtp-Source: ACJfBovOvUzhQ7vJQRbxMS+8T/FMFEQzzlqWAaKkyt8OcpZaRMyFajqQEztbt33tBoldVXPz1s+qa2GpY87OKQ+p5LU= X-Received: by 10.28.178.85 with SMTP id b82mr1887644wmf.47.1515000303727; Wed, 03 Jan 2018 09:25:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.189 with HTTP; Wed, 3 Jan 2018 09:25:02 -0800 (PST) In-Reply-To: <15337fea-5cec-0306-939b-df40b3a367d6@gmail.com> References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> <15337fea-5cec-0306-939b-df40b3a367d6@gmail.com> From: Richard Gibson Date: Wed, 3 Jan 2018 12:25:02 -0500 Message-ID: To: Anders Rundgren Cc: JSON WG Content-Type: multipart/alternative; boundary="001a11444aecf038100561e27e11" 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: Wed, 03 Jan 2018 17:25:09 -0000 --001a11444aecf038100561e27e11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm really not sure where the disconnect between us is coming from... JSON specifies unordered keys for objects, arbitrary-precision numbers, and strings that can contain code points excluded from UTF-8. As such, ECMAScript JSON.stringify is *not* suitable for JSON canonicalization, though it may suffice for certain Javascript-centric or otherwise restricted subsets thereof as addressed by JOSE. I believe that a general solution like http://gibson042.github.io/canonicaljson-spec/ is needed to avoid this seemingly endless series of special cases [1] [2] [3] [etc] (including those that have nothing to do with cryptographic signatures or encryption), and therefore wish to work towards an RFC describing it. There's no problem if you're uninterested, or even if you believe that a general solution is unwarranted, but there _is_ a problem if you believe that JSON.stringify already provides one. [1]: https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 [2]: https://tools.ietf.org/html/rfc7638#section-3.3 [3]: https://keybase.io/docs/api/1.0/canonical_packings#json [etc]: http://wiki.laptop.org/go/Canonical_JSON On Wed, Jan 3, 2018 at 2:06 AM, Anders Rundgren < anders.rundgren.net@gmail.com> wrote: > On 2018-01-02 17:33, Richard Gibson wrote: > > > > JSON.stringify assumes information that is explicitly not conveyed by JSO= N >> (in which an object is "an unordered collection of zero or more name/val= ue >> pairs") [1], and both its number serialization [2] >> and string serialization [3] specify aspects that harm compatibility >> (the former having arbitrary value-dependent branches, the latter being >> capable of producing invalid UTF-8 octet sequences that represent unpair= ed >> surrogate code points=E2=80=94unacceptable for exchange outside of a clo= sed >> ecosystem [4]). JSON is a general language-agnostic interchange format, >> and ECMAScript JSON.stringify is *not* a JSON canonicalization solution. >> >> [1]: https://tools.ietf.org/html/rfc8259#section-1 >> [2]: http://ecma-international.org/ecma-262/7.0/#sec-tostring-app >> lied-to-the-number-type >> [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring >> [4]: https://tools.ietf.org/html/rfc8259#section-8.1 >> > > JSON is a format defined the IETF and ECMA in some kind of cooperation. > > ECMA's ECMAScript defines a set of ("fairly" easy to implement) JSON > processing rules which are fully compatible [1] with the JSON format. > > The idea using ES6+ number normalization was originally proposed by an > esteemed member of the now concluded JOSE WG: > https://www.ietf.org/mail-archive/web/jose/current/msg05323.html > > Following that path, I (accidentally) discovered the "missing link", > ES6+'s preservation [2] of the original property ordering which in my min= d > is quite logical [3] for "ordinary" JSON usage as well. > > A Java based reference implementation has been successfully tested agains= t > Chrome, Node.js, Firefox and Safari. > > Feel free taking a test ride on: https://mobilepki.org/jose-jcs/home > Note that it outlaws signing a JSON "Number" expressed as "1.0" since the > correct (according to ES6+) representation is "1". > > Anders > > 1] possibly with the exception of "unpaired surrogate code points" which = I > admittedly know zilch about > 2] with properties named as integers as a for practical purposes > insignificant exception > 3] Making data come out in the order it was specified addresses human > aspects like debugging and documentation of JSON data > --001a11444aecf038100561e27e11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm really not sure where the disconnect between us is= coming from... JSON specifies unordered keys for objects, arbitrary-precis= ion numbers, and strings that can contain code points excluded from UTF-8. = As such, ECMAScript JSON.stringify is *not* suitable for JSON canonicalizat= ion, though it may suffice for certain Javascript-centric or otherwise rest= ricted subsets thereof as addressed by JOSE. I believe that a general solut= ion like=C2=A0ht= tp://gibson042.github.io/canonicaljson-spec/ is needed to avoid this se= emingly endless series of special cases [1] [2] [3] [etc] (including those = that have nothing to do with cryptographic signatures or encryption), and t= herefore wish to work towards an RFC describing it. There's no problem = if you're uninterested, or even if you believe that a general solution = is unwarranted, but there _is_ a problem if you believe that JSON.stringify= already provides one.

<= /div>

On Wed, Jan = 3, 2018 at 2:06 AM, Anders Rundgren <anders.rundgren.net@gmail= .com> wrote:
On 2018-01-02 = 17:33, Richard Gibson wrote:

<snip>

JSON.stringify assumes information that is explicitly not conveyed by JSON = (in which an object is "an unordered collection of zero or more name/v= alue pairs") [1], and both its number serialization [2]
and string serialization [3] specify aspects that harm compatibility
(the former having arbitrary value-dependent branches, the latter being
capable of producing invalid UTF-8 octet sequences that represent unpaired<= br> surrogate code points=E2=80=94unacceptable for exchange outside of a closed=
ecosystem [4]). JSON is a general language-agnostic interchange format,
and ECMAScript JSON.stringify is *not* a JSON canonicalization solution.
[1]: https://tools.ietf.org/html/rfc8259#section-1=
[2]: http://ecma-= international.org/ecma-262/7.0/#sec-tostring-applied-to-the-numbe= r-type
[3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring
[4]: https://tools.ietf.org/html/rfc8259#section= -8.1

 JSON is a format defined the IETF and ECMA in some kind of cooperation.

ECMA's ECMAScript defines a set of ("fairly" easy to implemen= t) JSON processing rules which are fully compatible [1] with the JSON forma= t.

The idea using ES6+ number normalization was originally proposed by an este= emed member of the now concluded JOSE WG:
https://www.ietf.org/mail-archi= ve/web/jose/current/msg05323.html

Following that path, I (accidentally) discovered the "missing link&quo= t;, ES6+'s preservation [2] of the original property ordering which in = my mind is quite logical [3] for "ordinary" JSON usage as well.
A Java based reference implementation has been successfully tested against = Chrome, Node.js, Firefox and Safari.

Feel free taking a test ride on: https://mobilepki.org/jose-jcs/home
Note that it outlaws signing a JSON "Number" expressed as "1= .0" since the correct (according to ES6+) representation is "1&qu= ot;.

Anders

1] possibly with the exception of "unpaired surrogate code points"= ; which I admittedly know zilch about
2] with properties named as integers as a for practical purposes insignific= ant exception
3] Making data come out in the order it was specified addresses human aspec= ts like debugging and documentation of JSON data

--001a11444aecf038100561e27e11-- From nobody Wed Jan 3 21:35:44 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BAC1243F6 for ; Wed, 3 Jan 2018 21:35:42 -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 CcnWtZPvIs9K for ; Wed, 3 Jan 2018 21:35:40 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 55FB412426E for ; Wed, 3 Jan 2018 21:35:40 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id b141so1342153wme.1 for ; Wed, 03 Jan 2018 21:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Bx8cBKBkGhmrBYAF4NTtPeg5KdErtOTR9d1G6I3wCqY=; b=hsRVE/MIhhk2AFg+7r45/w/2Z6RkocBPj9jX/d3twxt8NZViEX1kw53RqVZvb4ya9E DGF2njU1Nu56bm6Q78pZGTktThll48x2DYFZfdRlsl3AHecKuyFILanUBW4LKrhLwkCy 6cKF7BH8WjEhH164fG4GPDr7wa3vL4cdCfYjIkIsyjIvcTfSKIK8OM87X8II8COyVNEw mrtpP3mN6K8xLszkXRgiVGlIPLupzZLZQwGVkhmhMUskpR9S8+Hyk4XW22TOIlWIV6rH HlgwTXfgZeIT3mdM1RQ6gXxsLHDd0l529h9PCrcuxHb4WkNNbdUdj9BdFbsXZD8o6MhP 1kZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Bx8cBKBkGhmrBYAF4NTtPeg5KdErtOTR9d1G6I3wCqY=; b=GO/W7fMAdsIm6TJIECVJXVfKqo1zz4UdEJNSJeHzniNlcyqIMoPryUi2Z6wd3tG4v+ N/Amf4eq9P+orDWmigbkbjWEBezOSzk5MwibQi02LxbvCzM42YUE1CN27W/pfwoPmzq7 L0T5kkGnboHNoItwYTzRJvXZXJ5X2CVgur4r5dPmgIQXSLsKMAmd4WgmMrAf9q+PVR9f S4kLI2VI9jA8W6yxtXQH21eAgkIt2ey3xMrtW5dVTIFvBW3fpYS4xyEEsnbJEGV7ZxGJ t28SxSSSMMx2YHbAQRsZ/s6kSa8CSdmQL3UZPfcfR6RpAlpidL4enMHHCZeoNqjdPUAE yWxw== X-Gm-Message-State: AKGB3mIyR1QAcXokBTK/hw/QkpGRCM5dHaSGkbs93fML748lxjL/MwLd Ce0fk118rcZ2uRcmPoLQqnVMDA== X-Google-Smtp-Source: ACJfBot67c20xkxKvTBtDRMmhZeg+gmc8xtKCjHwaC1Khz9FotdA/ymJPTZT5TdjDftxXmDsn6kr5A== X-Received: by 10.80.135.86 with SMTP id 22mr5595327edv.266.1515044137669; Wed, 03 Jan 2018 21:35:37 -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 33sm1454421edt.57.2018.01.03.21.35.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jan 2018 21:35:36 -0800 (PST) From: Anders Rundgren To: Richard Gibson Cc: JSON WG References: <13860352-ef8e-1d4b-2eff-27e275c25e3a@gmail.com> <92077f95-5dd6-3f5b-4765-d14067f698ac@dret.net> <15337fea-5cec-0306-939b-df40b3a367d6@gmail.com> Message-ID: Date: Thu, 4 Jan 2018 06:35:37 +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: 8bit 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: Thu, 04 Jan 2018 05:35:43 -0000 Dear Richard, I'm in no way against an RFC for canonical JSON. On the contrary, I whish you luck with your JSON canonicalization endeavors! There is no real disconnect, there is a difference in opinion of what is [most] important. In my opinion a cross-platform system based on JSON messaging MUST consider the limitations in both ECMAScript JSON processing and in JSON itself. The latter are quite severe and every now and then cause people starting new projects to "fix JSON" like: https://www.tjson.org/ Creating a signature scheme relying on ECMAScript JSON processing rules may indeed be regarded as a short-cut, but availability typically trumps perfection. Anders On 2018-01-03 18:25, Richard Gibson wrote: > I'm really not sure where the disconnect between us is coming from... JSON specifies unordered keys for objects, arbitrary-precision numbers, and strings that can contain code points excluded from UTF-8. As such, ECMAScript JSON.stringify is *not* suitable for JSON canonicalization, though it may suffice for certain Javascript-centric or otherwise restricted subsets thereof as addressed by JOSE. I believe that a general solution like http://gibson042.github.io/canonicaljson-spec/ is needed to avoid this seemingly endless series of special cases [1] [2] [3] [etc] (including those that have nothing to do with cryptographic signatures or encryption), and therefore wish to work towards an RFC describing it. There's no problem if you're uninterested, or even if you believe that a general solution is unwarranted, but there _is_ a problem if you believe that JSON.stringify already provides one. > > [1]: https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00 > [2]: https://tools.ietf.org/html/rfc7638#section-3.3 > [3]: https://keybase.io/docs/api/1.0/canonical_packings#json > [etc]: http://wiki.laptop.org/go/Canonical_JSON > > On Wed, Jan 3, 2018 at 2:06 AM, Anders Rundgren > wrote: > > On 2018-01-02 17:33, Richard Gibson wrote: > > > > JSON.stringify assumes information that is explicitly not conveyed by JSON (in which an object is "an unordered collection of zero or more name/value pairs") [1], and both its number serialization [2] > and string serialization [3] specify aspects that harm compatibility > (the former having arbitrary value-dependent branches, the latter being > capable of producing invalid UTF-8 octet sequences that represent unpaired > surrogate code points—unacceptable for exchange outside of a closed > ecosystem [4]). JSON is a general language-agnostic interchange format, > and ECMAScript JSON.stringify is *not* a JSON canonicalization solution. > > [1]: https://tools.ietf.org/html/rfc8259#section-1 > [2]: http://ecma-international.org/ecma-262/7.0/#sec-tostring-applied-to-the-number-type > [3]: http://ecma-international.org/ecma-262/7.0/#sec-quotejsonstring > [4]: https://tools.ietf.org/html/rfc8259#section-8.1 > > > JSON is a format defined the IETF and ECMA in some kind of cooperation. > > ECMA's ECMAScript defines a set of ("fairly" easy to implement) JSON processing rules which are fully compatible [1] with the JSON format. > > The idea using ES6+ number normalization was originally proposed by an esteemed member of the now concluded JOSE WG: > https://www.ietf.org/mail-archive/web/jose/current/msg05323.html > > Following that path, I (accidentally) discovered the "missing link", ES6+'s preservation [2] of the original property ordering which in my mind is quite logical [3] for "ordinary" JSON usage as well. > > A Java based reference implementation has been successfully tested against Chrome, Node.js, Firefox and Safari. > > Feel free taking a test ride on: https://mobilepki.org/jose-jcs/home > Note that it outlaws signing a JSON "Number" expressed as "1.0" since the correct (according to ES6+) representation is "1". > > Anders > > 1] possibly with the exception of "unpaired surrogate code points" which I admittedly know zilch about > 2] with properties named as integers as a for practical purposes insignificant exception > 3] Making data come out in the order it was specified addresses human aspects like debugging and documentation of JSON data > > From nobody Fri Jan 12 13:58:46 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BB812D830 for ; Fri, 12 Jan 2018 13:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 AZU3ugqScZRN for ; Fri, 12 Jan 2018 13:58:31 -0800 (PST) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 1F76212D852 for ; Fri, 12 Jan 2018 13:58:30 -0800 (PST) Received: by mail-oi0-x244.google.com with SMTP id u83so4868372oie.7 for ; Fri, 12 Jan 2018 13:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1PK06wuvbDcprMlh6knBbECUB191xmnUlxeALEUqWW8=; b=n3NgJpdlCyy09K4KMRiRzQ1eog1dXrFkZyPCSiqHhSTf7ePQkp0T9vrKOxILvbhfIA wx2i2+WGGntuxpJADSRFoSQS2LYpCNORAp720AR8IsupgOdCiYH0bj8WBNF41UoEXMvl R+WnIXgr/z/sD8mxFvUhUUGm1B6GFAq58mT9FHOEf52fRqV3hYwSI4HGJUvt+QcULJhA mHHXVmWjfFcknsP+3QVwdVqzJdYfzXAMQ3tHckNVOIHdAXdnYlpfMC/PJw+1qtBb5BAI pxtqOUdFT67aYfUJ5MtwyOc0zxSWKf9lht0m+kCNQm8uUK5TyFBE+dHkvbeOw/ijPtzI JDzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1PK06wuvbDcprMlh6knBbECUB191xmnUlxeALEUqWW8=; b=WUl7/PywLhfWzoVgDD1bNemWqQg3XjYeAO+4HdIkrLJJP5hPCTD9Dwp+gaQblF8inX e0JioAbhH2qTEacS3GIOpH3Op/xlmZKx5bmrm0/3H0ozO/6KC0hSpFkfNLxL2N7nFToa 2/BDGjZDNKfAiZXjkOL+9Okg6xcdKeCL+6cjuFmBp57OsTio+NPgtMhwuijpLZOqKa5j EPluW5lr4sm6FzGaDPyve66I2rMgQQhinv8atiUVRk3UKJXmSACC8lt5Jy421fX7e2oQ UGh25emhExQFvRUHxl3+uhQjU6rVGiA0S2XFwszduwDZQ8n2KEh2JyEybmmrF3/Qbi30 qg3Q== X-Gm-Message-State: AKwxytdvkLwnKMVE9DUDU1v2UJ9vaAW4bZ9sOpgArMksqobHQr4vMu0U 4GMK7MXRrocFl20/hxsywplvG8AeukUcTssbX1mkGw== X-Google-Smtp-Source: ACJfBos+6xSSr+/P06xAwLm44ailbXGGtTmICo75+ElXe1G5+vPZdKZzsYEjSZtyjjrY4WVvxqkHN1rCa6nvVFP6HHk= X-Received: by 10.202.79.199 with SMTP id d190mr4002620oib.98.1515794309296; Fri, 12 Jan 2018 13:58:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.56.185 with HTTP; Fri, 12 Jan 2018 13:58:28 -0800 (PST) Received: by 10.157.56.185 with HTTP; Fri, 12 Jan 2018 13:58:28 -0800 (PST) From: Crandall Navy Date: Fri, 12 Jan 2018 13:58:28 -0800 Message-ID: To: json@ietf.org Content-Type: multipart/alternative; boundary="001a113d84ea5bb89f05629b5dba" Archived-At: Subject: [Json] 1. Corrected Announcement: STD 90, RFC 8259 on The JavaScript Object Notation (JSON) Data Interchange Format (rfc-editor@rfc-editor.org) 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: Fri, 12 Jan 2018 21:58:36 -0000 --001a113d84ea5bb89f05629b5dba Content-Type: text/plain; charset="UTF-8" --001a113d84ea5bb89f05629b5dba Content-Type: text/html; charset="UTF-8"
--001a113d84ea5bb89f05629b5dba-- From nobody Sat Jan 20 13:25:51 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C5E127735 for ; Sat, 20 Jan 2018 13:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHEuZthjHeZW for ; Sat, 20 Jan 2018 13:25:47 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D84C128C0A for ; Sat, 20 Jan 2018 13:25:47 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id z48so4644350wrz.6 for ; Sat, 20 Jan 2018 13:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=mndAywPXyMC6/9dfp/R0zku9zw9PthPYQshNoZCoYJs=; b=x+Gp1lU0oG36RaDthmMAwGGSRFUMLzMw2FJdJU+2EWP7bdSfB/GSM+HierC+OH4Nmw SHo/jwdWhZGa/a5ravdLx/YgRpTmbwY1E94cWgcPzQYSwgTbtunz8l2BmT1MWZ+dHhyj 3S4/dj2SDiwLx71DWw6Pjo5jqcTniS/20VCp4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=mndAywPXyMC6/9dfp/R0zku9zw9PthPYQshNoZCoYJs=; b=llXhggMFgpkjxRcbsIuu07W2EEYcRIddFB7XVInPcX5d/acflvDHgRk/m/AvL0Me1c f+/dmYwOkf8zTonaupN/QJjruQmEJUSVHoUPK14mVvKQB1P4uXQypnr+jxMdPbUPXxg+ EDpfErt14Bf/96OzgY+hk9NyuoPYyxBqA66D3cFrOAH1B4wm/d/PKzkdYJvuC27hhEK5 sjTb94M96KtXCvEuWDAVvK7RVG9eVJf4LmPGiF54BTB6C23ivlvEFZUfGNhudc2UDJ0N Sy35HSqLuysWpv4PLo4rVFn1UyAY4hjvcvX+D30kHDCNo1Y77583Se6xcNAe2TKXCEEx rJvw== X-Gm-Message-State: AKwxytdvB+5Sc6/3CMI+K1KeiWTLNHvKGiXHOg8kdvyVz6N/gjjS/680 z12VCiTGlXklSkLl0yY8qcoCbLrl/wNtMXHw3SAsrGyQ/w0= X-Google-Smtp-Source: AH8x224hq5dXuSr8Bxsqe9/eYFrg1pUSwMtSkFQZkqd3ud/vK75E4jDjaRF76BMFqEZVYD5IcWAszyh1tOsIGiKDMAo= X-Received: by 10.223.177.196 with SMTP id r4mr2130360wra.244.1516483545405; Sat, 20 Jan 2018 13:25:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.4 with HTTP; Sat, 20 Jan 2018 13:25:24 -0800 (PST) From: Henry Andrews Date: Sat, 20 Jan 2018 13:25:24 -0800 Message-ID: To: json@ietf.org Cc: Austin William Wright , Ben Hutton Content-Type: multipart/alternative; boundary="f403045ed022082ed205633bd7ea" Archived-At: Subject: [Json] JSON Schema 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, 20 Jan 2018 21:25:50 -0000 --f403045ed022082ed205633bd7ea Content-Type: text/plain; charset="UTF-8" Hi folks, I'm one of the JSON Schema draft editors, and it's been brought to our attention that the JSON Schema project may fit within this working group (or a successor? I'm a little confused as to the current status and scope of this group). We are definitely interested in having the project adopted by an IETF working group and eventually reaching RFC status if possible. To date we have not felt like the project is quite ready for that step, although I don't personally have a good feel for the criteria. Since October 2016, Austin Wright and I, with a great deal of behind-the-scenes help from Ben Hutton and others, have published three drafts of JSON Schema Core and Validation, four of Hyper-Schema, and two of Relative JSON Pointer. We are actively working on the next Core and Validation drafts right now. In addition to the obvious JSON Schema community engagement, we are also working directly with the Open API technical steering committee to resolve the problems that led them to adopt an almost-but-not-quite-compatible form of JSON Schema. I feel like they are a good proxy for general adoption problems as they have a large community of their own, and their concerns arise from common use cases that are not quite well-served at this time (particularly code generation). We've also engaged a bit with folks using JSON-LD who want to figure out how to leverage both, although that idea is very embryonic at this time. We're currently working on resolving some major questions of scope for the project overall and the Core and Validation specifications in particular (a lot of it related to how use cases such as code generation fit with the existing targeted use cases). I hope to resolve these in the next major draft before the current ones expire. There may be a minor bug-fix in the next week or so, separate from that effort, and one additional scope question may be deferred to another draft beyond that. Once the scope is settled, I had planned to actively look into working group status for the core and validation specifications. Hyper-Schema requires more work and at least a few viable implementations. Relative JSON Pointer could probably move to working group status as well if it is of interest (we've also considered merging it into JSON Schema Core if there is no interest in it as its own RFC: JSON Path is not a good fit for our needs despite being a great idea in its own right, and we already make extensive use of JSON Pointer). I believe that the ongoing broad use and implementation of JSON Schema despite a multi-year abandonment of the draft work shows that it is a very viable and useful technology despite the complaints around the edges (I noticed that the complaint on this mailing list from 2016 was also about code generation- as I mentioned, that's a current focus of ours to resolve). We've started to see implementations of the new drafts in use, and interest in the latest draft picked up even more quickly than the one before, so there seems to be real interest in taking JSON Schema over the finish line into some sort of official standard. The current team is committed to seeing this through. The recent change in submitting editor is just a reflection of who had the most time; the core team members have all remained involved since draft publication resumed. I'm interested in any feedback or suggestions on the path forward. thanks, -henry -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --f403045ed022082ed205633bd7ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,
=C2=A0 I'm one = of the JSON Schema draft editors, and it's been brought to our attentio= n that the JSON Schema project may fit within this working group (or a succ= essor?=C2=A0 I'm a little confused as to the current status and scope o= f this group).=C2=A0 We are definitely interested in having the project ado= pted by an IETF working group and eventually reaching RFC status if possibl= e.

=C2=A0 To date we have not felt like the project is quite r= eady for that step, although I don't personally have a good feel for th= e criteria.=C2=A0 Since October 2016, Austin Wright and I, with a great dea= l of behind-the-scenes help from Ben Hutton and others, have published thre= e drafts of JSON Schema Core and Validation, four of Hyper-Schema, and two = of Relative JSON Pointer.=C2=A0 We are actively working on the next Core an= d Validation drafts right now.

=C2=A0 In addit= ion to the obvious JSON Schema community engagement, we are also working di= rectly with the Open API technical steering committee to resolve the proble= ms that led them to adopt an almost-but-not-quite-compatible form of JSON S= chema.=C2=A0 I feel like they are a good proxy for general adoption problem= s as they have a large community of their own, and their concerns arise fro= m common use cases that are not quite well-served at this time (particularl= y code generation).=C2=A0 We've also engaged a bit with folks using JSO= N-LD who want to figure out how to leverage both, although that idea is ver= y embryonic at this time.

=C2=A0 We're currentl= y working on resolving some major questions of scope for the project overal= l and the Core and Validation specifications in particular (a lot of it rel= ated to how use cases such as code generation fit with the existing targete= d use cases).=C2=A0 I hope to resolve these in the next major draft before = the current ones expire.=C2=A0 There may be a minor bug-fix in the next wee= k or so, separate from that effort, and one additional scope question may b= e deferred to another draft beyond that.

=C2=A0 Once the scope= is settled, I had planned to actively look into working group status for t= he core and validation specifications.=C2=A0 Hyper-Schema requires more wor= k and at least a few viable implementations.=C2=A0 Relative JSON Pointer co= uld probably move to working group status as well if it is of interest (we&= #39;ve also considered merging it into JSON Schema Core if there is no inte= rest in it as its own RFC: JSON Path is not a good fit for our needs despit= e being a great idea in its own right, and we already make extensive use of= JSON Pointer).

=C2=A0 I believe that the ongoing broad use and implementation of J= SON Schema despite a multi-year abandonment of the draft work shows that it= is a very viable and useful technology despite the complaints around the e= dges (I noticed that the complaint on this mailing list from 2016 was also = about code generation- as I mentioned, that's a current focus of ours t= o resolve).=C2=A0 We've started to see implementations of the new draft= s in use, and=20 interest in the latest draft picked up even more quickly than the one=20 before, so there seems to be real interest in taking JSON Schema over=20 the finish line into some sort of official standard. The current team is co= mmitted to seeing this through. The recent change in submitting editor is j= ust a reflection of who had the most time; the core team members have all r= emained involved since draft publication resumed.

<= div>=C2=A0 I'm interested in any feedback or suggestions on the path fo= rward.

thanks,
-henry
--
  • <= p style=3D"font-family:Helvetica;font-size:12px;color:rgb(64,64,64)">Hen= ry Andrews=C2=A0=C2=A0|=C2=A0=C2=A0Systems Engineer
    h= enry@cloudflare.com

    1 888 9= 9 FLARE=C2=A0=C2=A0|=C2=A0=C2=A0www.cloudflare.com

  • <= /ul>
--f403045ed022082ed205633bd7ea-- From nobody Sat Jan 20 13:50:21 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F2F127869 for ; Sat, 20 Jan 2018 13:50:19 -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 bKAqzeAKsxLu for ; Sat, 20 Jan 2018 13:50:17 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2391127735 for ; Sat, 20 Jan 2018 13:50:16 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id v123so9902339wmd.5 for ; Sat, 20 Jan 2018 13:50:16 -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=cUmJHQ2KURBXnLOQE44LfOVWO0qLMkW3jsW8QSOEldY=; b=WNb1wEQlzKTY3V3Rg8NrbDFtdx2e/Hs2fONmnenQ9VX6ehCqdfanakU4mvpsJxHBVM 32AtahEkklJFrBZnvY+f6jQKx6PRknDTHhoC+cw1BCRXK//GsSiFZgnZkgLoEKRXPtJ0 yzKUYK+4RPZWso8ydPUmKAcD6AUtR5DcmHBjOXvMS1wNanHlmcaZbJM22n6hlz/24MZA pwOu1Rvz72eRQFiIoW5CEd8+SvVYLCIolHYLH/fzXgZ1BbKnHOM6LI2luFh8/vDwtupz lBZYIzs29NCpl7KI3vNkxkdz47WH0IOROMfgQZGs7WdC4YCk7QpQAj/ZXDiSvAIWd4R8 Gw7Q== 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=cUmJHQ2KURBXnLOQE44LfOVWO0qLMkW3jsW8QSOEldY=; b=sXjxpH9jssLqLhruJepdC+C8BEa9VCHozrh7mWWhtTNDOzpRnnbsfiftDa0FpOyafW qg4mywEjHJLl4KJBrZb9Ruvm7R64eqbK161+YIcfo0OFte5mhdbe3P0lIXR8d5SBot7j G1i0dIQFjwHIv6DfzZWh3+vv6d31EMelMEUziiW2oegjCgtWm/jip9o3GqUMKUUT5zYW 2gc7Tv9yeKUxuVUfQaqgnNGiFLPd+qzs5FCbYNVLVVLq+nGYWxjJEo1gA/cMSIpKdKqT sl6EIJaCF/ED/H7ohMp3VkzjTTCvU6DxyeNzyg7s+QZf1+tPCus0ShgO3uPJZtWRoa+U QEjQ== X-Gm-Message-State: AKwxyteRbZPkXEuJRhBdTukisFycJb7CmOX1PiQlcoUkAFhLdqefeiL9 PUflQNQ1blyPXuauD8QW5Firyi6LHRBQ2GjAlveYLJ9YWfI= X-Google-Smtp-Source: AH8x224ID9GREy0SB5vP/ZXwHUix5DZ3/PIG5XIGYBuNe+OC5NvXoOplS0/EjnC+8+DPlHhwwTIHhgSZD5nARp5lqD0= X-Received: by 10.80.154.225 with SMTP id p88mr5551775edb.256.1516485014934; Sat, 20 Jan 2018 13:50:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.245.149 with HTTP; Sat, 20 Jan 2018 13:49:54 -0800 (PST) X-Originating-IP: [174.6.224.108] In-Reply-To: References: From: Tim Bray Date: Sat, 20 Jan 2018 13:49:54 -0800 Message-ID: To: Henry Andrews Cc: json@ietf.org, Austin William Wright , Ben Hutton Content-Type: multipart/alternative; boundary="f403045c2a149f714905633c2e41" Archived-At: Subject: Re: [Json] JSON Schema 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, 20 Jan 2018 21:50:20 -0000 --f403045c2a149f714905633c2e41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could you give pointers to current drafts? I had a horrible experience with JSON Schema (V2 I think? Whatever's current implemented) - the implementations were inconsistent with each other, the error messages out of the validators were simultaneously verbose and unhelpful, and I was looking at it trying to figure how I'd get better-quality messages, it seemed sort of intrinsically difficult. I would want to see existence proof of a validator that produced high-quality error messages before I could really get behind a design. I ended up writing my own schema language to produce a user-friendly validator, but it's on the eccentric side and I doubt of interest to the broader community: https://www.tbray.org/ongoing/When/201x/2016/12/01/J2119-Validator Having said that, I think work on a schema language for JSON might be welcomed in the IETF, given a good draft to start with and an editor or editors who were interested in doing things the IETF way. It's not that lightweight, we'd have to re-charter the working group, but far from impossible. On Sat, Jan 20, 2018 at 1:25 PM, Henry Andrews wrote= : > Hi folks, > I'm one of the JSON Schema draft editors, and it's been brought to our > attention that the JSON Schema project may fit within this working group > (or a successor? I'm a little confused as to the current status and scop= e > of this group). We are definitely interested in having the project adopt= ed > by an IETF working group and eventually reaching RFC status if possible. > > To date we have not felt like the project is quite ready for that step, > although I don't personally have a good feel for the criteria. Since > October 2016, Austin Wright and I, with a great deal of behind-the-scenes > help from Ben Hutton and others, have published three drafts of JSON Sche= ma > Core and Validation, four of Hyper-Schema, and two of Relative JSON > Pointer. We are actively working on the next Core and Validation drafts > right now. > > In addition to the obvious JSON Schema community engagement, we are als= o > working directly with the Open API technical steering committee to resolv= e > the problems that led them to adopt an almost-but-not-quite-compatible > form of JSON Schema. I feel like they are a good proxy for general > adoption problems as they have a large community of their own, and their > concerns arise from common use cases that are not quite well-served at th= is > time (particularly code generation). We've also engaged a bit with folks > using JSON-LD who want to figure out how to leverage both, although that > idea is very embryonic at this time. > > We're currently working on resolving some major questions of scope for > the project overall and the Core and Validation specifications in > particular (a lot of it related to how use cases such as code generation > fit with the existing targeted use cases). I hope to resolve these in th= e > next major draft before the current ones expire. There may be a minor > bug-fix in the next week or so, separate from that effort, and one > additional scope question may be deferred to another draft beyond that. > > Once the scope is settled, I had planned to actively look into working > group status for the core and validation specifications. Hyper-Schema > requires more work and at least a few viable implementations. Relative > JSON Pointer could probably move to working group status as well if it is > of interest (we've also considered merging it into JSON Schema Core if > there is no interest in it as its own RFC: JSON Path is not a good fit fo= r > our needs despite being a great idea in its own right, and we already mak= e > extensive use of JSON Pointer). > > I believe that the ongoing broad use and implementation of JSON Schema > despite a multi-year abandonment of the draft work shows that it is a ver= y > viable and useful technology despite the complaints around the edges (I > noticed that the complaint on this mailing list from 2016 was also about > code generation- as I mentioned, that's a current focus of ours to > resolve). We've started to see implementations of the new drafts in use, > and interest in the latest draft picked up even more quickly than the one > before, so there seems to be real interest in taking JSON Schema over the > finish line into some sort of official standard. The current team is > committed to seeing this through. The recent change in submitting editor = is > just a reflection of who had the most time; the core team members have al= l > remained involved since draft publication resumed. > > I'm interested in any feedback or suggestions on the path forward. > > thanks, > -henry > > -- > > - > > *Henry Andrews* | Systems Engineer > henry@cloudflare.com > > > 1 888 99 FLARE | www.cloudflare.com > - > > > _______________________________________________ > 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) --f403045c2a149f714905633c2e41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Cou= ld you give pointers to current drafts?=C2=A0 I had a horrible experience w= ith JSON Schema (V2 I think? Whatever's current implemented) - the impl= ementations were inconsistent with each other, the error messages out of th= e validators were simultaneously verbose and unhelpful, and I was looking a= t it trying to figure how I'd get better-quality messages, it seemed so= rt of intrinsically difficult. I would want to see existence proof of a val= idator that produced high-quality error messages before I could really get = behind a design.

I ended = up writing my own schema language to produce a user-friendly validator, but= it's on the eccentric side and I doubt of interest to the broader comm= unity:=C2=A0https://www.tbray.org/ongoing/When/201x/2016/12/01/J2119-Va= lidator
Having said t= hat, I think work on a schema language for JSON might be welcomed in the IE= TF, given a good draft to start with and an editor or editors who were inte= rested in doing things the IETF way.=C2=A0 It's not that lightweight, w= e'd have to re-charter the working group, but far from impossible.

On Sat, Ja= n 20, 2018 at 1:25 PM, Henry Andrews <henry@cloudflare.com> wrote:
Hi folks,
=C2=A0 I'm one of the JSON Schema draft editor= s, and it's been brought to our attention that the JSON Schema project = may fit within this working group (or a successor?=C2=A0 I'm a little c= onfused as to the current status and scope of this group).=C2=A0 We are def= initely interested in having the project adopted by an IETF working group a= nd eventually reaching RFC status if possible.

=C2=A0 To date = we have not felt like the project is quite ready for that step, although I = don't personally have a good feel for the criteria.=C2=A0 Since October= 2016, Austin Wright and I, with a great deal of behind-the-scenes help fro= m Ben Hutton and others, have published three drafts of JSON Schema Core an= d Validation, four of Hyper-Schema, and two of Relative JSON Pointer.=C2=A0= We are actively working on the next Core and Validation drafts right now.<= br>

=C2=A0 In addition to the obvious JSON Schema = community engagement, we are also working directly with the Open API techni= cal steering committee to resolve the problems that led them to adopt an al= most-but-not-quite-compatible form of JSON Schema.=C2=A0 I feel like t= hey are a good proxy for general adoption problems as they have a large com= munity of their own, and their concerns arise from common use cases that ar= e not quite well-served at this time (particularly code generation).=C2=A0 = We've also engaged a bit with folks using JSON-LD who want to figure ou= t how to leverage both, although that idea is very embryonic at this time.<= br>

=C2=A0 We're currently working on resolving som= e major questions of scope for the project overall and the Core and Validat= ion specifications in particular (a lot of it related to how use cases such= as code generation fit with the existing targeted use cases).=C2=A0 I hope= to resolve these in the next major draft before the current ones expire.= =C2=A0 There may be a minor bug-fix in the next week or so, separate from t= hat effort, and one additional scope question may be deferred to another dr= aft beyond that.

=C2=A0 Once the scope is settled, I had plann= ed to actively look into working group status for the core and validation s= pecifications.=C2=A0 Hyper-Schema requires more work and at least a few via= ble implementations.=C2=A0 Relative JSON Pointer could probably move to wor= king group status as well if it is of interest (we've also considered m= erging it into JSON Schema Core if there is no interest in it as its own RF= C: JSON Path is not a good fit for our needs despite being a great idea in = its own right, and we already make extensive use of JSON Pointer).

=C2=A0 I believe= that the ongoing broad use and implementation of JSON Schema despite a mul= ti-year abandonment of the draft work shows that it is a very viable and us= eful technology despite the complaints around the edges (I noticed that the= complaint on this mailing list from 2016 was also about code generation- a= s I mentioned, that's a current focus of ours to resolve).=C2=A0 We'= ;ve started to see implementations of the new drafts in use, and=20 interest in the latest draft picked up even more quickly than the one=20 before, so there seems to be real interest in taking JSON Schema over=20 the finish line into some sort of official standard. The current team is co= mmitted to seeing this through. The recent change in submitting editor is j= ust a reflection of who had the most time; the core team members have all r= emained involved since draft publication resumed.

<= div>=C2=A0 I'm interested in any feedback or suggestions on the path fo= rward.

thanks,
-henry

--
<= /div>

_______________________________________________
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)
--f403045c2a149f714905633c2e41-- From nobody Sat Jan 20 14:13:34 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AE612421A for ; Sat, 20 Jan 2018 14:13:30 -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, 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 (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFNnL8nIXJKq for ; Sat, 20 Jan 2018 14:13:26 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FEF1242F5 for ; Sat, 20 Jan 2018 14:13:26 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id b21so9977912wme.4 for ; Sat, 20 Jan 2018 14:13:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RLXurAo20PmrIQQxa4AbOBG52He+u8Def154vSPuR0I=; b=qfHc8Rc9EW2xqkP3gw3esetl1ieHZ7p0hu05zIr/8+Y6oq9HfH/6EGWTLa+MF05NvX Y3Fx269oolg/7b4QoZOtbAiUxyULu3n1ujBZ/8xlyWsnoLOBEfpulpvpcg+ZvEXnOLeD CgrOETJUk7APHJ/U2CNo0OCFByGCKtTuRoV8Q= 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=RLXurAo20PmrIQQxa4AbOBG52He+u8Def154vSPuR0I=; b=kU5BhO4jmSJXHSnmssCy4PBAWd6QUXO6i+d10D7DoHvOv9x4MqwrfqFEulrfnEO8Fh iwxGT5+20dUXEz2H0Ewil56nTVbPn5INgt6JV8PezvqIYGGJK+iWMGtuu+MErJfXfnlu znn4PjUyM7EXJrZQ0H+zSoPljRUm7rUKXzERB3uJG5aW+GbqxKuDEsaY2hbSuXJO26aw cl8EpaME1/i9u5lvt3Q84MSsZXfimprt/JHyNcNndrX462gXwNv4Jii5yYMC1IfKhCyA C14mBqHi0xCBQqVdcseAbnINbbH9nRb6taSJBYB+bqVdvtcmWbOuMeRcDEL3hkzGIYCt gj/w== X-Gm-Message-State: AKwxyteEjvu3BK2vUulktht4fqhUVFISLGj7o4h2P3CUEYF7st3VIiRr Si/K3mtKWYOiOTKv3RhgOlyVn8XhfgMi2eIPVFwtew== X-Google-Smtp-Source: AH8x2268BY9D+xwpuCYcnBowPtS0wb6wWdZiRpECxhtQGiFlH1TstoRUUFiutbB39wth5U5FQ408oxPOa5Lxokr74Mo= X-Received: by 10.28.111.11 with SMTP id k11mr1841934wmc.119.1516486404825; Sat, 20 Jan 2018 14:13:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.4 with HTTP; Sat, 20 Jan 2018 14:13:04 -0800 (PST) In-Reply-To: References: From: Henry Andrews Date: Sat, 20 Jan 2018 14:13:04 -0800 Message-ID: To: Tim Bray Cc: json@ietf.org, Austin William Wright , Ben Hutton Content-Type: multipart/alternative; boundary="001a1147c446777b9805633c818d" Archived-At: Subject: Re: [Json] JSON Schema 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, 20 Jan 2018 22:13:33 -0000 --001a1147c446777b9805633c818d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tim, The current draft is draft-07 (although the actual IETF numbering is complicated). So draft-02 was a very long time ago :-) You can find links to nice HTML renderings of all of the drafts, as well as links to the official ietf.org hosted renderings, on our site at http://json-schema.org/ (yes, we know we need to move to HTTPS, there's a long difficult story there that is finally showing signs of resolution). You will also find some guides to migrating to recent drafts and a bit of explanation of the history, although we could use more/improved content on those topics. You will also find links to implementations, with notes about which drafts are supported- draft-06 (April 2017) has been implemented in several languages, and we're starting to see a few draft-07 (November 2017) implementations as well. For discussions of improving or standardizing output (error or otherwise), follow the "output" tag on the GitHub issues: https://github.com/json-schema-org/json-schema-spec/issues?q=3Dis%3Aissue+i= s%3Aopen+label%3Aoutput While not an immediate focus, it is obviously on the list of concerns. In my view it is the responsibility of the spec to ensure that it is *possible* to provide good output, but the fact that some implementation fails to do so despite the possibility is not a reason to drop the spec. Note that for the common complaint of difficult error messages with "oneOf", we introduced "if"/"then"/"else" keywords in draft-07 (after extensive debate as to whether they were "too imperative"- in the end the community demand was extremely high, and the capabilities are no different than with "oneOf", it's just easier to read and report errors with "if"/"then"/"else" in many use cases). thanks, -henry On Sat, Jan 20, 2018 at 1:49 PM, Tim Bray wrote: > Could you give pointers to current drafts? I had a horrible experience > with JSON Schema (V2 I think? Whatever's current implemented) - the > implementations were inconsistent with each other, the error messages out > of the validators were simultaneously verbose and unhelpful, and I was > looking at it trying to figure how I'd get better-quality messages, it > seemed sort of intrinsically difficult. I would want to see existence pro= of > of a validator that produced high-quality error messages before I could > really get behind a design. > > I ended up writing my own schema language to produce a user-friendly > validator, but it's on the eccentric side and I doubt of interest to the > broader community: https://www.tbray.org/ongoing/When/201x/2016/12/ > 01/J2119-Validator > > Having said that, I think work on a schema language for JSON might be > welcomed in the IETF, given a good draft to start with and an editor or > editors who were interested in doing things the IETF way. It's not that > lightweight, we'd have to re-charter the working group, but far from > impossible. > > On Sat, Jan 20, 2018 at 1:25 PM, Henry Andrews > wrote: > >> Hi folks, >> I'm one of the JSON Schema draft editors, and it's been brought to our >> attention that the JSON Schema project may fit within this working group >> (or a successor? I'm a little confused as to the current status and sco= pe >> of this group). We are definitely interested in having the project adop= ted >> by an IETF working group and eventually reaching RFC status if possible. >> >> To date we have not felt like the project is quite ready for that step= , >> although I don't personally have a good feel for the criteria. Since >> October 2016, Austin Wright and I, with a great deal of behind-the-scene= s >> help from Ben Hutton and others, have published three drafts of JSON Sch= ema >> Core and Validation, four of Hyper-Schema, and two of Relative JSON >> Pointer. We are actively working on the next Core and Validation drafts >> right now. >> >> In addition to the obvious JSON Schema community engagement, we are >> also working directly with the Open API technical steering committee to >> resolve the problems that led them to adopt an >> almost-but-not-quite-compatible form of JSON Schema. I feel like they >> are a good proxy for general adoption problems as they have a large >> community of their own, and their concerns arise from common use cases t= hat >> are not quite well-served at this time (particularly code generation). >> We've also engaged a bit with folks using JSON-LD who want to figure out >> how to leverage both, although that idea is very embryonic at this time. >> >> We're currently working on resolving some major questions of scope for >> the project overall and the Core and Validation specifications in >> particular (a lot of it related to how use cases such as code generation >> fit with the existing targeted use cases). I hope to resolve these in t= he >> next major draft before the current ones expire. There may be a minor >> bug-fix in the next week or so, separate from that effort, and one >> additional scope question may be deferred to another draft beyond that. >> >> Once the scope is settled, I had planned to actively look into working >> group status for the core and validation specifications. Hyper-Schema >> requires more work and at least a few viable implementations. Relative >> JSON Pointer could probably move to working group status as well if it i= s >> of interest (we've also considered merging it into JSON Schema Core if >> there is no interest in it as its own RFC: JSON Path is not a good fit f= or >> our needs despite being a great idea in its own right, and we already ma= ke >> extensive use of JSON Pointer). >> >> I believe that the ongoing broad use and implementation of JSON Schema >> despite a multi-year abandonment of the draft work shows that it is a ve= ry >> viable and useful technology despite the complaints around the edges (I >> noticed that the complaint on this mailing list from 2016 was also about >> code generation- as I mentioned, that's a current focus of ours to >> resolve). We've started to see implementations of the new drafts in use= , >> and interest in the latest draft picked up even more quickly than the on= e >> before, so there seems to be real interest in taking JSON Schema over th= e >> finish line into some sort of official standard. The current team is >> committed to seeing this through. The recent change in submitting editor= is >> just a reflection of who had the most time; the core team members have a= ll >> remained involved since draft publication resumed. >> >> I'm interested in any feedback or suggestions on the path forward. >> >> thanks, >> -henry >> >> -- >> >> - >> >> *Henry Andrews* | Systems Engineer >> henry@cloudflare.com >> >> >> 1 888 99 FLARE | www.cloudflare.com >> - >> >> >> _______________________________________________ >> 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) > --=20 - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --001a1147c446777b9805633c818d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tim,
=C2=A0 The current draft is draft-0= 7 (although the actual IETF numbering is complicated).=C2=A0 So draft-02 wa= s a very long time ago :-)

You can find links = to nice HTML renderings of all of the drafts, as well as links to the offic= ial ietf.org hosted renderings, on our site= at http://json-schema.org/ (yes, w= e know we need to move to HTTPS, there's a long difficult story there t= hat is finally showing signs of resolution).=C2=A0 You will also find some = guides to migrating to recent drafts and a bit of explanation of the histor= y, although we could use more/improved content on those topics.=C2=A0 You w= ill also find links to implementations, with notes about which drafts are s= upported- draft-06 (April 2017) has been implemented in several languages, = and we're starting to see a few draft-07 (November 2017) implementation= s as well.

For discussions of improving or sta= ndardizing output (error or otherwise), follow the "output" tag o= n the GitHub issues: https://github.com= /json-schema-org/json-schema-spec/issues?q=3Dis%3Aissue+is%3Aopen+label%3Ao= utput=C2=A0 While not an immediate focus, it is obviously on the list o= f concerns.=C2=A0 In my view it is the responsibility of the spec to ensure= that it is *possible* to provide good output, but the fact that some imple= mentation fails to do so despite the possibility is not a reason to drop th= e spec.

Note that for the common complaint of diff= icult error messages with "oneOf", we introduced "if"/&= quot;then"/"else" keywords in draft-07 (after extensive deba= te as to whether they were "too imperative"- in the end the commu= nity demand was extremely high, and the capabilities are no different than = with "oneOf", it's just easier to read and report errors with= "if"/"then"/"else" in many use cases).

thanks,
-henry


On Sat, Jan 2= 0, 2018 at 1:49 PM, Tim Bray <tbray@textuality.com> wrote= :
Could you give pointers to current drafts?= =C2=A0 I had a horrible experience with JSON Schema (V2 I think? Whatever&#= 39;s current implemented) - the implementations were inconsistent with each= other, the error messages out of the validators were simultaneously verbos= e and unhelpful, and I was looking at it trying to figure how I'd get b= etter-quality messages, it seemed sort of intrinsically difficult. I would = want to see existence proof of a validator that produced high-quality error= messages before I could really get behind a design.

I ended up writing my own schema language to pr= oduce a user-friendly validator, but it's on the eccentric side and I d= oubt of interest to the broader community:=C2=A0https= ://www.tbray.org/ongoing/When/201x/2016/12/01/J2119-Validator=

Having said that, I thin= k work on a schema language for JSON might be welcomed in the IETF, given a= good draft to start with and an editor or editors who were interested in d= oing things the IETF way.=C2=A0 It's not that lightweight, we'd hav= e to re-charter the working group, but far from impossible.

On Sat, Jan 20, 2018 = at 1:25 PM, Henry Andrews <henry@cloudflare.com> wrote:
Hi fo= lks,
=C2=A0 I'm one of the JSON Schema draft editors, and it&#= 39;s been brought to our attention that the JSON Schema project may fit wit= hin this working group (or a successor?=C2=A0 I'm a little confused as = to the current status and scope of this group).=C2=A0 We are definitely int= erested in having the project adopted by an IETF working group and eventual= ly reaching RFC status if possible.

=C2=A0 To date we have not= felt like the project is quite ready for that step, although I don't p= ersonally have a good feel for the criteria.=C2=A0 Since October 2016, Aust= in Wright and I, with a great deal of behind-the-scenes help from Ben Hutto= n and others, have published three drafts of JSON Schema Core and Validatio= n, four of Hyper-Schema, and two of Relative JSON Pointer.=C2=A0 We are act= ively working on the next Core and Validation drafts right now.

=C2=A0 In addition to the obvious JSON Schema community e= ngagement, we are also working directly with the Open API technical steerin= g committee to resolve the problems that led them to adopt an almost-but-no= t-quite-compatible form of JSON Schema.=C2=A0 I feel like they are a g= ood proxy for general adoption problems as they have a large community of t= heir own, and their concerns arise from common use cases that are not quite= well-served at this time (particularly code generation).=C2=A0 We've a= lso engaged a bit with folks using JSON-LD who want to figure out how to le= verage both, although that idea is very embryonic at this time.

=C2=A0 We're currently working on resolving some major que= stions of scope for the project overall and the Core and Validation specifi= cations in particular (a lot of it related to how use cases such as code ge= neration fit with the existing targeted use cases).=C2=A0 I hope to resolve= these in the next major draft before the current ones expire.=C2=A0 There = may be a minor bug-fix in the next week or so, separate from that effort, a= nd one additional scope question may be deferred to another draft beyond th= at.

=C2=A0 Once the scope is settled, I had planned to activel= y look into working group status for the core and validation specifications= .=C2=A0 Hyper-Schema requires more work and at least a few viable implement= ations.=C2=A0 Relative JSON Pointer could probably move to working group st= atus as well if it is of interest (we've also considered merging it int= o JSON Schema Core if there is no interest in it as its own RFC: JSON Path = is not a good fit for our needs despite being a great idea in its own right= , and we already make extensive use of JSON Pointer).

=C2=A0 I believe that the ong= oing broad use and implementation of JSON Schema despite a multi-year aband= onment of the draft work shows that it is a very viable and useful technolo= gy despite the complaints around the edges (I noticed that the complaint on= this mailing list from 2016 was also about code generation- as I mentioned= , that's a current focus of ours to resolve).=C2=A0 We've started t= o see implementations of the new drafts in use, and=20 interest in the latest draft picked up even more quickly than the one=20 before, so there seems to be real interest in taking JSON Schema over=20 the finish line into some sort of official standard. The current team is co= mmitted to seeing this through. The recent change in submitting editor is j= ust a reflection of who had the most time; the core team members have all r= emained involved since draft publication resumed.

<= div>=C2=A0 I'm interested in any feedback or suggestions on the path fo= rward.

thanks,
-henry

--

  • Henry Andrews=C2=A0=C2=A0|=C2=A0=C2= =A0Systems Engineer
    henry@cloudflare.com

    1 888 99 FLARE=C2=A0=C2=A0|=C2=A0=C2=A0www.cloudflare.com


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


<= br clear=3D"all">

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


--
=
--001a1147c446777b9805633c818d-- From nobody Sat Jan 20 14:59:24 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712EC126DC2 for ; Sat, 20 Jan 2018 14:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Qx9IhdzHjaZM for ; Sat, 20 Jan 2018 14:59:21 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 35A7F1201F2 for ; Sat, 20 Jan 2018 14:59:21 -0800 (PST) Received: from [10.32.60.60] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w0KMx49v032239 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 20 Jan 2018 15:59:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.60] From: "Paul Hoffman" To: "Henry Andrews" Cc: json@ietf.org Date: Sat, 20 Jan 2018 14:59:16 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Json] JSON Schema 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, 20 Jan 2018 22:59:22 -0000 On 20 Jan 2018, at 13:25, Henry Andrews wrote: > Hi folks, > I'm one of the JSON Schema draft editors, and it's been brought to > our > attention that the JSON Schema project may fit within this working > group > (or a successor? I'm a little confused as to the current status and > scope > of this group). The WG is closed and thus has no charter. If you want an IETF WG for JSON Schema, it would need to be a new WG. The new WG could be chartered just to work on JSON Schema, and not every other JSON-y idea that comes by. > The current draft is draft-07 (although the actual IETF numbering is > complicated). So draft-02 was a very long time ago :-) Could you point to the actual documents you are talking about? I see draft-handrews-json-schema-00, which is not at -07, --Paul Hoffman From nobody Sun Jan 21 14:11:36 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9721243F3 for ; Sun, 21 Jan 2018 14:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1mI3r194H_0 for ; Sun, 21 Jan 2018 14:11:33 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 132C01200F1 for ; Sun, 21 Jan 2018 14:11:33 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id 16so6618947wry.12 for ; Sun, 21 Jan 2018 14:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v+Zvf6i6Fbne6xv6+F+F6claovgpxEFrRMFzWuNRFeQ=; b=PiT8lSjWHwyMNRVNWuDNxo7Q3XmJ5W+nybC0g0AbxCoTtdAVCh1vTrVEFvRnk9xc9l ss4p9tOcvuxGUMDe5mOFxKtsR0MiNPtudjhv1SyZPUFaqsH8MIyG1eh22expdZbINqOh vbVCfs2YkYYHhZByyfjwgEcHzKS+ZxCQhOSQ8= 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=v+Zvf6i6Fbne6xv6+F+F6claovgpxEFrRMFzWuNRFeQ=; b=sFU1hhf1p3cPs3mwbkeLkpH3z2SbRhKkof7zVjahonxDINm6jP82N9kLi0mp99Mvjd Kqp8o4PL//e0SR9Hqjji384ACu54Yq/1cBxloVTP5JXfTIIhVkAZXC2RCAo8XZCqkBlT RDCpCjI1mz8PJf6PlsQNWWj9jX8LVpYIKkC+qtxrMFNtvQz6+Eg872TdL/XDspKMbfST ta7ffxLtitphsPWrV/IZkGho5PVOL3JlV65VxZd3QYVm9PyIJWj7/YnkAsT93+JSxose j23nxWuEpvAFE+/vlmt/88uyGCD3sWhD2C55nmb/FmwhWTFq4m4Ontym2M8ipRDS/7aK +BOw== X-Gm-Message-State: AKwxytcztPt2qfwfa1Cg8s6oppwSX3GvyAQbWcjS8n98O0bmjNSczNhg zMS1NjsMV15TY8QtMi7bShN/lZuT96dw3VS0XywmFK1rosI= X-Google-Smtp-Source: AH8x225Uy72dMV0pN20Ja3ymnEH2WsPVdFURSHyh1GoWdTYr1oUN+Rmc+qr1SXuEGjKL1Jjy56+Pu63TOuxxz9XKhCs= X-Received: by 10.223.133.150 with SMTP id 22mr2242201wrt.176.1516572691555; Sun, 21 Jan 2018 14:11:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.4 with HTTP; Sun, 21 Jan 2018 14:11:11 -0800 (PST) In-Reply-To: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> From: Henry Andrews Date: Sun, 21 Jan 2018 14:11:11 -0800 Message-ID: To: Paul Hoffman Cc: json@ietf.org Content-Type: multipart/alternative; boundary="001a114918d08e7c39056350988f" Archived-At: Subject: Re: [Json] JSON Schema 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, 21 Jan 2018 22:11:35 -0000 --001a114918d08e7c39056350988f Content-Type: text/plain; charset="UTF-8" The full set of current documents is on the web page: http://json-schema.org/specification.html The first set of links (in the table) go to locally hosted renderings of each document. Beneath that, there are links to the IETF-hosted documents. If you want to see why the numbering is so incredibly confusing, there's a "Specification LInks" page linked under "Older Drafts" -henry On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffman wrote: > On 20 Jan 2018, at 13:25, Henry Andrews wrote: > > Hi folks, >> I'm one of the JSON Schema draft editors, and it's been brought to our >> attention that the JSON Schema project may fit within this working group >> (or a successor? I'm a little confused as to the current status and scope >> of this group). >> > > The WG is closed and thus has no charter. If you want an IETF WG for JSON > Schema, it would need to be a new WG. The new WG could be chartered just to > work on JSON Schema, and not every other JSON-y idea that comes by. > > The current draft is draft-07 (although the actual IETF numbering is >> complicated). So draft-02 was a very long time ago :-) >> > > Could you point to the actual documents you are talking about? I see > draft-handrews-json-schema-00, which is not at -07, > > --Paul Hoffman > -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --001a114918d08e7c39056350988f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The full set of current documents is o= n the web page:

http://json-schema.org/specification.html

The first set = of links (in the table) go to locally hosted renderings of each document.
Beneath that, there are links to the IETF-hosted documents.

=
If you want to see why the numbering is so incredibly confusing, ther= e's a "Specification LInks" page linked under "Older Dra= fts"

-henry


<= div class=3D"gmail_quote">On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 20 Jan 2018, at 13:25, Henry Andrews wrote:

Hi folks,
=C2=A0 I'm one of the JSON Schema draft editors, and it's been brou= ght to our
attention that the JSON Schema project may fit within this working group (or a successor?=C2=A0 I'm a little confused as to the current status a= nd scope
of this group).

The WG is closed and thus has no charter. If you want an IETF WG for JSON S= chema, it would need to be a new WG. The new WG could be chartered just to = work on JSON Schema, and not every other JSON-y idea that comes by.

=C2=A0 The current draft is draft-07 (although the actual IETF numbering is=
complicated).=C2=A0 So draft-02 was a very long time ago :-)

Could you point to the actual documents you are talking about? I see draft-= handrews-json-schema-00, which is not at -07,

--Paul Hoffman



--
=
--001a114918d08e7c39056350988f-- From nobody Sun Jan 21 14:21:57 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB63E126C25 for ; Sun, 21 Jan 2018 14:21:55 -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 mBryc2NGfElU for ; Sun, 21 Jan 2018 14:21:53 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731301200F1 for ; Sun, 21 Jan 2018 14:21:53 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id o89so8302700lfg.10 for ; Sun, 21 Jan 2018 14:21:53 -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=G/RS0MMsT/wDEnxEnTVwrC48yIFiNi5kCs/KjlZzzEM=; b=JlkvfR3xPOmi/73rG1AEaejqDB+zVJ8i91OWZ/lnIc+fTx2FnFMr9/BGE1YJM0pVcc Uoc0zylWITLvp97/8uLVX2+Q2H4QdHdKvpAkrCdwqD+/4vpPDDKY6oBbmMqwPezkgKxS sE9872kYpWRRf65cUgzhFPKJT5ofFWa3ZsAVqC0Qxcy1b+L+P4eL+HwNE49ciWlTU+Mc tsRNWX+ra9k9WDT6UjnBrT1lk8vpJi+6Lf52mFxGGxB3tddaR4AX6ENG3SaXZeGPPXlg oN4yVYqV97O3AqGGPy3rpZSSo5KQYqnHnwdA8jug0O5n0nr+RNuNfHtEI5U0ECcPGnqc hxMQ== 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=G/RS0MMsT/wDEnxEnTVwrC48yIFiNi5kCs/KjlZzzEM=; b=tnvE5+DlBKAGjr63jqk8rb4RUMtvEWybPe6xr2lf5poBITxBec+jkf1fPJv1bxjIMp Bx5NdJRJ+5D2L0XzCM842wlOBSY0bLSL6CVr+D5sVCZnvGb/1COU1aOUXb09N6R82TBu yFYZePbRp+M5iOnPKa5m+mde/b/3Obf+rja+zwrFR53RBaW80bo5FHxX1gyAqqIdG0db 7N7/hIpDTyxtTVuaJkefeJVMKCCeU+DTCMxyVjDRBwnlEwwVkpBfmvG4AerTBv6leB2h USpbY7aF6sIpf/reu0n+uZJjBqn25YiCYZv5/c5eURs62Sr7EVstJm1zQUGOelVReIXf jTHw== X-Gm-Message-State: AKwxytcyYrWdmdRnm8+dPNORExqhYQ/ZA3Ot8eUo8mjKCePgQ8PTBND1 NMLHDz5oubSn5kGn16Uhyu5ExFfgqyV3hXNMr4M= X-Google-Smtp-Source: AH8x225NQggRE2pvAkwHdCy/5dTi1Sv8MH4GHK94f8FgpPWJt15A3M5eTdiwSz7ISBYQvls/r9J9tEi9zG17niP4OoA= X-Received: by 10.25.16.3 with SMTP id f3mr2225715lfi.98.1516573311507; Sun, 21 Jan 2018 14:21:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.18.194 with HTTP; Sun, 21 Jan 2018 14:21:50 -0800 (PST) In-Reply-To: References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> From: Rob Sayre Date: Sun, 21 Jan 2018 14:21:50 -0800 Message-ID: To: Henry Andrews Cc: Paul Hoffman , json@ietf.org Content-Type: multipart/alternative; boundary="001a113fb3008222c8056350bdc3" Archived-At: Subject: Re: [Json] JSON Schema 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, 21 Jan 2018 22:21:56 -0000 --001a113fb3008222c8056350bdc3 Content-Type: text/plain; charset="UTF-8" Hi all. There are much more efficient and unambiguous formats available if there's a schema at hand. thanks, Rob On Sun, Jan 21, 2018 at 2:11 PM, Henry Andrews wrote: > The full set of current documents is on the web page: > > http://json-schema.org/specification.html > > The first set of links (in the table) go to locally hosted renderings of > each document. > Beneath that, there are links to the IETF-hosted documents. > > If you want to see why the numbering is so incredibly confusing, there's a > "Specification LInks" page linked under "Older Drafts" > > -henry > > > On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffman > wrote: > >> On 20 Jan 2018, at 13:25, Henry Andrews wrote: >> >> Hi folks, >>> I'm one of the JSON Schema draft editors, and it's been brought to our >>> attention that the JSON Schema project may fit within this working group >>> (or a successor? I'm a little confused as to the current status and >>> scope >>> of this group). >>> >> >> The WG is closed and thus has no charter. If you want an IETF WG for JSON >> Schema, it would need to be a new WG. The new WG could be chartered just to >> work on JSON Schema, and not every other JSON-y idea that comes by. >> >> The current draft is draft-07 (although the actual IETF numbering is >>> complicated). So draft-02 was a very long time ago :-) >>> >> >> Could you point to the actual documents you are talking about? I see >> draft-handrews-json-schema-00, which is not at -07, >> >> --Paul Hoffman >> > > > > -- > > - > > *Henry Andrews* | Systems Engineer > henry@cloudflare.com > > > 1 888 99 FLARE | www.cloudflare.com > - > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --001a113fb3008222c8056350bdc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all.

There are much more efficient a= nd unambiguous formats available if there's a schema at hand.
=

thanks,
Rob


On Sun, Jan 21, 2018 at = 2:11 PM, Henry Andrews <henry@cloudflare.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
The full= set of current documents is on the web page:

http://json-schema.org/specification.html

The first set of links (in the table= ) go to locally hosted renderings of each document.
Beneath that, = there are links to the IETF-hosted documents.

If you want to s= ee why the numbering is so incredibly confusing, there's a "Specif= ication LInks" page linked under "Older Drafts"

-henry


On Sa= t, Jan 20, 2018 at 2:59 PM, Paul Hoffman <paul.hoffman@vpnc.org>= ; wrote:
On 20 Jan 2018, at 13:25,= Henry Andrews wrote:

Hi folks,
=C2=A0 I'm one of the JSON Schema draft editors, and it's been brou= ght to our
attention that the JSON Schema project may fit within this working group (or a successor?=C2=A0 I'm a little confused as to the current status a= nd scope
of this group).

The WG is closed and thus has no charter. If you want an IETF WG for JSON S= chema, it would need to be a new WG. The new WG could be chartered just to = work on JSON Schema, and not every other JSON-y idea that comes by.

=C2=A0 The current draft is draft-07 (although the actual IETF numbering is=
complicated).=C2=A0 So draft-02 was a very long time ago :-)

Could you point to the actual documents you are talking about? I see draft-= handrews-json-schema-00, which is not at -07,

--Paul Hoffman



--

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


--001a113fb3008222c8056350bdc3-- From nobody Sun Jan 21 18:09:05 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01B0126C25 for ; Sun, 21 Jan 2018 18:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0ajvt2mmxuA for ; Sun, 21 Jan 2018 18:08:50 -0800 (PST) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAD11242F5 for ; Sun, 21 Jan 2018 18:08:34 -0800 (PST) Received: by mail-wr0-x22e.google.com with SMTP id x1so6931137wrb.5 for ; Sun, 21 Jan 2018 18:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kjtk1JEqTGrymA3eLEs26dvoLqvVaPTAY9jHcxwe6g8=; b=Jp+Omh+zjt4Cw2Wnh6C+wBosnlP8Zv6X2pxWZ31yKhNFFnALHv5vXl+6wfhJ8i3Arv QssQjIlHlCN7OEfhfZgIxx2LhtF9WaHIu1kf5oCmQfNx7pFgvfUh2/yJXhJjHEY21Ygd yOJwfVVB9cbXuT95dMcS3TLCPlFrS+1zEEA5A= 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=Kjtk1JEqTGrymA3eLEs26dvoLqvVaPTAY9jHcxwe6g8=; b=Wpkkw5Jft/eiNqSVCKefWdXr9cB38IDmAapBQJjgfs+HNVPE9Jj+wxLvH6GC1O0Us7 kmmUuFg2ePT/2n8hoVOPb55DClnTECaxt/fDMZELZvuKKATSA00LrfRXWw/eYXb2VNh0 eS08oYk0CM4evTIw1ueqJ59SJC3h2/+z+DBbHXibjaZc2Hk6J4QEcyrhAhAXBCurFrLW kxY5OeW/uVbivR2sB4hj629a9tKpQlN6xOyQo0RLb7E3cRogsbxwSpqejfV7qsBleXO1 FG2XaXDrB4BgQymifpAFNMYw3eGCR919tWERfa2kgER0NQDVme1JfAP1r3ebsEIkJbwI oSVw== X-Gm-Message-State: AKwxytceF8tjYpYw2ysAoxS21+73S/RkR4iCXYceHMTJtX5D1zwYWv8M DyU17H+x1+7BHHsJLGzXz5KXbKhFHxmyT8K6gvEt6A== X-Google-Smtp-Source: AH8x226hX5duI0IiQPJOs3qzjjXCRPCCbhYhfF2NHewxskxWc9Ape2RMdZbXW6SzbVgLIITJJPNrPdbWtcoBf5LlLZA= X-Received: by 10.223.139.10 with SMTP id n10mr5309847wra.23.1516586912955; Sun, 21 Jan 2018 18:08:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.4 with HTTP; Sun, 21 Jan 2018 18:08:12 -0800 (PST) In-Reply-To: References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> From: Henry Andrews Date: Sun, 21 Jan 2018 18:08:12 -0800 Message-ID: To: Rob Sayre Cc: Paul Hoffman , json@ietf.org Content-Type: multipart/alternative; boundary="f403045e9f7437d092056353e843" Archived-At: Subject: Re: [Json] JSON Schema 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, 22 Jan 2018 02:09:03 -0000 --f403045e9f7437d092056353e843 Content-Type: text/plain; charset="UTF-8" I'm not sure I follow. Are you talking about an alternative? If so could you provide a name or a link? Or are you asking for the JSON Schema spec in a different format? On Sun, Jan 21, 2018 at 2:21 PM, Rob Sayre wrote: > Hi all. > > There are much more efficient and unambiguous formats available if there's > a schema at hand. > > thanks, > Rob > > > On Sun, Jan 21, 2018 at 2:11 PM, Henry Andrews > wrote: > >> The full set of current documents is on the web page: >> >> http://json-schema.org/specification.html >> >> The first set of links (in the table) go to locally hosted renderings of >> each document. >> Beneath that, there are links to the IETF-hosted documents. >> >> If you want to see why the numbering is so incredibly confusing, there's >> a "Specification LInks" page linked under "Older Drafts" >> >> -henry >> >> >> On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffman >> wrote: >> >>> On 20 Jan 2018, at 13:25, Henry Andrews wrote: >>> >>> Hi folks, >>>> I'm one of the JSON Schema draft editors, and it's been brought to our >>>> attention that the JSON Schema project may fit within this working group >>>> (or a successor? I'm a little confused as to the current status and >>>> scope >>>> of this group). >>>> >>> >>> The WG is closed and thus has no charter. If you want an IETF WG for >>> JSON Schema, it would need to be a new WG. The new WG could be chartered >>> just to work on JSON Schema, and not every other JSON-y idea that comes by. >>> >>> The current draft is draft-07 (although the actual IETF numbering is >>>> complicated). So draft-02 was a very long time ago :-) >>>> >>> >>> Could you point to the actual documents you are talking about? I see >>> draft-handrews-json-schema-00, which is not at -07, >>> >>> --Paul Hoffman >>> >> >> >> >> -- >> >> - >> >> *Henry Andrews* | Systems Engineer >> henry@cloudflare.com >> >> >> 1 888 99 FLARE | www.cloudflare.com >> - >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> > -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --f403045e9f7437d092056353e843 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure I follow.=C2=A0 Are you talking about an = alternative?=C2=A0 If so could you provide a name or a link?=C2=A0 Or are y= ou asking for the JSON Schema spec in a different format?

On Sun, Jan 21, 2018 at 2= :21 PM, Rob Sayre <sayrer@gmail.com> wrote:
Hi all.

There are much= more efficient and unambiguous formats available if there's a schema a= t hand.

thanks,
Rob


On Sun,= Jan 21, 2018 at 2:11 PM, Henry Andrews <henry@cloudflare.com> wrote:
<= div>
The full set of current documents is on the web page:

http://j= son-schema.org/specification.html

The first set of li= nks (in the table) go to locally hosted renderings of each document.
Beneath that, there are links to the IETF-hosted documents.

If you want to see why the numbering is so incredibly confusing, there'= ;s a "Specification LInks" page linked under "Older Drafts&q= uot;
-henry


On Sat, Jan 20, 2018 at 2:59 PM,= Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On 20 Jan 2018, at 13:25, Henry Andrews wrote:

Hi folks,
=C2=A0 I'm one of the JSON Schema draft editors, and it's been brou= ght to our
attention that the JSON Schema project may fit within this working group (or a successor?=C2=A0 I'm a little confused as to the current status a= nd scope
of this group).

The WG is closed and thus has no charter. If you want an IETF WG for JSON S= chema, it would need to be a new WG. The new WG could be chartered just to = work on JSON Schema, and not every other JSON-y idea that comes by.

=C2=A0 The current draft is draft-07 (although the actual IETF numbering is=
complicated).=C2=A0 So draft-02 was a very long time ago :-)

Could you point to the actual documents you are talking about? I see draft-= handrews-json-schema-00, which is not at -07,

--Paul Hoffman



--

  • Henry Andrews=C2=A0=C2=A0|=C2=A0=C2= =A0Systems Engineer
    henry@cloudflare.com

    1 888 99 FLARE=C2=A0=C2=A0|=C2=A0=C2=A0www.cloudflare.com


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





--
=
--f403045e9f7437d092056353e843-- From nobody Sun Jan 21 18:25:37 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E78126CC7 for ; Sun, 21 Jan 2018 18:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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 kwD-z_gsNHHE for ; Sun, 21 Jan 2018 18:25:34 -0800 (PST) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (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 26E7A126C19 for ; Sun, 21 Jan 2018 18:25:34 -0800 (PST) Received: by mail-ot0-x242.google.com with SMTP id x4so6228742otg.7 for ; Sun, 21 Jan 2018 18:25:34 -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=+5zau/DD8OOJcNwZICNQI0fSfVCa11RWfc37hRm1Isc=; b=iwL/zlAXCtS5cxhYTUFXy7LdYm23ezA+IndRLlrobdu+i1aJyTIb3+/lT2herGuomu hNiBnLC/vOQEI1XvMVLVwue6ROHkZ9KonXaqvg9winYnMihB/NdYV6OrrY46uLCLcirn nrWbj0uU0OtgpkDkyu5s7aJuQnEWf0y+CWQ1kgjJ2iT43qHiqIMN7JqximLwjU5EPbv8 oS67/lDFxHKADwf7ws7mBCXA7bI8k9F9yW2TmWK3T+VeCeUKmoAhGs3CPrqeRuA54rQx BbDV40JAVY1a62Al/sBpv5fQnijuNoZNnfKk+SM7PGRFrh/DSkh426XRGjdxlJAHVtE7 gbig== 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=+5zau/DD8OOJcNwZICNQI0fSfVCa11RWfc37hRm1Isc=; b=CxZ9oJuTX7eGXg7KCq72wMOppdnFzPd3B7VM6sxHIgPPo+Qo5/P69jC7kYfrZejxZD LFF35kLjq/y31S3Np/TSDG9uANS87MFb9j8EVe6LUh03J5h+0RRCeS8KBq7suMwiU304 T38fCCixkYCkPPs5G6NTNEyZCnHuKly5UaEivUPzPSZ0UfA97iElY0Y0NlIGECc9ZN0t tuBNQ/qfcR8ZtXoFLTDC5XKPbdIjRpu8IqS5SAGZgTCz1BzsbhLpsLBGKFtHqrZGjIe3 7eZRLjsKxwJQIV8/efj0mwcv0SPQCAMowRCCCOEEr1fJYVZ5R4/IYclNNsztHk8/9VQ4 xLjA== X-Gm-Message-State: AKwxytccO9OhOyVmCjbnM4UVKaHfrbVwemDbLaHy8xYFnADbfLJ+Ob+R jisoez2DDk2PWfXswjlTiOKglVKsLYpsne5wBVk= X-Google-Smtp-Source: AH8x225zCrhOla37U7kYsHo+ltvvaGf541KCqYS30Ng4G10Rh66HO7HndphgsWNWoFiRkDDsLQmQuzE4cnGbZ0uwyk8= X-Received: by 10.157.45.169 with SMTP id g38mr3670467otb.149.1516587933153; Sun, 21 Jan 2018 18:25:33 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.37.125 with HTTP; Sun, 21 Jan 2018 18:25:31 -0800 (PST) In-Reply-To: References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> From: Phillip Hallam-Baker Date: Sun, 21 Jan 2018 21:25:31 -0500 X-Google-Sender-Auth: W2PqJrZ8Bn1MDNF0kbTlwvTAgoE Message-ID: To: Rob Sayre Cc: Henry Andrews , Paul Hoffman , JSON WG Content-Type: multipart/alternative; boundary="94eb2c0321fa06be4d05635425fe" Archived-At: Subject: Re: [Json] JSON Schema 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, 22 Jan 2018 02:25:36 -0000 --94eb2c0321fa06be4d05635425fe Content-Type: text/plain; charset="UTF-8" +1 I have been designing protocols for 25 years and I have never come across a requirement to specify a minimum number of items in a set that is other than 0 or 1 and never come across a reason to specify a maximum other than 1 or infinity. When I have come across other limits, I have pretty much always found them to be wrong. Take the requirement to have two authoritative servers for a DNS zone (not enforced by the protocol but enforced by the social infrastructure around it). That seemed such a good idea to me till I found the two authoritative servers for the MIT LCS/AI running on a couple of sparc stations plugged into the same wall socket. The less twiddles and curlicues, the better. Validation is not useful for a data schema. It is useful for a document schema because it allows an intelligent editor to tell the user if they are filling in what really amounts to a form correctly. My other objection is to the use of JSON syntax and the limitation to JSON encoding. I don't see a reason to limit scope to one encoding. I write my systems using a schema language that is at least in principle capable of targeting ASN.1 and XML as well as JSON. This approach only allows me a subset of the capabilities of ASN.1 and XML schema which is exactly the point. On Sun, Jan 21, 2018 at 5:21 PM, Rob Sayre wrote: > Hi all. > > There are much more efficient and unambiguous formats available if there's > a schema at hand. > > thanks, > Rob > > > On Sun, Jan 21, 2018 at 2:11 PM, Henry Andrews > wrote: > >> The full set of current documents is on the web page: >> >> http://json-schema.org/specification.html >> >> The first set of links (in the table) go to locally hosted renderings of >> each document. >> Beneath that, there are links to the IETF-hosted documents. >> >> If you want to see why the numbering is so incredibly confusing, there's >> a "Specification LInks" page linked under "Older Drafts" >> >> -henry >> >> >> On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffman >> wrote: >> >>> On 20 Jan 2018, at 13:25, Henry Andrews wrote: >>> >>> Hi folks, >>>> I'm one of the JSON Schema draft editors, and it's been brought to our >>>> attention that the JSON Schema project may fit within this working group >>>> (or a successor? I'm a little confused as to the current status and >>>> scope >>>> of this group). >>>> >>> >>> The WG is closed and thus has no charter. If you want an IETF WG for >>> JSON Schema, it would need to be a new WG. The new WG could be chartered >>> just to work on JSON Schema, and not every other JSON-y idea that comes by. >>> >>> The current draft is draft-07 (although the actual IETF numbering is >>>> complicated). So draft-02 was a very long time ago :-) >>>> >>> >>> Could you point to the actual documents you are talking about? I see >>> draft-handrews-json-schema-00, which is not at -07, >>> >>> --Paul Hoffman >>> >> >> >> >> -- >> >> - >> >> *Henry Andrews* | Systems Engineer >> henry@cloudflare.com >> >> >> 1 888 99 FLARE | www.cloudflare.com >> - >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > --94eb2c0321fa06be4d05635425fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1<= /div>

I have been designing pro= tocols for 25 years and I have never come across a requirement to specify a= minimum number of items in a set that is other than 0 or 1 and never come = across a reason to specify a maximum other than 1 or infinity.

When I have come across other limits,= I have pretty much always found them to be wrong. Take the requirement to = have two authoritative servers for a DNS zone (not enforced by the protocol= but enforced by the social infrastructure around it). That seemed such a g= ood idea to me till I found the two authoritative servers for the MIT LCS/A= I running on a couple of sparc stations plugged into the same wall socket.<= /div>


The less twiddles and curlicues, th= e better.

<= /div>
Validation is n= ot useful for a data schema. It is useful for a document schema because it = allows an intelligent editor to tell the user if they are filling in what r= eally amounts to a form correctly.=C2=A0


My other objection is to the use of JSON syntax and the limitation to= JSON encoding. I don't see a reason to limit scope to one encoding. I = write my systems using a schema language that is at least in principle capa= ble of targeting ASN.1 and XML as well as JSON. This approach only allows m= e a subset of the capabilities of ASN.1 and XML schema which is exactly the= point.


<= div class=3D"gmail_extra">
On Sun, Jan 21, 20= 18 at 5:21 PM, Rob Sayre <sayrer@gmail.com> wrote:
Hi all.

There a= re much more efficient and unambiguous formats available if there's a s= chema at hand.

thanks,
Rob


=
On Sun, Jan 21, 2018 at 2:11 PM, Henry Andrews <= henry@cloudflare.com> wrote:
T= he full set of current documents is on the web page:

http://json-schema= .org/specification.html

The first set of links (in th= e table) go to locally hosted renderings of each document.
Beneath= that, there are links to the IETF-hosted documents.

If you wa= nt to see why the numbering is so incredibly confusing, there's a "= ;Specification LInks" page linked under "Older Drafts"

-henry

=
On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffma= n <paul.hoffman@vpnc.org> wrote:
On 20 Jan 2018, at 13:25, Henry Andrews wrote:

Hi folks,
=C2=A0 I'm one of the JSON Schema draft editors, and it's been brou= ght to our
attention that the JSON Schema project may fit within this working group (or a successor?=C2=A0 I'm a little confused as to the current status a= nd scope
of this group).

The WG is closed and thus has no charter. If you want an IETF WG for JSON S= chema, it would need to be a new WG. The new WG could be chartered just to = work on JSON Schema, and not every other JSON-y idea that comes by.

=C2=A0 The current draft is draft-07 (although the actual IETF numbering is=
complicated).=C2=A0 So draft-02 was a very long time ago :-)

Could you point to the actual documents you are talking about? I see draft-= handrews-json-schema-00, which is not at -07,

--Paul Hoffman



--

_____________________________________= __________
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


--94eb2c0321fa06be4d05635425fe-- From nobody Sun Jan 21 18:49:25 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C487126D3F for ; Sun, 21 Jan 2018 18:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_TRY_3LD=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haBog8MRug5W for ; Sun, 21 Jan 2018 18:49:21 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 AD661126CC7 for ; Sun, 21 Jan 2018 18:49:20 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id r71so946795wmd.1 for ; Sun, 21 Jan 2018 18:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0hoLy7d3QtHsHifVeszHOnv2Alg0M6GONROYHVKlyGo=; b=E7KhjlfVqIaEY3SZ4Qrn6bz4eruma08uD8DQJsMVGmtELh0mYvJdIb6t18KPQm61/Y I13savld3w/9p2BWLBoXzkyH2dEPZ5u838mutFBW41COERD2CTfiY2dz4hrJR88L+Myq EuOrII/gwSdjdvhP50dyNpimwXO2MTTQOVsws= 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=0hoLy7d3QtHsHifVeszHOnv2Alg0M6GONROYHVKlyGo=; b=p14UO1pCbXqXn6RB6nqqV/x0ZMjd5OS8kNc4USrDClRQln7CKG+NsOmhO9YZlozlhK JLqa/sPFY2V5DfzHKGqrcGEhw0UvT1rcjsaTozw/9wqklnfbKIpaV6b2cf7uZ305Fokw wXbt1juZdMfLpZquwXtuKp/J7P5PKuWJrP/TmmTiKSw/JBNmMB3vcjrOSCYUCNmb5Enm SDLYjPU0ScMSYNaUv7lOHqXF7/jAVocP+pD02yf47YMje2I2oeQZhkDGLW1XQO70YN8g zaFhQG0EU/cDPEcA2Q/S2DJwIGud/Kp3rwmvyy2WxBb/Lo0pSMlui3eogIOk0UwN1BL2 TQsg== X-Gm-Message-State: AKwxytdAPYs7yJ83rICt+9kNheiHvgZTbxAcUznSDmFS2izvJpS5am/b wXC2UOVoTnVF+PMFtcNePT/DqmYewbWvHrkQkBP8Qg== X-Google-Smtp-Source: AH8x226i463EwnNTapP9NTIA6Qt1L0h/VbVGrfTJDpgvTYH2u7RckiZTepOP//pIAQ8PLqv2kQJhTFTu+uyxFvdF9DQ= X-Received: by 10.28.134.140 with SMTP id i134mr4544867wmd.57.1516589359156; Sun, 21 Jan 2018 18:49:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.4 with HTTP; Sun, 21 Jan 2018 18:48:58 -0800 (PST) In-Reply-To: References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> From: Henry Andrews Date: Sun, 21 Jan 2018 18:48:58 -0800 Message-ID: To: Phillip Hallam-Baker Cc: Rob Sayre , Paul Hoffman , JSON WG Content-Type: multipart/alternative; boundary="001a114439d005e5ef0563547a8d" Archived-At: Subject: Re: [Json] JSON Schema 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, 22 Jan 2018 02:49:24 -0000 --001a114439d005e5ef0563547a8d Content-Type: text/plain; charset="UTF-8" So... the point of me sending this email was to answer a request made to the JSON Schema project that I investigate the working group. The clear answer to that is that this working group is closed, and a new one would need to be chartered. It's not clear to me that we would want to charter such a group now, although I would be interested in anyone's input on that. Otherwise this discussion has turned into various people raising complaints about JSON Schema who have clearly not followed the recent developments on the project, or just clearly want something entirely different. For those complaining about outdated concepts (failure to consider data definition, which is actually a huge focus right now, or concern over a required json encoding, which no longer exists- the spec works on a data model derived from JSON, not on JSON itself, or the behavior of implementations that are five drafts out of date) I don't think a closed working group mailing list that did not have JSON Schema in its scope to begin with is the appropriate place to deal with these complaints. Nor does it seem to be the appropriate place for me to educate everyone on the past few years of work. For those of you who want something else entirely, that's great, there are lots of good ideas out there. I wish you well. There are several projects underway in the same general space, some with quite a bit of momentum of their own. One of them may be a better choice for an IETF working group, I'm not in a position to say one way or the other. For those of you who would like to take a look at the current state of the project, outstanding topics and debates, etc., please come on over to https://github.com/json-schema-org/json-schema-spec or join our slack channel with this invite: https://join.slack.com/t/json-schema/shared_invite/enQtMjk1NDcyNDI2NTAwLTcyYmYwMjdmMmUxNzZjYzIxNGU2YjdkNzdlOGZiNjIwNDI2M2Y3NmRkYjA4YmMwODMwYjgyOTFlNWZjZjAyNjg Filing issues or asking questions on our slack channel will probably work better than hi-jacking this mailing list, now that I understand it is no longer active. :-) I would be interested in pursuing the IETF process (heavyweight or not), if there is interest from the appropriate segment of the IETF community. However, if the reaction is primarily hostile, or just indifferent with preferences for other projects, that is fine. We can work through another standards body or pursue some other path, or if our own community moves on to other ideas we can just wind it down. I have no interest in forcing anyone to support JSON Schema- it stands or falls on its own. Even without a formal standardized specification, JSON Schema is broadly used and survived several years of abandonment, so whatever other worthy ideas might be out there, we have a community to support either way, and that is my primary focus right now. thanks, -henry On Sun, Jan 21, 2018 at 6:25 PM, Phillip Hallam-Baker wrote: > +1 > > I have been designing protocols for 25 years and I have never come across > a requirement to specify a minimum number of items in a set that is other > than 0 or 1 and never come across a reason to specify a maximum other than > 1 or infinity. > > When I have come across other limits, I have pretty much always found them > to be wrong. Take the requirement to have two authoritative servers for a > DNS zone (not enforced by the protocol but enforced by the social > infrastructure around it). That seemed such a good idea to me till I found > the two authoritative servers for the MIT LCS/AI running on a couple of > sparc stations plugged into the same wall socket. > > > The less twiddles and curlicues, the better. > > Validation is not useful for a data schema. It is useful for a document > schema because it allows an intelligent editor to tell the user if they are > filling in what really amounts to a form correctly. > > > My other objection is to the use of JSON syntax and the limitation to JSON > encoding. I don't see a reason to limit scope to one encoding. I write my > systems using a schema language that is at least in principle capable of > targeting ASN.1 and XML as well as JSON. This approach only allows me a > subset of the capabilities of ASN.1 and XML schema which is exactly the > point. > > > > On Sun, Jan 21, 2018 at 5:21 PM, Rob Sayre wrote: > >> Hi all. >> >> There are much more efficient and unambiguous formats available if >> there's a schema at hand. >> >> thanks, >> Rob >> >> >> On Sun, Jan 21, 2018 at 2:11 PM, Henry Andrews >> wrote: >> >>> The full set of current documents is on the web page: >>> >>> http://json-schema.org/specification.html >>> >>> The first set of links (in the table) go to locally hosted renderings of >>> each document. >>> Beneath that, there are links to the IETF-hosted documents. >>> >>> If you want to see why the numbering is so incredibly confusing, there's >>> a "Specification LInks" page linked under "Older Drafts" >>> >>> -henry >>> >>> >>> On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffman >>> wrote: >>> >>>> On 20 Jan 2018, at 13:25, Henry Andrews wrote: >>>> >>>> Hi folks, >>>>> I'm one of the JSON Schema draft editors, and it's been brought to >>>>> our >>>>> attention that the JSON Schema project may fit within this working >>>>> group >>>>> (or a successor? I'm a little confused as to the current status and >>>>> scope >>>>> of this group). >>>>> >>>> >>>> The WG is closed and thus has no charter. If you want an IETF WG for >>>> JSON Schema, it would need to be a new WG. The new WG could be chartered >>>> just to work on JSON Schema, and not every other JSON-y idea that comes by. >>>> >>>> The current draft is draft-07 (although the actual IETF numbering is >>>>> complicated). So draft-02 was a very long time ago :-) >>>>> >>>> >>>> Could you point to the actual documents you are talking about? I see >>>> draft-handrews-json-schema-00, which is not at -07, >>>> >>>> --Paul Hoffman >>>> >>> >>> >>> >>> -- >>> >>> - >>> >>> *Henry Andrews* | Systems Engineer >>> henry@cloudflare.com >>> >>> >>> 1 888 99 FLARE | www.cloudflare.com >>> - >>> >>> >>> _______________________________________________ >>> json mailing list >>> json@ietf.org >>> https://www.ietf.org/mailman/listinfo/json >>> >>> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> > -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --001a114439d005e5ef0563547a8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So... the point of me sending this email wa= s to answer a request made to the JSON Schema project that I investigate th= e working group.=C2=A0 The clear answer to that is that this working group = is closed, and a new one would need to be chartered.=C2=A0 It's not cle= ar to me that we would want to charter such a group now, although I would b= e interested in anyone's input on that.


Otherwise this discussion has turned into various people raising compla= ints about JSON Schema who have clearly not followed the recent development= s on the project, or just clearly want something entirely different.=C2=A0 = For those complaining about outdated concepts (failure to consider data def= inition, which is actually a huge focus right now, or concern over a requir= ed json encoding, which no longer exists- the spec works on a data model de= rived from JSON, not on JSON itself, or the behavior of implementations tha= t are five drafts out of date) I don't think a closed working group mai= ling list that did not have JSON Schema in its scope to begin with is the a= ppropriate place to deal with these complaints.=C2=A0 Nor does it seem to b= e the appropriate place for me to educate everyone on the past few years of= work.

For those of you who want something els= e entirely, that's great, there are lots of good ideas out there.=C2=A0= I wish you well.=C2=A0 There are several projects underway in the same gen= eral space, some with quite a bit of momentum of their own.=C2=A0 One of th= em may be a better choice for an IETF working group, I'm not in a posit= ion to say one way or the other.

For those of = you who would like to take a look at the current state of the project, outs= tanding topics and debates, etc., please come on over to https://github.com/json-schem= a-org/json-schema-spec or join our slack channel with this invite:
<= br>https://join.slack.com/t/json-schema/shared_invite/= enQtMjk1NDcyNDI2NTAwLTcyYmYwMjdmMmUxNzZjYzIxNGU2YjdkNzdlOGZiNjIwNDI2M2Y3NmR= kYjA4YmMwODMwYjgyOTFlNWZjZjAyNjg

Filing is= sues or asking questions on our slack channel will probably work better tha= n hi-jacking this mailing list, now that I understand it is no longer activ= e. :-)

I would be interested in pursuing the I= ETF process (heavyweight or not), if there is interest from the appropriate= segment of the IETF community.=C2=A0 However, if the reaction is primarily= hostile, or just indifferent with preferences for other projects, that is = fine.=C2=A0 We can work through another standards body or pursue some other= path, or if our own community moves on to other ideas we can just wind it = down.=C2=A0 I have no interest in forcing anyone to support JSON Schema- it= stands or falls on its own.=C2=A0 Even without a formal standardized speci= fication, JSON Schema is broadly used and survived several years of abandon= ment, so whatever other worthy ideas might be out there, we have a communit= y to support either way, and that is my primary focus right now.
<= div>
thanks,
-henry


On Sun, Jan 21, 201= 8 at 6:25 PM, Phillip Hallam-Baker <ietf@hallambaker.com>= wrote:
+1

I have been designing protocols for 25 years and I have ne= ver come across a requirement to specify a minimum number of items in a set= that is other than 0 or 1 and never come across a reason to specify a maxi= mum other than 1 or infinity.

When I have come across other limits, I have pretty much always found = them to be wrong. Take the requirement to have two authoritative servers fo= r a DNS zone (not enforced by the protocol but enforced by the social infra= structure around it). That seemed such a good idea to me till I found the t= wo authoritative servers for the MIT LCS/AI running on a couple of sparc st= ations plugged into the same wall socket.


The less twiddles and curlicues, the better.

Validation is not useful for a data schema. It i= s useful for a document schema because it allows an intelligent editor to t= ell the user if they are filling in what really amounts to a form correctly= .=C2=A0


My other objection is to th= e use of JSON syntax and the limitation to JSON encoding. I don't see a= reason to limit scope to one encoding. I write my systems using a schema l= anguage that is at least in principle capable of targeting ASN.1 and XML as= well as JSON. This approach only allows me a subset of the capabilities of= ASN.1 and XML schema which is exactly the point.



On Sun, Jan 21, 2018 at 5:21 PM, Rob Sayre <sayrer@= gmail.com> wrote:
Hi all.

There are much more efficient and unamb= iguous formats available if there's a schema at hand.
thanks,
Rob


On Sun, Jan 21, 2018 at 2:11 PM, Henry Andrews <henry@cloud= flare.com> wrote:
<= div>
The full set of current documents is on the web page:

http://j= son-schema.org/specification.html

The first set of li= nks (in the table) go to locally hosted renderings of each document.
Beneath that, there are links to the IETF-hosted documents.

If you want to see why the numbering is so incredibly confusing, there'= ;s a "Specification LInks" page linked under "Older Drafts&q= uot;

-henry

<= /font>

On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffman <= ;paul.hoffman@vp= nc.org> wrote:
On 20 Jan 20= 18, at 13:25, Henry Andrews wrote:

Hi folks,
=C2=A0 I'm one of the JSON Schema draft editors, and it's been brou= ght to our
attention that the JSON Schema project may fit within this working group (or a successor?=C2=A0 I'm a little confused as to the current status a= nd scope
of this group).

The WG is closed and thus has no charter. If you want an IETF WG for JSON S= chema, it would need to be a new WG. The new WG could be chartered just to = work on JSON Schema, and not every other JSON-y idea that comes by.

=C2=A0 The current draft is draft-07 (although the actual IETF numbering is=
complicated).=C2=A0 So draft-02 was a very long time ago :-)

Could you point to the actual documents you are talking about? I see draft-= handrews-json-schema-00, which is not at -07,

--Paul Hoffman



--


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





--
=
--001a114439d005e5ef0563547a8d-- From nobody Sun Jan 21 18:52:26 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57E2126CC7 for ; Sun, 21 Jan 2018 18:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_TRY_3LD=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfHseITTJvYN for ; Sun, 21 Jan 2018 18:52:21 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 133AF1200F1 for ; Sun, 21 Jan 2018 18:52:21 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id t16so6984869wrc.10 for ; Sun, 21 Jan 2018 18:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ltNrWiVkB5DRJWy2CqDUq4A8YkE8poO2rHOz7vjMFDQ=; b=isdEKa5uBcgipzGxlAflAtdz92zsZWE4ZuyKd6ATcsMVr8exF9FIJPj/Tdr8vKEvWd t8O87b6VwzxSqLsH1pQagwqC1VRMbHRFg0mlzjA+4tjE9IyTjUkvXHg2rVR62WhvW0nL BtU4hprM9Ev7kaWOQU2CGGrLTUH+EYo54wAPk= 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=ltNrWiVkB5DRJWy2CqDUq4A8YkE8poO2rHOz7vjMFDQ=; b=fmolgcy7xc14tllsXtfdYUwYbf50Ih0aZF0Mf5pc/eYG1DZAzqwqPp1LHG8DfPbpTy 1i30h5M/S7mwWNN2TalN1fDq5QOcCle60r6KXHOklsytQG6hGKVuHsdwlmp8JA2OAaCr 79/U+nF3fS53jr09Zsj64m7G83RJfRW0dky9xaOxeVWteD0OlF1IBZBr2soi1LiyLcmz 5aVRgZPCuFa1gMJgIljYgl9cHWxbrMii8Q2Vkxahl8E0nC13uC5dNKgNvPPDiBR0c1p6 zWyyG5OCgr4QbuyCzG8fLAEo+WwxsT03a10QcyBirKitzj0U4H9YWZSBJpUBf20TAJWA 71xQ== X-Gm-Message-State: AKwxytc0L1xaIrsSO94U8/Ve61rw2oscWO8xKueuR0m0HGROrNSPb2Gi xElSs0MC8+1rBX29jSnkKG5nnyNfra+5JzfxBPmEuA== X-Google-Smtp-Source: AH8x224E1cMv+tyq7pbLkh0idd6561Zk8nDRVg/KQUU0I6nvsHh6clZsvVGzW46CLB9GyQJXOeB5p2Git7l2xcZXNNY= X-Received: by 10.223.139.10 with SMTP id n10mr5374811wra.23.1516589539616; Sun, 21 Jan 2018 18:52:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.4 with HTTP; Sun, 21 Jan 2018 18:51:59 -0800 (PST) In-Reply-To: References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> From: Henry Andrews Date: Sun, 21 Jan 2018 18:51:59 -0800 Message-ID: To: Phillip Hallam-Baker Cc: Rob Sayre , Paul Hoffman , JSON WG Content-Type: multipart/alternative; boundary="f403045e9f74c77c5f0563548460" Archived-At: Subject: Re: [Json] JSON Schema 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, 22 Jan 2018 02:52:25 -0000 --f403045e9f74c77c5f0563548460 Content-Type: text/plain; charset="UTF-8" Note that this is all my personal opinion. I'm the de-facto spokesperson for JSON Schema mostly because I have the most time available, but I'm not necessarily the ideal person to be running things. So take my views with a grain of salt. On Sun, Jan 21, 2018 at 6:48 PM, Henry Andrews wrote: > So... the point of me sending this email was to answer a request made to > the JSON Schema project that I investigate the working group. The clear > answer to that is that this working group is closed, and a new one would > need to be chartered. It's not clear to me that we would want to charter > such a group now, although I would be interested in anyone's input on that. > > > Otherwise this discussion has turned into various people raising > complaints about JSON Schema who have clearly not followed the recent > developments on the project, or just clearly want something entirely > different. For those complaining about outdated concepts (failure to > consider data definition, which is actually a huge focus right now, or > concern over a required json encoding, which no longer exists- the spec > works on a data model derived from JSON, not on JSON itself, or the > behavior of implementations that are five drafts out of date) I don't think > a closed working group mailing list that did not have JSON Schema in its > scope to begin with is the appropriate place to deal with these > complaints. Nor does it seem to be the appropriate place for me to educate > everyone on the past few years of work. > > For those of you who want something else entirely, that's great, there are > lots of good ideas out there. I wish you well. There are several projects > underway in the same general space, some with quite a bit of momentum of > their own. One of them may be a better choice for an IETF working group, > I'm not in a position to say one way or the other. > > For those of you who would like to take a look at the current state of the > project, outstanding topics and debates, etc., please come on over to > https://github.com/json-schema-org/json-schema-spec or join our slack > channel with this invite: > > https://join.slack.com/t/json-schema/shared_invite/ > enQtMjk1NDcyNDI2NTAwLTcyYmYwMjdmMmUxNzZjYzIxNGU2YjdkNzdlOGZi > NjIwNDI2M2Y3NmRkYjA4YmMwODMwYjgyOTFlNWZjZjAyNjg > > Filing issues or asking questions on our slack channel will probably work > better than hi-jacking this mailing list, now that I understand it is no > longer active. :-) > > I would be interested in pursuing the IETF process (heavyweight or not), > if there is interest from the appropriate segment of the IETF community. > However, if the reaction is primarily hostile, or just indifferent with > preferences for other projects, that is fine. We can work through another > standards body or pursue some other path, or if our own community moves on > to other ideas we can just wind it down. I have no interest in forcing > anyone to support JSON Schema- it stands or falls on its own. Even without > a formal standardized specification, JSON Schema is broadly used and > survived several years of abandonment, so whatever other worthy ideas might > be out there, we have a community to support either way, and that is my > primary focus right now. > > thanks, > -henry > > > On Sun, Jan 21, 2018 at 6:25 PM, Phillip Hallam-Baker < > ietf@hallambaker.com> wrote: > >> +1 >> >> I have been designing protocols for 25 years and I have never come across >> a requirement to specify a minimum number of items in a set that is other >> than 0 or 1 and never come across a reason to specify a maximum other than >> 1 or infinity. >> >> When I have come across other limits, I have pretty much always found >> them to be wrong. Take the requirement to have two authoritative servers >> for a DNS zone (not enforced by the protocol but enforced by the social >> infrastructure around it). That seemed such a good idea to me till I found >> the two authoritative servers for the MIT LCS/AI running on a couple of >> sparc stations plugged into the same wall socket. >> >> >> The less twiddles and curlicues, the better. >> >> Validation is not useful for a data schema. It is useful for a document >> schema because it allows an intelligent editor to tell the user if they are >> filling in what really amounts to a form correctly. >> >> >> My other objection is to the use of JSON syntax and the limitation to >> JSON encoding. I don't see a reason to limit scope to one encoding. I write >> my systems using a schema language that is at least in principle capable of >> targeting ASN.1 and XML as well as JSON. This approach only allows me a >> subset of the capabilities of ASN.1 and XML schema which is exactly the >> point. >> >> >> >> On Sun, Jan 21, 2018 at 5:21 PM, Rob Sayre wrote: >> >>> Hi all. >>> >>> There are much more efficient and unambiguous formats available if >>> there's a schema at hand. >>> >>> thanks, >>> Rob >>> >>> >>> On Sun, Jan 21, 2018 at 2:11 PM, Henry Andrews >>> wrote: >>> >>>> The full set of current documents is on the web page: >>>> >>>> http://json-schema.org/specification.html >>>> >>>> The first set of links (in the table) go to locally hosted renderings >>>> of each document. >>>> Beneath that, there are links to the IETF-hosted documents. >>>> >>>> If you want to see why the numbering is so incredibly confusing, >>>> there's a "Specification LInks" page linked under "Older Drafts" >>>> >>>> -henry >>>> >>>> >>>> On Sat, Jan 20, 2018 at 2:59 PM, Paul Hoffman >>>> wrote: >>>> >>>>> On 20 Jan 2018, at 13:25, Henry Andrews wrote: >>>>> >>>>> Hi folks, >>>>>> I'm one of the JSON Schema draft editors, and it's been brought to >>>>>> our >>>>>> attention that the JSON Schema project may fit within this working >>>>>> group >>>>>> (or a successor? I'm a little confused as to the current status and >>>>>> scope >>>>>> of this group). >>>>>> >>>>> >>>>> The WG is closed and thus has no charter. If you want an IETF WG for >>>>> JSON Schema, it would need to be a new WG. The new WG could be chartered >>>>> just to work on JSON Schema, and not every other JSON-y idea that comes by. >>>>> >>>>> The current draft is draft-07 (although the actual IETF numbering is >>>>>> complicated). So draft-02 was a very long time ago :-) >>>>>> >>>>> >>>>> Could you point to the actual documents you are talking about? I see >>>>> draft-handrews-json-schema-00, which is not at -07, >>>>> >>>>> --Paul Hoffman >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> - >>>> >>>> *Henry Andrews* | Systems Engineer >>>> henry@cloudflare.com >>>> >>>> >>>> 1 888 99 FLARE | www.cloudflare.com >>>> - >>>> >>>> >>>> _______________________________________________ >>>> json mailing list >>>> json@ietf.org >>>> https://www.ietf.org/mailman/listinfo/json >>>> >>>> >>> >>> _______________________________________________ >>> json mailing list >>> json@ietf.org >>> https://www.ietf.org/mailman/listinfo/json >>> >>> >> > > > -- > > - > > *Henry Andrews* | Systems Engineer > henry@cloudflare.com > > > 1 888 99 FLARE | www.cloudflare.com > - > > -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --f403045e9f74c77c5f0563548460 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that this is all my personal opinion.=C2=A0 I'm t= he de-facto spokesperson for JSON Schema mostly because I have the most tim= e available, but I'm not necessarily the ideal person to be running thi= ngs.=C2=A0 So take my views with a grain of salt.

On Sun, Jan 21, 2018 at 6:48 PM, = Henry Andrews <henry@cloudflare.com> wrote:
So... the point of me = sending this email was to answer a request made to the JSON Schema project = that I investigate the working group.=C2=A0 The clear answer to that is tha= t this working group is closed, and a new one would need to be chartered.= =C2=A0 It's not clear to me that we would want to charter such a group = now, although I would be interested in anyone's input on that.


Otherwise this discussion has turned into variou= s people raising complaints about JSON Schema who have clearly not followed= the recent developments on the project, or just clearly want something ent= irely different.=C2=A0 For those complaining about outdated concepts (failu= re to consider data definition, which is actually a huge focus right now, o= r concern over a required json encoding, which no longer exists- the spec w= orks on a data model derived from JSON, not on JSON itself, or the behavior= of implementations that are five drafts out of date) I don't think a c= losed working group mailing list that did not have JSON Schema in its scope= to begin with is the appropriate place to deal with these complaints.=C2= =A0 Nor does it seem to be the appropriate place for me to educate everyone= on the past few years of work.

For those of y= ou who want something else entirely, that's great, there are lots of go= od ideas out there.=C2=A0 I wish you well.=C2=A0 There are several projects= underway in the same general space, some with quite a bit of momentum of t= heir own.=C2=A0 One of them may be a better choice for an IETF working grou= p, I'm not in a position to say one way or the other.
For those of you who would like to take a look at the current s= tate of the project, outstanding topics and debates, etc., please come on o= ver to https://github.com/json-schema-org/json-schema-spec = or join our slack channel with this invite:

https://join.slack.com/t/json-schema/shared_invite/enQtMjk1NDcyNDI2NTAwLTcyYmYwMjdmMmUxNzZjYzIxNGU2YjdkNzdlOGZiNjIw= NDI2M2Y3NmRkYjA4YmMwODMwYjgyOTFlNWZjZjAyNjg

Filing issues or asking questions on our slack channel will probably= work better than hi-jacking this mailing list, now that I understand it is= no longer active. :-)

I would be interested i= n pursuing the IETF process (heavyweight or not), if there is interest from= the appropriate segment of the IETF community.=C2=A0 However, if the react= ion is primarily hostile, or just indifferent with preferences for other pr= ojects, that is fine.=C2=A0 We can work through another standards body or p= ursue some other path, or if our own community moves on to other ideas we c= an just wind it down.=C2=A0 I have no interest in forcing anyone to support= JSON Schema- it stands or falls on its own.=C2=A0 Even without a formal st= andardized specification, JSON Schema is broadly used and survived several = years of abandonment, so whatever other worthy ideas might be out there, we= have a community to support either way, and that is my primary focus right= now.

thanks,
-henry


On = Sun, Jan 21, 2018 at 6:25 PM, Phillip Hallam-Baker <ietf@hallambaker.co= m> wrote:
=
+1

I have been designing protocols for 25 y= ears and I have never come across a requirement to specify a minimum number= of items in a set that is other than 0 or 1 and never come across a reason= to specify a maximum other than 1 or infinity.

When I have come across other limits, I have pretty = much always found them to be wrong. Take the requirement to have two author= itative servers for a DNS zone (not enforced by the protocol but enforced b= y the social infrastructure around it). That seemed such a good idea to me = till I found the two authoritative servers for the MIT LCS/AI running on a = couple of sparc stations plugged into the same wall socket.


The less twiddles and curlicues, the better.
=

Validation is not useful for a= data schema. It is useful for a document schema because it allows an intel= ligent editor to tell the user if they are filling in what really amounts t= o a form correctly.=C2=A0


My other = objection is to the use of JSON syntax and the limitation to JSON encoding.= I don't see a reason to limit scope to one encoding. I write my system= s using a schema language that is at least in principle capable of targetin= g ASN.1 and XML as well as JSON. This approach only allows me a subset of t= he capabilities of ASN.1 and XML schema which is exactly the point.



On Sun, Jan 21, 2018 at 5:21 PM= , Rob Sayre <sayrer@gmail.com> wrote:
Hi all.

There are much more = efficient and unambiguous formats available if there's a schema at hand= .

thanks,
Rob


On Sun, Jan 21, 2018 at= 2:11 PM, Henry Andrews <henry@cloudflare.com> wrote:
=
The f= ull set of current documents is on the web page:

http://json-schema.org= /specification.html

The first set of links (in the ta= ble) go to locally hosted renderings of each document.
Beneath tha= t, there are links to the IETF-hosted documents.

If you want t= o see why the numbering is so incredibly confusing, there's a "Spe= cification LInks" page linked under "Older Drafts"

-henry

<= span>
On Sat, Jan 20, 2018 at 2:59 PM, Paul H= offman <paul.hoffman@vpnc.org> wrote:
On 20 Jan 2018, at 13:25, Henry Andrews wrote:

Hi folks,
=C2=A0 I'm one of the JSON Schema draft editors, and it's been brou= ght to our
attention that the JSON Schema project may fit within this working group (or a successor?=C2=A0 I'm a little confused as to the current status a= nd scope
of this group).

The WG is closed and thus has no charter. If you want an IETF WG for JSON S= chema, it would need to be a new WG. The new WG could be chartered just to = work on JSON Schema, and not every other JSON-y idea that comes by.

=C2=A0 The current draft is draft-07 (although the actual IETF numbering is=
complicated).=C2=A0 So draft-02 was a very long time ago :-)

Could you point to the actual documents you are talking about? I see draft-= handrews-json-schema-00, which is not at -07,

--Paul Hoffman



--

_______________________________________________<= br> 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





--



--
=
--f403045e9f74c77c5f0563548460-- From nobody Sun Jan 21 19:53:18 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3F5126CC7 for ; Sun, 21 Jan 2018 19:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 kXnW5q6-EatU for ; Sun, 21 Jan 2018 19:53:14 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 60C4612025C for ; Sun, 21 Jan 2018 19:53:14 -0800 (PST) Received: from [169.254.236.117] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w0M3qv50093080 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 21 Jan 2018 20:52:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.236.117] From: "Paul Hoffman" To: "Henry Andrews" Cc: "JSON WG" Date: Sun, 21 Jan 2018 19:53:10 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: <4E44E944-B830-40EF-8E33-005BF5172CCA@vpnc.org> In-Reply-To: References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Json] JSON Schema 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, 22 Jan 2018 03:53:16 -0000 A few procedural notes to correct some misunderstandings. (Wearing no hats, just lots of scars from earlier IETF work on JSON and lots of other data formats...) On 21 Jan 2018, at 18:48, Henry Andrews wrote: > So... the point of me sending this email was to answer a request made > to > the JSON Schema project that I investigate the working group. The > clear > answer to that is that this working group is closed, and a new one > would > need to be chartered. If you want an IETF standard, yes. > It's not clear to me that we would want to charter > such a group now, although I would be interested in anyone's input on > that. There appears to be interest in something around schema for JSON; it is not clear if there is interest in starting from the specific spec at https://github.com/json-schema-org/json-schema-spec. I bet there is some interest in that, and some interest in something else. This is quite typical of requests for the IETF to adopt work that originated outside the IETF, with mixed results in any of of "adopt with the intention of making only minor changes", "adopt and make major changes", and "start from scratch while getting inspiration from the existing work". The IETF sucks at this, as do most other SDOs. We're just more public about our suckage. > There are several projects > underway in the same general space, some with quite a bit of momentum > of > their own. One of them may be a better choice for an IETF working > group, > I'm not in a position to say one way or the other. None of us are; that's what consensus is for. > Filing issues or asking questions on our slack channel will probably > work > better than hi-jacking this mailing list, now that I understand it is > no > longer active. :-) What you have done is *not* hijacking this mailing list: it's a completely appropriate use of it. And the list is active, as you have just seen. It's just not an IETF WG any more. > I would be interested in pursuing the IETF process (heavyweight or > not) It will be the former :-( > , if > there is interest from the appropriate segment of the IETF community. This list is a good proxy for that appropriate segment. Everyone who is interested in this topic should feel free to use the mailing list for it. --Paul Hoffman From nobody Sun Jan 21 20:24:09 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7BC1270A3 for ; Sun, 21 Jan 2018 20:24:07 -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, 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 (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIccuEQml3tV for ; Sun, 21 Jan 2018 20:24:05 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5160D12704A for ; Sun, 21 Jan 2018 20:24:05 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id f71so13742415wmf.0 for ; Sun, 21 Jan 2018 20:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r4HmlU3LlA3YAvGCrUaK4GLzRs/s0Vh86gdmftKr4DU=; b=JngRYRDH5ae4pl22L/jkqq/gSnYqdBVk6aD+bYVoaKo8FYXB8tCRnDRM1GzKmLrBfQ LFBuADt3b9E2s7jYJzSNoPlOi5ab8e8NcKOz6H2ZxxsuZ1KQo+akmsQpm5NFYO8j7JHU jseRUnHL5ZduqX7m4tzqf4WNzaJED24Da64Ic= 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=r4HmlU3LlA3YAvGCrUaK4GLzRs/s0Vh86gdmftKr4DU=; b=gZ4ytDXKD2vDXB9Xj5D/AQ8bKh7WafQ5giY4cTvkIPkt/4Gjwe7cRrlKx7xdREkVD+ WKvZ3S4BcXwCsSw+dBO6vUpYVh0H038nYx0VeoyOFis94A94DSHhWzECUEV+TJsW1V51 poH+OlvRiWN/8KoBC9lECQ+lFwThbwmZRDS2w2GdiFGY+egDqPO1tyNg4kz7PRf6J4sK 11SRCgT/FlILSrqGbv7aGRn39A17d/ESAKmiLlSLc00huMNL0TtUY8qLs0fkl6zoBVBl Ta6J/L/WiIDd0z9RApucz8RVT+183rrwdPnPeG7anv8DAD7Hvjp0YPy1KVjmU/d2AWLu aECA== X-Gm-Message-State: AKwxytd5oYhxm6UGVwSLu7uAAIDJvALeDtFh7MvhnLUygTPtdLgbB8Ej rSZb5Jf6vNhUwaLucZ1RNdmFVgpen+ZKirvSJQDYhKWf X-Google-Smtp-Source: AH8x2274tmoVhZQprIwd4xkm1Y0PJjkZJqoZwCRtHwL24OQSB1i54wtHenANrDvfZ79ZqzcoivEpFC841wUgMCoTmDM= X-Received: by 10.28.181.72 with SMTP id e69mr3646169wmf.7.1516595043714; Sun, 21 Jan 2018 20:24:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.4 with HTTP; Sun, 21 Jan 2018 20:23:43 -0800 (PST) In-Reply-To: <4E44E944-B830-40EF-8E33-005BF5172CCA@vpnc.org> References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> <4E44E944-B830-40EF-8E33-005BF5172CCA@vpnc.org> From: Henry Andrews Date: Sun, 21 Jan 2018 20:23:43 -0800 Message-ID: To: Paul Hoffman Cc: JSON WG Content-Type: multipart/alternative; boundary="001a1148dec0d95e38056355ccd7" Archived-At: Subject: Re: [Json] JSON Schema 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, 22 Jan 2018 04:24:08 -0000 --001a1148dec0d95e38056355ccd7 Content-Type: text/plain; charset="UTF-8" Thanks, Paul, this is very helpful. My inclination for now is for JSON Schema to continue on its current course as we are. I do not think the current set of drafts are the right base to start from. Again, this just my personal view, but I'd like to work within the JSON Schema community on its own more to solve some of the most obvious problems before throwing it in a blender with other proposals. I had not intended on contacting the IETF about a working group for at least two more drafts- I only started this thread due to a request. There is also the question of whether I would be the right point person for bringing JSON Schema into a working group. I'm not sure I would be, so if someone else steps up in the meantime or wants to start working on some schema system and use JSON Schema as it is as one input, I would be fine with that. Honestly, nearly every comment from anyone (here or elsewhere) that I've heard about the working group process has, um... not really excited me about it. So I think I'll keep doing what I'm doing, and note that I'm happy to help if someone else wants to lead a schema working group of some sort. If no one steps up, I may eventually do so. Otherwise I need to spend some time thinking about which paths forward would be best for the JSON Schema community. And if a schema working group emerges and goes in a different direction, I can look at how to help the JSON Schema community transition towards that. thanks, -henry On Sun, Jan 21, 2018 at 7:53 PM, Paul Hoffman wrote: > A few procedural notes to correct some misunderstandings. (Wearing no > hats, just lots of scars from earlier IETF work on JSON and lots of other > data formats...) > > On 21 Jan 2018, at 18:48, Henry Andrews wrote: > > So... the point of me sending this email was to answer a request made to >> the JSON Schema project that I investigate the working group. The clear >> answer to that is that this working group is closed, and a new one would >> need to be chartered. >> > > If you want an IETF standard, yes. > > It's not clear to me that we would want to charter >> such a group now, although I would be interested in anyone's input on >> that. >> > > There appears to be interest in something around schema for JSON; it is > not clear if there is interest in starting from the specific spec at > https://github.com/json-schema-org/json-schema-spec. I bet there is some > interest in that, and some interest in something else. This is quite > typical of requests for the IETF to adopt work that originated outside the > IETF, with mixed results in any of of "adopt with the intention of making > only minor changes", "adopt and make major changes", and "start from > scratch while getting inspiration from the existing work". > > The IETF sucks at this, as do most other SDOs. We're just more public > about our suckage. > > There are several projects >> underway in the same general space, some with quite a bit of momentum of >> their own. One of them may be a better choice for an IETF working group, >> I'm not in a position to say one way or the other. >> > > None of us are; that's what consensus is for. > > Filing issues or asking questions on our slack channel will probably work >> better than hi-jacking this mailing list, now that I understand it is no >> longer active. :-) >> > > What you have done is *not* hijacking this mailing list: it's a completely > appropriate use of it. And the list is active, as you have just seen. It's > just not an IETF WG any more. > > I would be interested in pursuing the IETF process (heavyweight or not) >> > > It will be the former :-( > > , if >> there is interest from the appropriate segment of the IETF community. >> > > This list is a good proxy for that appropriate segment. Everyone who is > interested in this topic should feel free to use the mailing list for it. > > --Paul Hoffman > -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --001a1148dec0d95e38056355ccd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --f4030435be949d1e09056378dbf3-- From nobody Tue Jan 23 15:24:43 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5529612D941 for ; Tue, 23 Jan 2018 15:24:42 -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, 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=hxr-us.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 gxLO08ZuBixv for ; Tue, 23 Jan 2018 15:24:40 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 2E67012D93E for ; Tue, 23 Jan 2018 15:24:40 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id m11so2826113iob.2 for ; Tue, 23 Jan 2018 15:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U2x7aTqMi2Vm8bzCEXaYgqlJo0XVFbp9jpWBiwfzpJo=; b=aODHimDp9zibDmwtQ5o4TZkwV2kfP5vhlxSYT0PyjYDbgwrsuD8rBjRKsJc5KNsRFm V9i9b74KHgFadAEFMM1Q1UgnT/EYZPwqIJAzgNgQqca0yqcE+Ai0M0G7kqR5UQU296IV b6NwxrUbEEUJJYPjq2eNS31LExDw2DQGVjO3L/Cv+lBd8+xrZoz5cgR+dpFF0A1e1Rb0 v3lbgTPQknAKSOVJSjbjEUSOQsKYcCqzI+fjIGwImLHXgF4z5d9MqUNTC9oS5qLWDL25 1jtfEHY6uiI/8gSq6f4Tw70Zb1aGhqCHjmj87dJKdIGuDAdAlkiMzwRLzNn7SSpR2aoT UzYg== 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=U2x7aTqMi2Vm8bzCEXaYgqlJo0XVFbp9jpWBiwfzpJo=; b=nE4p2OP9XPMNzRSduNffptBWV6THzf8ts0KwNYCXQqoYaep5NLcKnSWrFbmktJvFYV 5tfdVIOnX/CGK1W1kpyQHuNyxRH4rJcBhjbLugu/o26Df8OGoQbfA71WxsCCsCz6YwE9 6sFjUk/zus5E1dIEVnu+f3tPMGOV7kMz3Cx+HY+mHXA7qbEPDQK8MrTxtE/rFrpQYpbn JyeivuPr4i+nFJjxjvOTaf/GLo2Ym/Uc+4yrgRoJjMVwe0Dgzu//dJdIPd+RzfPvxz+7 oMVHAnoN3rnRPIFhMhiuBei05FPzNoN0OkKrLcWkauLyZiTWnzBfABEe+1ENOrdNv3bW xdLg== X-Gm-Message-State: AKwxytc3XHKsITMgQ8zUrc4ftkwfuFR2tLQauh4Af/LeP2XspPVM6YhQ Ka3yAFqqzydeqqKcjICrm3J2CKQd806L+AYNpcg7BraJ X-Google-Smtp-Source: AH8x224h+vNPq+e+OVTWQL4VFyOGKNGzKjoakzz5CbZsY5xTYWO4KjB08V3LlmErHNbxMBJh11Y9BwyyARqquQHBEpE= X-Received: by 10.107.48.68 with SMTP id w65mr6226727iow.84.1516749879420; Tue, 23 Jan 2018 15:24:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.132.165 with HTTP; Tue, 23 Jan 2018 15:24:38 -0800 (PST) X-Originating-IP: [192.136.136.238] In-Reply-To: References: From: Andrew Newton Date: Tue, 23 Jan 2018 18:24:38 -0500 Message-ID: To: Daniel P Cc: JSON WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Json] JSON Content Rules 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, 23 Jan 2018 23:24:42 -0000 Daniel, It's not a compromise well-loved by anyone, for sure. With hopes that I'm explaining this correctly, the basic issue is that without a statement termination character it is difficult for a parser to differentiate between an assignment of a string and the assignment of a member as they both start with the same syntax (a quoted string). As chance would have it, an alternative is in the works. https://github.com/arineng/jcrvalidator/issues/112 Is that a suitable fix? We're open to feedback. -andy On Tue, Jan 23, 2018 at 5:13 PM, Daniel P wrote: > Hello everyone, > > I would like to solicit feedback from members of this forum on one feature > of the JSON Content Rules specification, draft 09, as I'm considering to > build an implementation. > > The specification states: "There are two forms of rule name assignments: > assignments of primitive types and assignments of all other types. Rule > name assignments to primitive type specifications [e.g. string] separate the > rule name from the type specification with the character sequence '=:', > whereas rule name assignments for all other type specifications [e.g. > array] only require the separation using the '=' character ... This syntax > is necessary so that JCR parsers may readily distinguish between rule name > assignments involving string and regular expressions primitive types and > member names of member specifications." > > An example (I hope I have this right): > > { $bar-name : $bar-val, "foo" : $foo-val } > > ; member name specification > $bar-name = /^bar[0-9]$/ > > ; primitive type specification > $foo-val =: "foo" > > ; non primitive type specification > $bar-val = [ integer, integer, integer ] > > In what otherwise appears to me to be a fairly clean specification, I'm > having some difficulty digesting this syntax, with "=" if such and such, and > "=:" if so and so. I would be interested if anyone else on this list has any > thoughts about this. > > Thanks, > Daniel Parker > https://github.com/danielaparker/jsoncons > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Wed Jan 24 04:19:24 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AA812025C for ; Wed, 24 Jan 2018 04:19:23 -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, 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 nHSLQjwG0NHe for ; Wed, 24 Jan 2018 04:19:20 -0800 (PST) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171971200F1 for ; Wed, 24 Jan 2018 04:19:19 -0800 (PST) Received: (qmail 10880 invoked from network); 24 Jan 2018 12:09:33 +0000 Received: from host86-137-73-204.range86-137.btcentralplus.com (HELO ?192.168.1.72?) (86.137.73.204) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 24 Jan 2018 12:09:33 +0000 To: Daniel P , JSON WG References: From: Pete Cordell Message-ID: Date: Wed, 24 Jan 2018 12:19:14 +0000 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-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON Content Rules 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, 24 Jan 2018 12:19:23 -0000 Hi Daniel, As Andy said, it's been bugging us too. The fundamental problem is (was!) that a quoted string (e.g. "foo") can either be a member name or a string value. Also, a regex (e.g. /bar/) could either be a member name regex or a value regex. The ambiguity could potentially be resolved with back tracking in the parser, but I've wanted to try to make JCR as simple to parse as possible in the hope that this will facilitate its adoption. (I think what I've been promoting is called an LR(1) grammar.) Hence the approach of adding the extra ':' or 'type' token to do the disambiguation. The new change linked to by Andy at https://github.com/arineng/jcrvalidator/issues/112 essentially disambiguates this by adopting slightly different syntax for the various uses. So we've ended up with: "foo" - A member name (but see caveat below) 'bar' - A string value (new syntax, but also see below) /^baz\d+$/ - A regex value `biff\d+` - A member name regex (new syntax) Now the various usages are unambiguous, and we don't need the colon to differentiate whether a quoted string is a member name or value, etc. Now to the caveat... We wanted to still allow JCR to be a superset of JSON syntax (to facilitate easy creation of JCR from example JSON). So we wanted to allow: { "name" : "Fred" } Hence, in situations where the parser has read a member name and colon, and knows that what follows is a value, a string value can either be single quoted or double quoted; 'Fred' or "Fred". The result is that the following are all valid: $r1 = "name" : "Fred" ; A member rule $r2 = "name" : 'Fred' ; Also a member rule $r3 = 'Fred' ; A string value $r4 = /^Fred/' ; A regex value $r5 = `p[0-9]` : integer ; Member rule with regex name $r6 = string ; The big win - Colon no longer needed The following would be an error: $e1 = "Fred" $e2 = string because when parsing $e1 and seeing "Fred", the parsing would interpret "Fred" as a member name, and therefore complain when encountering $e2 without first seeing a colon. (You'd have to do the following instead: $e1 = 'Fred' $e2 = string) Personally I think the revision is a lot neater than what we had, and I hope it's not too difficult for developers to grok. I look forward to your comments. Thanks, Pete. -- --------------------------------------------------------------------- Pete Cordell http://www.xml2cpp.com --------------------------------------------------------------------- On 23/01/2018 22:13, Daniel P wrote: > Hello everyone, > > I would like to solicit feedback from members of this forum on one > feature of the JSON Content Rules specification, draft 09 > , > as I'm considering to build an implementation. > > The specification states: "There are two forms of rule name assignments: > assignments of  primitive types and assignments of all other types. > Rule name assignments to primitive type specifications [e.g. string] > separate the rule name from the type specification with the character > sequence '=:', whereas  rule name assignments for all other type > specifications [e.g. array] only require the separation using the '=' > character ... This syntax is necessary so  that JCR parsers may readily > distinguish between rule name assignments involving string and regular > expressions primitive types and member names of member specifications." > > An example (I hope I have this right): > > { $bar-name : $bar-val, "foo" : $foo-val } > > ; member name specification > $bar-name = /^bar[0-9]$/ > > ; primitive type specification > $foo-val =: "foo" > > ; non primitive type specification > $bar-val = [ integer, integer, integer ] > > In what otherwise appears to me to be a fairly clean specification, I'm > having some difficulty digesting this syntax, with "=" if such and such, > and "=:" if so and so. I would be interested if anyone else on this list > has any thoughts about this. > > Thanks, > Daniel Parker > https://github.com/danielaparker/jsoncons > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > From nobody Wed Jan 24 05:11:21 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACEE12D94E for ; Wed, 24 Jan 2018 05:11:20 -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 JIAHMi2BuSad for ; Wed, 24 Jan 2018 05:11:18 -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 C514012421A for ; Wed, 24 Jan 2018 05:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0ODBCj1026864; Wed, 24 Jan 2018 14:11:12 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (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 3zRQXc2VxrzDWtT; Wed, 24 Jan 2018 14:11:12 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: Date: Wed, 24 Jan 2018 14:11:11 +0100 Cc: Daniel P , JSON WG X-Mao-Original-Outgoing-Id: 538492270.27095-4d9739417255fe75bce36e3c02e09584 Content-Transfer-Encoding: quoted-printable Message-Id: <3600B43A-97D5-406C-AE85-8BF90F577B75@tzi.org> References: To: Pete Cordell X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Json] JSON Content Rules 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, 24 Jan 2018 13:11:20 -0000 On Jan 24, 2018, at 13:19, Pete Cordell wrote: >=20 > "foo" - A member name (but see caveat below) > 'bar' - A string value (new syntax, but also see below) > /^baz\d+$/ - A regex value > `biff\d+` - A member name regex (new syntax) Hmm. > We wanted to still allow JCR to be a superset of JSON syntax (to = facilitate easy creation of JCR from example JSON). So we wanted to = allow: >=20 > { "name" : "Fred" } Right. In JSON, a string is a string=E2=80=A6 What is the syntactical feature of JCR that makes this distinction = necessary? Maybe you can fix that feature instead? (When we designed CDDL, we didn=E2=80=99t have to make a distinction = between string values destined as member names and string values = destined as member values =E2=80=94 indeed strings are strings. Now the = CDDL syntax is very simple and does not leave any ambiguity as to = whether we are talking about a member name or a member value; I = haven=E2=80=99t looked at JCR recently enough to answer my own question = here.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 24 05:36:13 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ACF12422F for ; Wed, 24 Jan 2018 05:36:13 -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, 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 domtUbLjwfZU for ; Wed, 24 Jan 2018 05:36:11 -0800 (PST) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5818E124207 for ; Wed, 24 Jan 2018 05:36:11 -0800 (PST) Received: (qmail 12563 invoked from network); 24 Jan 2018 13:26:25 +0000 Received: from host86-137-73-204.range86-137.btcentralplus.com (HELO ?192.168.1.72?) (86.137.73.204) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 24 Jan 2018 13:26:25 +0000 To: Carsten Bormann Cc: Daniel P , JSON WG References: <3600B43A-97D5-406C-AE85-8BF90F577B75@tzi.org> From: Pete Cordell Message-ID: <3534e266-e344-8d49-12af-df946f5255f3@codalogic.com> Date: Wed, 24 Jan 2018 13:36:07 +0000 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: <3600B43A-97D5-406C-AE85-8BF90F577B75@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON Content Rules 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, 24 Jan 2018 13:36:13 -0000 On 24/01/2018 13:11, Carsten Bormann wrote: > On Jan 24, 2018, at 13:19, Pete Cordell wrote: >> >> "foo" - A member name (but see caveat below) >> 'bar' - A string value (new syntax, but also see below) >> /^baz\d+$/ - A regex value >> `biff\d+` - A member name regex (new syntax) > > Hmm. > >> We wanted to still allow JCR to be a superset of JSON syntax (to facilitate easy creation of JCR from example JSON). So we wanted to allow: >> >> { "name" : "Fred" } > > Right. In JSON, a string is a string… ...disambiguated by context. Where such disambiguating context isn't present, we give a little help via syntax. > What is the syntactical feature of JCR that makes this distinction necessary? > Maybe you can fix that feature instead? > > (When we designed CDDL, we didn’t have to make a distinction between string values destined as member names and string values destined as member values — indeed strings are strings. Now the CDDL syntax is very simple and does not leave any ambiguity as to whether we are talking about a member name or a member value; I haven’t looked at JCR recently enough to answer my own question here.) Likewise, I need another look at CDDL. Pete. From nobody Wed Jan 24 06:26:35 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B99D1243F6 for ; Wed, 24 Jan 2018 06:26: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 bD2lj9HaFsPj for ; Wed, 24 Jan 2018 06:26:31 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 3A6A4124C27 for ; Wed, 24 Jan 2018 06:26:31 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id x4so3704448otg.7 for ; Wed, 24 Jan 2018 06:26:31 -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=2GhW1KnamcGxflet4AJG2nHjoMVeCYFyU3VT5+8S7J4=; b=AbXX0hgKtin/eA41T3F+bs7BRcxYzz4K0L3PVQEGxWLpNM81QiEU1mhufU0A3G4CJv IG1N0YswhOnrT8UNpkqWoEQ1jampIIqwDuqo1Nnpmo5PVQP5LKFVN9VLiQflKiS0CX16 5AKhVFLjvvDnvJ0BAeWrSHNOcNmjc7XEvW73/0KXcmSnPqKBnOUyyKZLVHkpmVjw3q/1 fdVF5GhNmL3Iyzl+pxhVwYblnP7BBBlMShOaqHWwt6d9JBKjnBxDPWS60LoSSkc5iq/q V8lXy/N0ELHYFCTs/OH/iE7sDGMM49SfrrnW+0R9X68MIlVy65+rxUw6azgfyCWXb6+4 Pj2w== 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=2GhW1KnamcGxflet4AJG2nHjoMVeCYFyU3VT5+8S7J4=; b=NNDW2fH6n7WELdo6+rPzUYUzhP0uYiiZVS9TSqRwa71akzKg/OgGvHatx2Dn1UfHfK P1ToiU3/8usDXSW9aa5Hq/2VwTVzrY4SdGqxBLsHiC/DfYjf8JxRKZ442fSWK8pmwZns nu0n1mDvEQDj2YIKPJOgtkQJBsYRIC8/N3UpCDJ7+xE4UAZOc671v/tH4dKI+W86V7VJ WqUzYc8qxgrd5OYM4hvnmjuOtJNCbtnoOaOiJDBtVHBnjLPCTfpaplJDODXU+Lx8sLW0 WUjKgyfQgMql8uOE3Qk7xPFbeaAx4NAtfsVJspZCTHA1X1W9sNh1O+fxIWMbuxbfKJjD 2mhg== X-Gm-Message-State: AKwxytcC/Px/j3ArppBp1rLR6dmvyDOH+znuZ4NwXh/iqxwG2cN3yQqd HtpVUqKYUQwQiC781tg73GoQVVp51eJ8xkXcrMWLJg== X-Google-Smtp-Source: AH8x225C0Z3fBT0x8xaHTwuHiGX3PPv+8PS7+tOLok8OX+v5bKcS8M/vvFLbFNUevBGwx8Z6pY1Nzrwa94BM7ikCLOw= X-Received: by 10.157.69.138 with SMTP id x10mr11010500ote.252.1516803990343; Wed, 24 Jan 2018 06:26:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.27.139 with HTTP; Wed, 24 Jan 2018 06:26:30 -0800 (PST) In-Reply-To: References: From: Daniel P Date: Wed, 24 Jan 2018 09:26:30 -0500 Message-ID: To: Pete Cordell Cc: JSON WG Content-Type: multipart/alternative; boundary="089e082cb7d009d3ce0563867318" Archived-At: Subject: Re: [Json] JSON Content Rules 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, 24 Jan 2018 14:26:34 -0000 --089e082cb7d009d3ce0563867318 Content-Type: text/plain; charset="UTF-8" A problem with both the original specification and the suggested revisions is that they both involve adding inconsistent bits of syntax to resolve ambiguities, "=" if such and such and "=": if so and so, or a double quote if such and such and a single one if so and so. A user's mind rebels against that. I don't understand why it's necessary to have a distinction between name rule specifications and value rule specifications at all. The user may express something impossible by writing { $bar : $foo } $bar = [ integer, integer, integer ] $foo = "foo" but who cares? it's going to get caught. On Wed, Jan 24, 2018 at 7:19 AM, Pete Cordell wrote: > Hi Daniel, > > As Andy said, it's been bugging us too. > > The fundamental problem is (was!) that a quoted string (e.g. "foo") can > either be a member name or a string value. Also, a regex (e.g. /bar/) > could either be a member name regex or a value regex. > > The ambiguity could potentially be resolved with back tracking in the > parser, but I've wanted to try to make JCR as simple to parse as possible > in the hope that this will facilitate its adoption. (I think what I've > been promoting is called an LR(1) grammar.) Hence the approach of adding > the extra ':' or 'type' token to do the disambiguation. > > The new change linked to by Andy at https://github.com/arineng/jcr > validator/issues/112 essentially disambiguates this by adopting slightly > different syntax for the various uses. So we've ended up with: > > "foo" - A member name (but see caveat below) > 'bar' - A string value (new syntax, but also see below) > /^baz\d+$/ - A regex value > `biff\d+` - A member name regex (new syntax) > > Now the various usages are unambiguous, and we don't need the colon to > differentiate whether a quoted string is a member name or value, etc. > > Now to the caveat... > > We wanted to still allow JCR to be a superset of JSON syntax (to > facilitate easy creation of JCR from example JSON). So we wanted to allow: > > { "name" : "Fred" } > > Hence, in situations where the parser has read a member name and colon, > and knows that what follows is a value, a string value can either be single > quoted or double quoted; 'Fred' or "Fred". > > The result is that the following are all valid: > > $r1 = "name" : "Fred" ; A member rule > $r2 = "name" : 'Fred' ; Also a member rule > $r3 = 'Fred' ; A string value > $r4 = /^Fred/' ; A regex value > $r5 = `p[0-9]` : integer ; Member rule with regex name > $r6 = string ; The big win - Colon no longer needed > > The following would be an error: > > $e1 = "Fred" $e2 = string > > because when parsing $e1 and seeing "Fred", the parsing would interpret > "Fred" as a member name, and therefore complain when encountering $e2 > without first seeing a colon. (You'd have to do the following instead: $e1 > = 'Fred' $e2 = string) > > Personally I think the revision is a lot neater than what we had, and I > hope it's not too difficult for developers to grok. I look forward to your > comments. > > Thanks, > > Pete. > -- > --------------------------------------------------------------------- > Pete Cordell > http://www.xml2cpp.com > --------------------------------------------------------------------- > On 23/01/2018 22:13, Daniel P wrote: > >> Hello everyone, >> >> I would like to solicit feedback from members of this forum on one >> feature of the JSON Content Rules specification, draft 09 < >> https://datatracker.ietf.org/doc/draft-newton-json-content- >> rules/?include_text=1>, as I'm considering to build an implementation. >> >> The specification states: "There are two forms of rule name assignments: >> assignments of primitive types and assignments of all other types. Rule >> name assignments to primitive type specifications [e.g. string] separate >> the rule name from the type specification with the character sequence '=:', >> whereas rule name assignments for all other type specifications [e.g. >> array] only require the separation using the '=' character ... This syntax >> is necessary so that JCR parsers may readily distinguish between rule name >> assignments involving string and regular expressions primitive types and >> member names of member specifications." >> >> An example (I hope I have this right): >> >> { $bar-name : $bar-val, "foo" : $foo-val } >> >> ; member name specification >> $bar-name = /^bar[0-9]$/ >> >> ; primitive type specification >> $foo-val =: "foo" >> >> ; non primitive type specification >> $bar-val = [ integer, integer, integer ] >> >> In what otherwise appears to me to be a fairly clean specification, I'm >> having some difficulty digesting this syntax, with "=" if such and such, >> and "=:" if so and so. I would be interested if anyone else on this list >> has any thoughts about this. >> >> Thanks, >> Daniel Parker >> https://github.com/danielaparker/jsoncons >> >> >> >> _______________________________________________ >> json mailing list >> json@ietf.org >> https://www.ietf.org/mailman/listinfo/json >> >> --089e082cb7d009d3ce0563867318 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A problem with both the original specification and the sug= gested revisions is that they both involve adding inconsistent bits of synt= ax to resolve ambiguities, "=3D" if such and such and "=3D&q= uot;: if so and so, or a double quote if such and such and a single one if = so and so. A user's mind rebels against that.

I don&= #39;t understand why it's necessary to have a distinction between name = rule specifications and value rule specifications at all. The user may expr= ess something impossible by writing

{ $bar : $foo }

$bar =3D [ int= eger, integer, integer ]=C2=A0=C2=A0
$foo =3D "foo"
<= /div>

but who cares? it's going to get caught.<= /div>


On Wed, Jan 24, 2018 at 7:19 AM, Pete Cordell &l= t;petejson@coda= logic.com> wrote:
Hi Danie= l,

As Andy said, it's been bugging us too.

The fundamental problem is (was!) that a quoted string (e.g. "foo"= ;) can either be a member name or a string value.=C2=A0 Also, a regex (e.g.= /bar/) could either be a member name regex or a value regex.

The ambiguity could potentially be resolved with back tracking in the parse= r, but I've wanted to try to make JCR as simple to parse as possible in= the hope that this will facilitate its adoption.=C2=A0 (I think what I'= ;ve been promoting is called an LR(1) grammar.)=C2=A0 Hence the approach of= adding the extra ':' or 'type' token to do the disambiguat= ion.

The new change linked to by Andy at https://github= .com/arineng/jcrvalidator/issues/112 essentially disambiguates thi= s by adopting slightly different syntax for the various uses.=C2=A0 So we&#= 39;ve ended up with:

=C2=A0 =C2=A0"foo" - A member name (but see caveat below)
=C2=A0 =C2=A0'bar' - A string value (new syntax, but also see below= )
=C2=A0 =C2=A0/^baz\d+$/ - A regex value
=C2=A0 =C2=A0`biff\d+` - A member name regex (new syntax)

Now the various usages are unambiguous, and we don't need the colon to = differentiate whether a quoted string is a member name or value, etc.

Now to the caveat...

We wanted to still allow JCR to be a superset of JSON syntax (to facilitate= easy creation of JCR from example JSON).=C2=A0 So we wanted to allow:

=C2=A0 =C2=A0 { "name" : "Fred" }

Hence, in situations where the parser has read a member name and colon, and= knows that what follows is a value, a string value can either be single qu= oted or double quoted; 'Fred' or "Fred".

The result is that the following are all valid:

=C2=A0 =C2=A0 $r1 =3D "name" : "Fred" ; A member rule =C2=A0 =C2=A0 $r2 =3D "name" : 'Fred' ; Also a member rul= e
=C2=A0 =C2=A0 $r3 =3D 'Fred'=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; A = string value
=C2=A0 =C2=A0 $r4 =3D /^Fred/'=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; A regex val= ue
=C2=A0 =C2=A0 $r5 =3D `p[0-9]` : integer ; Member rule with regex name
=C2=A0 =C2=A0 $r6 =3D string=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; The big wi= n - Colon no longer needed

The following would be an error:

=C2=A0 =C2=A0 $e1 =3D "Fred" $e2 =3D string

because when parsing $e1 and seeing "Fred", the parsing would int= erpret "Fred" as a member name, and therefore complain when encou= ntering $e2 without first seeing a colon.=C2=A0 (You'd have to do the f= ollowing instead: $e1 =3D 'Fred' $e2 =3D string)

Personally I think the revision is a lot neater than what we had, and I hop= e it's not too difficult for developers to grok.=C2=A0 I look forward t= o your comments.

Thanks,

Pete.
--
-----------------------------------------------------------------= ----
Pete Cordell
htt= p://www.xml2cpp.com
-----------------------------------------------------------------= ----
On 23/01/2018 22:13, Daniel P wrote:
Hello everyone,

I would like to solicit feedback from members of this forum on one feature = of the JSON Content Rules specification, draft 09 <https://datatracker.ietf.org/doc/d= raft-newton-json-content-rules/?include_text=3D1>, as I'm c= onsidering to build an implementation.

The specification=C2=A0states: "There are two forms of rule name assig= nments: assignments of =C2=A0primitive types and assignments of all other t= ypes.=C2=A0 Rule name assignments to primitive type specifications [e.g. st= ring] separate the rule name from the type specification with the character= sequence '=3D:', whereas =C2=A0rule name assignments for all other= type specifications [e.g. array] only require the separation using the = 9;=3D' character ... This syntax is necessary so=C2=A0 that JCR parsers= may readily distinguish between rule name assignments involving string and= regular expressions primitive types and member names of member specificati= ons."

An example (I hope I have this right):

{ $bar-name : $bar-val, "foo" : $foo-val }

; member name specification
$bar-name =3D /^bar[0-9]$/

; primitive type specification
$foo-val =3D: "foo"

; non primitive type specification
$bar-val =3D [ integer, integer, integer ]

In what otherwise appears to me to be a fairly clean specification, I'm= having some difficulty digesting this syntax, with "=3D" if such= and such, and "=3D:" if so and so. I would be interested if anyo= ne else on this list has any thoughts about this.

Thanks,
Daniel Parker
https://github.com/danielaparker/jsoncons



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


--089e082cb7d009d3ce0563867318-- From nobody Wed Jan 24 08:09:27 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CE4126CF9 for ; Wed, 24 Jan 2018 08:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsbMigCWY6E5 for ; Wed, 24 Jan 2018 08:09:23 -0800 (PST) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7C31205D3 for ; Wed, 24 Jan 2018 08:09:23 -0800 (PST) Received: (qmail 15932 invoked from network); 24 Jan 2018 15:59:37 +0000 Received: from host86-137-73-204.range86-137.btcentralplus.com (HELO ?192.168.1.72?) (86.137.73.204) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 24 Jan 2018 15:59:37 +0000 To: Daniel P Cc: JSON WG References: From: Pete Cordell Message-ID: Date: Wed, 24 Jan 2018 16:09:19 +0000 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-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] JSON Content Rules 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, 24 Jan 2018 16:09:26 -0000 Hi Daniel, On 24/01/2018 14:26, Daniel P wrote: > A problem with both the original specification and the suggested > revisions is that they both involve adding inconsistent bits of syntax > to resolve ambiguities, "=" if such and such and "=": if so and so, or a > double quote if such and such and a single one if so and so. A user's > mind rebels against that. > > I don't understand why it's necessary to have a distinction between name > rule specifications and value rule specifications at all. The user may > express something impossible by writing > > { $bar : $foo } > > $bar = [ integer, integer, integer ] > $foo = "foo" It looks like there is a misunderstanding here (possibly of minor consequence, but worth clearing up). JCR works in terms of rules. So `$bar = [ integer, integer, integer ]` is a named rule (called 'bar' for those less familiar with JCR). It happens to be a value rule. There are also member rules, which consist of a member name and a value rule. JCR doesn't do macro substitution. So the `$name = ...` syntax is not specifying a macro that can be dropped into anywhere. So, currently, you can't do `{ $bar : $foo }` in JCR. Personally, I don't see this as a problem. I can see many cases where types need to be specified independent of the member names that use them. But I don't think there are many practical cases where a member name needs to be specified independent of its type. That said, that clarification probably doesn't change your main point. > but who cares? it's going to get caught. My background is C++. One aspect of that language is that it's hard to parse correctly. The consequence of that is that the tooling lacks well behind many other languages that are easier to parse. I don't want that to be the case for JCR. My theory is that, the easier it is to parse, the better the tools will be, with more consistency etc. Also, I want to make it easy to produce accurate, helpful error reports that will reduce the time developers need to work out what's wrong with their JCR. The structure of a rule can be pedantic, and with them parsers have a much better chance of saying "your error is here". Using a macros approach potentially means that the errors are detected well away from their source, which makes them harder to give helpful error messages for, and harder to fix. Normally I would push any complexities into the tool, and relieve the user of them as much as possible. But I don't see JCR as a multi-million dollar industry. More of a cottage industry akin to Bill's ABNF parser (https://tools.ietf.org/tools/bap/abnf.cgi). So it's a balance. Given the choice of better tools, and remembering to use single quotes; or worse tooling and not having to remember to use single quotes, I think developers would go for the former. Single quoted strings also helps the human developer. They can look at 'foo' and know it's a value. They don't have to look into the context of where it's used to work out whether it's a name or value. I hope that help, Pete. http://www.xml2cpp.com ---------------- old stuff for possible context ----------------------- > > On Wed, Jan 24, 2018 at 7:19 AM, Pete Cordell > wrote: > > Hi Daniel, > > As Andy said, it's been bugging us too. > > The fundamental problem is (was!) that a quoted string (e.g. "foo") > can either be a member name or a string value.  Also, a regex (e.g. > /bar/) could either be a member name regex or a value regex. > > The ambiguity could potentially be resolved with back tracking in > the parser, but I've wanted to try to make JCR as simple to parse as > possible in the hope that this will facilitate its adoption.  (I > think what I've been promoting is called an LR(1) grammar.)  Hence > the approach of adding the extra ':' or 'type' token to do the > disambiguation. > > The new change linked to by Andy at > https://github.com/arineng/jcrvalidator/issues/112 > essentially > disambiguates this by adopting slightly different syntax for the > various uses.  So we've ended up with: > >    "foo" - A member name (but see caveat below) >    'bar' - A string value (new syntax, but also see below) >    /^baz\d+$/ - A regex value >    `biff\d+` - A member name regex (new syntax) > > Now the various usages are unambiguous, and we don't need the colon > to differentiate whether a quoted string is a member name or value, etc. > > Now to the caveat... > > We wanted to still allow JCR to be a superset of JSON syntax (to > facilitate easy creation of JCR from example JSON).  So we wanted to > allow: > >     { "name" : "Fred" } > > Hence, in situations where the parser has read a member name and > colon, and knows that what follows is a value, a string value can > either be single quoted or double quoted; 'Fred' or "Fred". > > The result is that the following are all valid: > >     $r1 = "name" : "Fred" ; A member rule >     $r2 = "name" : 'Fred' ; Also a member rule >     $r3 = 'Fred'          ; A string value >     $r4 = /^Fred/'        ; A regex value >     $r5 = `p[0-9]` : integer ; Member rule with regex name >     $r6 = string          ; The big win - Colon no longer needed > > The following would be an error: > >     $e1 = "Fred" $e2 = string > > because when parsing $e1 and seeing "Fred", the parsing would > interpret "Fred" as a member name, and therefore complain when > encountering $e2 without first seeing a colon.  (You'd have to do > the following instead: $e1 = 'Fred' $e2 = string) > > Personally I think the revision is a lot neater than what we had, > and I hope it's not too difficult for developers to grok.  I look > forward to your comments. > > Thanks, > > Pete. > -- > --------------------------------------------------------------------- > Pete Cordell > http://www.xml2cpp.com > --------------------------------------------------------------------- > On 23/01/2018 22:13, Daniel P wrote: > > Hello everyone, > > I would like to solicit feedback from members of this forum on > one feature of the JSON Content Rules specification, draft 09 > >, > as I'm considering to build an implementation. > > The specification states: "There are two forms of rule name > assignments: assignments of  primitive types and assignments of > all other types.  Rule name assignments to primitive type > specifications [e.g. string] separate the rule name from the > type specification with the character sequence '=:', whereas >  rule name assignments for all other type specifications [e.g. > array] only require the separation using the '=' character ... > This syntax is necessary so  that JCR parsers may readily > distinguish between rule name assignments involving string and > regular expressions primitive types and member names of member > specifications." > > An example (I hope I have this right): > > { $bar-name : $bar-val, "foo" : $foo-val } > > ; member name specification > $bar-name = /^bar[0-9]$/ > > ; primitive type specification > $foo-val =: "foo" > > ; non primitive type specification > $bar-val = [ integer, integer, integer ] > > In what otherwise appears to me to be a fairly clean > specification, I'm having some difficulty digesting this syntax, > with "=" if such and such, and "=:" if so and so. I would be > interested if anyone else on this list has any thoughts about this. > > Thanks, > Daniel Parker > https://github.com/danielaparker/jsoncons > > > > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json > > > From nobody Wed Jan 24 09:51:08 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16C1270A3 for ; Wed, 24 Jan 2018 09:51:07 -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 lO41K7scJz-f for ; Wed, 24 Jan 2018 09:51:05 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 4694E12706D for ; Wed, 24 Jan 2018 09:51:05 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id d9so4316722oth.6 for ; Wed, 24 Jan 2018 09:51:05 -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=8sAAS2biPR2Lbr6u8Q6t33205BPO7c8HxzQ9OwR5Qxs=; b=V6KLnte0MsX9vNbOaToqtVGOsmigt6VoJfHYVSiRcR5lvM3zET+5uQqHk6o4uYHD1Q 2vg9eHQfsgARz8YwTvKpbdwSHOHSinZWsz1a+HQvnXCJfpdqvfsSHjJ7RB6/xZcf245/ jOvDPidvRm2WaXI08+OCq+IYCcMwE6DxcoYC9SJaTjbSudlGGlnbpeXQ4PG4QuhBioba HZ+t/U8V+OR/FEVHZTcdaDbON+pcR3sEwtvvnEaZ91x4Hb+wam+3sAbMmb1BMNV+CEhM cj10eT9+VvoeBrwweoLpEJAnlojANra/cg4iCJ/0kJVHX85sYR3uZMQX0tjDsrpIjqmZ WTaQ== 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=8sAAS2biPR2Lbr6u8Q6t33205BPO7c8HxzQ9OwR5Qxs=; b=kpBqByOvumGEWW93C+vpsUVfZ3zp8JTGvCPky+vA/7tbF8jteBQdQh2zVUYu47T7rq j51noSNfj1rWLap/oBygF3ZGyDwZERRjr2TmRGu0aZ/QztkWr0uDcYNIp83YJqqGxyJf SLasD5MMWxNjA1SQwPgwTcvQkPqhv9oYzOU0h2DlA3sADoxmUknK9i1F50PuQWgMPSBi yeZ9CcPSYtmYgtBJmkvRPC8wIDFlzjsayXXTMtUt2e7ky/yoKeB711h3xJqzIWtk8TwA YYs9in1NuONjXnVxa1LQZTPxhyEfAE3ANbfZVSO62jmc8RudyLAROTV7f6VfQ9uTDjXe 7Ncg== X-Gm-Message-State: AKwxytdJ+A4LsfE9tbbWapugNjH4DS+v8S9+eUMbw2FsYsxMdqwDOAIH paQQrLjcZs2izEjn/jBXaPR/zlZkw9qIvitsLOM= X-Google-Smtp-Source: AH8x225ZR2v1a0SF/oqvRgPmhyduvVw+pLhqiTtU6ZrV1cvJI/Bi/be++07sR0tfJw1yiYlFKe5kNBtYPYegdbnQPDg= X-Received: by 10.157.89.203 with SMTP id u11mr10474894otg.319.1516816264138; Wed, 24 Jan 2018 09:51:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.27.139 with HTTP; Wed, 24 Jan 2018 09:51:03 -0800 (PST) In-Reply-To: References: From: Daniel P Date: Wed, 24 Jan 2018 12:51:03 -0500 Message-ID: To: JSON WG Content-Type: multipart/alternative; boundary="f4030435be949d15780563894e12" Archived-At: Subject: [Json] Fwd: JSON Content Rules 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, 24 Jan 2018 17:51:07 -0000 --f4030435be949d15780563894e12 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 24, 2018 at 11:09 AM, Pete Cordell wrote: > JCR works in terms of rules ... JCR doesn't do macro substitution. Of course, but the issue is whether the grammar needs to distinguish between name rule specifications and value rule specifications. I don't think that it does, and I don't think that that provides any meaningful benefit to the user, compared to the loss in simplicity of the syntax. That's just my opinion, of course, but I would be interested to see what others on the list think. > My background is C++. Mine too, but if you want a C++ inspired solution, you might want to study the C++ rules for template method disambiguation :-) Daniel https://github.com/danielaparker/jsoncons --f4030435be949d15780563894e12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks, Paul, this is very helpfu= l.

My inclination for now is for JSON Schema to continue on it= s current course as we are.=C2=A0 I do not think the current set of drafts = are the right base to start from.=C2=A0 Again, this just my personal view, = but I'd like to work within the JSON Schema community on its own more t= o solve some of the most obvious problems before throwing it in a blender w= ith other proposals.=C2=A0 I had not intended on contacting the IETF about = a working group for at least two more drafts- I only started this thread du= e to a request.

There is also the question of whether I would = be the right point person for bringing JSON Schema into a working group.=C2= =A0 I'm not sure I would be, so if someone else steps up in the meantim= e or wants to start working on some schema system and use JSON Schema as it= is as one input, I would be fine with that.=C2=A0 Honestly, nearly every c= omment from anyone (here or elsewhere) that I've heard about the workin= g group process has, um... not really excited me about it.

So = I think I'll keep doing what I'm doing, and note that I'm happy= to help if someone else wants to lead a schema working group of some sort.= =C2=A0 If no one steps up, I may eventually do so.=C2=A0 Otherwise I need t= o spend some time thinking about which paths forward would be best for the = JSON Schema community.=C2=A0 And if a schema working group emerges and goes= in a different direction, I can look at how to help the JSON Schema commun= ity transition towards that.

thanks,
-henry


On Sun, Jan 2= 1, 2018 at 7:53 PM, Paul Hoffman <paul.hoffman@vpnc.org>= wrote:
A few procedural notes to correct= some misunderstandings. (Wearing no hats, just lots of scars from earlier = IETF work on JSON and lots of other data formats...)

On 21 Jan 2018, at 18:48, Henry Andrews wrote:

So... the point of me sending this email was to answer a request made to the JSON Schema project that I investigate the working group.=C2=A0 The cle= ar
answer to that is that this working group is closed, and a new one would need to be chartered.

If you want an IETF standard, yes.

It's not clear to me that we would want to charter
such a group now, although I would be interested in anyone's input on t= hat.

There appears to be interest in something around schema for JSON; it is not= clear if there is interest in starting from the specific spec at https://github.com/json-schema-org/json-schema-spec= . I bet there is some interest in that, and some interest in something = else. This is quite typical of requests for the IETF to adopt work that ori= ginated outside the IETF, with mixed results in any of of "adopt with = the intention of making only minor changes", "adopt and make majo= r changes", and "start from scratch while getting inspiration fro= m the existing work".

The IETF sucks at this, as do most other SDOs. We're just more public a= bout our suckage.

There are several projects
underway in the same general space, some with quite a bit of momentum of their own.=C2=A0 One of them may be a better choice for an IETF working gro= up,
I'm not in a position to say one way or the other.

None of us are; that's what consensus is for.

Filing issues or asking questions on our slack channel will probably work better than hi-jacking this mailing list, now that I understand it is no longer active. :-)

What you have done is *not* hijacking this mailing list: it's a complet= ely appropriate use of it. And the list is active, as you have just seen. I= t's just not an IETF WG any more.

I would be interested in pursuing the IETF process (heavyweight or not)

It will be the former :-(

, if
there is interest from the appropriate segment of the IETF community.

This list is a good proxy for that appropriate segment. Everyone who is int= erested in this topic should feel free to use the mailing list for it.

--Paul Hoffman



--
<= div>
--001a1148dec0d95e38056355ccd7-- From nobody Sun Jan 21 20:27:40 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8476012704A for ; Sun, 21 Jan 2018 20:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqdOvxarRIWk for ; Sun, 21 Jan 2018 20:27:35 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFA41241F8 for ; Sun, 21 Jan 2018 20:27:29 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id t16so7113208wrc.10 for ; Sun, 21 Jan 2018 20:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RQGmykCQQ1Qq7xP5YS1ySHotKwM4jOZrC5p3vI5jCYE=; b=CtNrayTdFaNCgj/8BdgxBkKoMAqnwiIZsqYdkH9jEBnKUZVK3eqyu3stdYKGz278M4 TIQhJ+D1ZWDjWQ0RZuZWKnRMo8yCe9uc32pa04eaRRCOuRdrJFn/rQQ3blH+D93WigQe Fcqb5LRl9V1JjvO112A3BkNLSX92aW6/nBb68= 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=RQGmykCQQ1Qq7xP5YS1ySHotKwM4jOZrC5p3vI5jCYE=; b=dRtlCrSHhm9EpFzpnRxwm5pANPmxiZ4MYF2u8wuC9VGv8PrYjw1/t+xK5/Ovyppn6s gdQCw2T0DkrDs8lKILMKToynq3TZP0hmx+F/HcABPA9uTxU/9q9zZJgnXInBe+LhkC2E kfp9P3Yhg+hoXjlV3snlbJd3JFeS3sDQar8y4jcw9h5HEzPbeYkqn55TQ6glYyGvmbdg CrYWSEnDQkXneIx4+GrKuZWD4nVI/cb8cXwxkmYdFlk3mOHMOy83sRG/LpikI0RGqZen LdB2/ZkdMu+17iVDptbFpjmRUfT0Lkf/uHl9rbaM/nSoWZfrti8TyvqYjOpc4OW91N0+ YrMA== X-Gm-Message-State: AKwxytePExZXSo5p0iZuUhbRTfZxc5ZctEMAaK0Gba7k2uJHF36DvNuG rM0t/oDzGE/QrPitwMG0RqImE2ZwuyKCSwzz5Gcalr3H X-Google-Smtp-Source: AH8x227utt7t5dHzrsao9a7xlG47uV0zx/7PtoaP5f5EtoGYlwB+QZWKYVdeA3Uzvua7vyew/9lm0aigrcZ3NS/LPP0= X-Received: by 10.223.155.196 with SMTP id e4mr5602789wrc.63.1516595248075; Sun, 21 Jan 2018 20:27:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.4 with HTTP; Sun, 21 Jan 2018 20:27:07 -0800 (PST) In-Reply-To: References: <1ECAA6AB-6A96-4E45-AB5C-22F53673FBE1@vpnc.org> <4E44E944-B830-40EF-8E33-005BF5172CCA@vpnc.org> From: Henry Andrews Date: Sun, 21 Jan 2018 20:27:07 -0800 Message-ID: To: Paul Hoffman Cc: JSON WG Content-Type: multipart/alternative; boundary="94eb2c1b686807a82f056355d93d" Archived-At: Subject: Re: [Json] JSON Schema 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, 22 Jan 2018 04:27:38 -0000 --94eb2c1b686807a82f056355d93d Content-Type: text/plain; charset="UTF-8" hmm- there's a bit in that last message that could be read as me assuming that I would lead a working group if I were interested in doing so. I am not making that assumption :-D On Sun, Jan 21, 2018 at 8:23 PM, Henry Andrews wrote: > Thanks, Paul, this is very helpful. > > My inclination for now is for JSON Schema to continue on its current > course as we are. I do not think the current set of drafts are the right > base to start from. Again, this just my personal view, but I'd like to > work within the JSON Schema community on its own more to solve some of the > most obvious problems before throwing it in a blender with other > proposals. I had not intended on contacting the IETF about a working group > for at least two more drafts- I only started this thread due to a request. > > There is also the question of whether I would be the right point person > for bringing JSON Schema into a working group. I'm not sure I would be, so > if someone else steps up in the meantime or wants to start working on some > schema system and use JSON Schema as it is as one input, I would be fine > with that. Honestly, nearly every comment from anyone (here or elsewhere) > that I've heard about the working group process has, um... not really > excited me about it. > > So I think I'll keep doing what I'm doing, and note that I'm happy to help > if someone else wants to lead a schema working group of some sort. If no > one steps up, I may eventually do so. Otherwise I need to spend some time > thinking about which paths forward would be best for the JSON Schema > community. And if a schema working group emerges and goes in a different > direction, I can look at how to help the JSON Schema community transition > towards that. > > thanks, > -henry > > > On Sun, Jan 21, 2018 at 7:53 PM, Paul Hoffman > wrote: > >> A few procedural notes to correct some misunderstandings. (Wearing no >> hats, just lots of scars from earlier IETF work on JSON and lots of other >> data formats...) >> >> On 21 Jan 2018, at 18:48, Henry Andrews wrote: >> >> So... the point of me sending this email was to answer a request made to >>> the JSON Schema project that I investigate the working group. The clear >>> answer to that is that this working group is closed, and a new one would >>> need to be chartered. >>> >> >> If you want an IETF standard, yes. >> >> It's not clear to me that we would want to charter >>> such a group now, although I would be interested in anyone's input on >>> that. >>> >> >> There appears to be interest in something around schema for JSON; it is >> not clear if there is interest in starting from the specific spec at >> https://github.com/json-schema-org/json-schema-spec. I bet there is some >> interest in that, and some interest in something else. This is quite >> typical of requests for the IETF to adopt work that originated outside the >> IETF, with mixed results in any of of "adopt with the intention of making >> only minor changes", "adopt and make major changes", and "start from >> scratch while getting inspiration from the existing work". >> >> The IETF sucks at this, as do most other SDOs. We're just more public >> about our suckage. >> >> There are several projects >>> underway in the same general space, some with quite a bit of momentum of >>> their own. One of them may be a better choice for an IETF working group, >>> I'm not in a position to say one way or the other. >>> >> >> None of us are; that's what consensus is for. >> >> Filing issues or asking questions on our slack channel will probably work >>> better than hi-jacking this mailing list, now that I understand it is no >>> longer active. :-) >>> >> >> What you have done is *not* hijacking this mailing list: it's a >> completely appropriate use of it. And the list is active, as you have just >> seen. It's just not an IETF WG any more. >> >> I would be interested in pursuing the IETF process (heavyweight or not) >>> >> >> It will be the former :-( >> >> , if >>> there is interest from the appropriate segment of the IETF community. >>> >> >> This list is a good proxy for that appropriate segment. Everyone who is >> interested in this topic should feel free to use the mailing list for it. >> >> --Paul Hoffman >> > > > > -- > > - > > *Henry Andrews* | Systems Engineer > henry@cloudflare.com > > > 1 888 99 FLARE | www.cloudflare.com > - > > -- - *Henry Andrews* | Systems Engineer henry@cloudflare.com 1 888 99 FLARE | www.cloudflare.com - --94eb2c1b686807a82f056355d93d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hmm- there's a bit in that last message that could be = read as me assuming that I would lead a working group if I were interested = in doing so.=C2=A0 I am not making that assumption :-D
 --94eb2c1b686807a82f056355d93d-- From nobody Tue Jan 23 14:13:39 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BB312D855 for ; Tue, 23 Jan 2018 14:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 XgrEhaOkCrmZ for ; Tue, 23 Jan 2018 14:13:36 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 2582C12D859 for ; Tue, 23 Jan 2018 14:13:36 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id t20so1846980ote.11 for ; Tue, 23 Jan 2018 14:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2ijLuIMzY/BVjRkDYgfp+iQmb8dtK7Mgdm0mbWFFIJI=; b=cELJoPkxrFEvsGGrfSD37AyFlO7h7T0o6/l7w4k8iw0NvxwOpivMlGrmg+SZrXY8pT ZwNTqFNCvgjK5JxC6j5GtlYpCCL9gz7ZIY0/N/mauJkELMXy7ScSQBjGw1WFkFByt574 51wKBQAs5kMk0U9JpXqrKOex+s5VCMkSjCS7epOjxvA+caUhj/C+jeKbBJze9D5M0TLi PA1kQ7dJWIol6cHez3UM0fh5MdXqIuqote6YkXLuqTsQldlnjVxFDFJpFF6M5ISeB6ry e1WQloGMQpqBeM2AlouFmMURo+tgFM254NofV5QSgPDNMa5QYxjTxZs96x7oBod/MJmV Arug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2ijLuIMzY/BVjRkDYgfp+iQmb8dtK7Mgdm0mbWFFIJI=; b=kmfbGdGkdvMpcwSDMCr7cUIcpEJZwwQALYfH5a/XHPwet0kQxeYLLHq/ALbS6TqMCV dP7zqc8uFiqwDgFvU1+mcD6xc9i7amBprszpWqWKrN9Yge1QSpjKnp69IiuntR2/MeXK au+aa3n+3fec6gUtt9arayeclsUoJ6AVqMsl6P11kNNmwHIl+g2xEtjUKokBESxIYYh6 nFy2tTplTgDv4PjLNsG7bHT7xHj/hLwZJfUCflM3lrNLkRzWceMB/ITcRFnuSft2JF/N mmUszQmitCuff65lcCxcJYAJyXvXvIOh8onfICcLh8fNCbyhCkcLIKzXX7Atj+F2d4PF OdMg== X-Gm-Message-State: AKwxytfaUL5EJk0bdpBQP0jiIKsWotofyGngMb6hbjQuCHZhpNByJXq4 SeAPkA0I7OeTTCWECoSNSCApWqdl2pQhtPn0ogGfSg== X-Google-Smtp-Source: AH8x224TOnmaKMdTHWWTKtUhEDzE9ZnZF9HY97fwIYNzMIgkw83WZM+dzufVd8FsUGa1UoFEKkzKwMR9eGPOUdcxAHI= X-Received: by 10.157.89.203 with SMTP id u11mr8632618otg.319.1516745615283; Tue, 23 Jan 2018 14:13:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.27.139 with HTTP; Tue, 23 Jan 2018 14:13:34 -0800 (PST) From: Daniel P Date: Tue, 23 Jan 2018 17:13:34 -0500 Message-ID: To: JSON WG Content-Type: multipart/alternative; boundary="f4030435be949d1e09056378dbf3" Archived-At: Subject: [Json] JSON Content Rules 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, 23 Jan 2018 22:13:38 -0000 --f4030435be949d1e09056378dbf3 Content-Type: text/plain; charset="UTF-8" Hello everyone, I would like to solicit feedback from members of this forum on one feature of the JSON Content Rules specification, draft 09 , as I'm considering to build an implementation. The specification states: "There are two forms of rule name assignments: assignments of primitive types and assignments of all other types. Rule name assignments to primitive type specifications [e.g. string] separate the rule name from the type specification with the character sequence '=:', whereas rule name assignments for all other type specifications [e.g. array] only require the separation using the '=' character ... This syntax is necessary so that JCR parsers may readily distinguish between rule name assignments involving string and regular expressions primitive types and member names of member specifications." An example (I hope I have this right): { $bar-name : $bar-val, "foo" : $foo-val } ; member name specification $bar-name = /^bar[0-9]$/ ; primitive type specification $foo-val =: "foo" ; non primitive type specification $bar-val = [ integer, integer, integer ] In what otherwise appears to me to be a fairly clean specification, I'm having some difficulty digesting this syntax, with "=" if such and such, and "=:" if so and so. I would be interested if anyone else on this list has any thoughts about this. Thanks, Daniel Parker https://github.com/danielaparker/jsoncons --f4030435be949d1e09056378dbf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

I would like= to solicit feedback from members of this forum on one feature of the JSON Content Rules specification, draft 09= , as I'm considering to build an implementation.=C2=A0
The specification=C2=A0states: "There are two forms of ru= le name assignments: assignments of =C2=A0primitive types and assignments o= f all other types.=C2=A0 Rule name assignments to primitive type specificat= ions [e.g. string] separate the rule name from the type specification with = the character sequence '=3D:', whereas =C2=A0rule name assignments = for all other type specifications [e.g. array] only require the separation = using the '=3D' character ... This syntax is necessary so=C2=A0 tha= t JCR parsers may readily distinguish between rule name assignments involvi= ng string and regular expressions primitive types and member names of membe= r specifications."

An example (I hope I h= ave this right):

{ $bar-name : $bar-val, "foo" : $foo= -val }

; member name specification
$bar-name =3D /^bar[0-9]$/
=
; primitive type specification
$foo-val =3D: "foo"

= ; non primitive type specification
$bar-val =3D [ integer, integer, inte= ger ]

In what otherwise appears to me to be = a fairly clean specification, I'm having some difficulty digesting this= syntax, with "=3D" if such and such, and "=3D:" if so = and so. I would be interested if anyone else on this list has any thoughts = about this.

Thanks,
Daniel Parker
<= div>https://github.co= m/danielaparker/jsoncons


On Sun, Jan 21, 2018 at 8:2= 3 PM, Henry Andrews <henry@cloudflare.com> wrote:
Thanks= , Paul, this is very helpful.

My inclination for now is for JS= ON Schema to continue on its current course as we are.=C2=A0 I do not think= the current set of drafts are the right base to start from.=C2=A0 Again, t= his just my personal view, but I'd like to work within the JSON Schema = community on its own more to solve some of the most obvious problems before= throwing it in a blender with other proposals.=C2=A0 I had not intended on= contacting the IETF about a working group for at least two more drafts- I = only started this thread due to a request.

There is also the q= uestion of whether I would be the right point person for bringing JSON Sche= ma into a working group.=C2=A0 I'm not sure I would be, so if someone e= lse steps up in the meantime or wants to start working on some schema syste= m and use JSON Schema as it is as one input, I would be fine with that.=C2= =A0 Honestly, nearly every comment from anyone (here or elsewhere) that I&#= 39;ve heard about the working group process has, um... not really excited m= e about it.

So I think I'll keep doing what I'm doing,= and note that I'm happy to help if someone else wants to lead a schema= working group of some sort.=C2=A0 If no one steps up, I may eventually do = so.=C2=A0 Otherwise I need to spend some time thinking about which paths fo= rward would be best for the JSON Schema community.=C2=A0 And if a schema wo= rking group emerges and goes in a different direction, I can look at how to= help the JSON Schema community transition towards that.

thank= s,
-henry


On Sun, Jan 21, 2018 at 7:53 PM, Paul Hoffman <paul.h= offman@vpnc.org> wrote:
A f= ew procedural notes to correct some misunderstandings. (Wearing no hats, ju= st lots of scars from earlier IETF work on JSON and lots of other data form= ats...)

On 21 Jan 2018, at 18:48, Henry Andrews wrote:

So... the point of me sending this email was to answer a request made to the JSON Schema project that I investigate the working group.=C2=A0 The cle= ar
answer to that is that this working group is closed, and a new one would need to be chartered.

If you want an IETF standard, yes.

It's not clear to me that we would want to charter
such a group now, although I would be interested in anyone's input on t= hat.

There appears to be interest in something around schema for JSON; it is not= clear if there is interest in starting from the specific spec at https://github.com/json-schema-org/json-schema-spec= . I bet there is some interest in that, and some interest in something = else. This is quite typical of requests for the IETF to adopt work that ori= ginated outside the IETF, with mixed results in any of of "adopt with = the intention of making only minor changes", "adopt and make majo= r changes", and "start from scratch while getting inspiration fro= m the existing work".

The IETF sucks at this, as do most other SDOs. We're just more public a= bout our suckage.

There are several projects
underway in the same general space, some with quite a bit of momentum of their own.=C2=A0 One of them may be a better choice for an IETF working gro= up,
I'm not in a position to say one way or the other.

None of us are; that's what consensus is for.

Filing issues or asking questions on our slack channel will probably work better than hi-jacking this mailing list, now that I understand it is no longer active. :-)

What you have done is *not* hijacking this mailing list: it's a complet= ely appropriate use of it. And the list is active, as you have just seen. I= t's just not an IETF WG any more.

I would be interested in pursuing the IETF process (heavyweight or not)

It will be the former :-(

, if
there is interest from the appropriate segment of the IETF community.

This list is a good proxy for that appropriate segment. Everyone who is int= erested in this topic should feel free to use the mailing list for it.

--Paul Hoffman



--



--
=
--f4030435be949d15780563894e12-- From nobody Thu Jan 25 01:16:02 2018 Return-Path: X-Original-To: json@ietfa.amsl.com Delivered-To: json@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2697912E870 for ; Thu, 25 Jan 2018 01:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVoa9LuP4rZC for ; Thu, 25 Jan 2018 01:15:53 -0800 (PST) Received: from ppsa-online.com (ppsa-online.com [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46A512DA08 for ; Thu, 25 Jan 2018 01:15:52 -0800 (PST) Received: (qmail 22137 invoked from network); 25 Jan 2018 09:06:07 +0000 Received: from host86-137-73-204.range86-137.btcentralplus.com (HELO ?192.168.1.72?) (86.137.73.204) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 25 Jan 2018 09:06:07 +0000 To: Daniel P , JSON WG References: From: Pete Cordell Message-ID: <794516b0-4579-51f8-50c8-7356bb200ab9@codalogic.com> Date: Thu, 25 Jan 2018 09:15:49 +0000 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-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Json] Fwd: JSON Content Rules 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, 25 Jan 2018 09:15:56 -0000 On 24/01/2018 17:51, Daniel P wrote: > On Wed, Jan 24, 2018 at 11:09 AM, Pete Cordell > wrote: > > > JCR works in terms of rules ... JCR doesn't do macro substitution. > > Of course, but the issue is whether the grammar needs to distinguish > between name rule specifications and > value rule specifications. I don't think that it does, and I don't think > that that provides any meaningful benefit to > the user, compared to the loss in simplicity of the syntax. That's just > my opinion, of course, but I would be > interested to see what others on the list think. I too am interested in the opinions of the group. Maybe I'm being over cautious? Pete. http://www.xml2cpp.com